Question 1

What is CI/CD?

Accepted Answer

CI, Continuous Integration, means developers merge code often and every change is automatically built and tested, so problems are found early. CD means Continuous Delivery, where every passing change is ready to release with one click, or Continuous Deployment, where it goes to production automatically. Together they make releases small, frequent and much less risky.

Question 2

Describe the stages of a typical CI/CD pipeline.

Accepted Answer

A push or pull request triggers the pipeline. It checks out the code, installs dependencies, runs linting and unit tests, and runs a security scan. Then it builds an artifact, often a Docker image tagged with the commit SHA, and pushes it to a registry. Next it deploys to a staging environment and runs integration or smoke tests, then deploys to production, often after an approval, and finally checks health and sends notifications.

Question 3

What is the difference between Continuous Delivery and Continuous Deployment?

Accepted Answer

In both, every change is built, tested and ready to release. In Continuous Delivery a person decides when to release to production, usually with a manual approval step. In Continuous Deployment there is no manual step: every change that passes all the checks goes to production automatically. Continuous Deployment needs strong automated tests and monitoring.

Question 4

How do you handle secrets in a CI/CD pipeline?

Accepted Answer

I never put secrets in the code or pipeline file. I store them in the CI tool's secret store, such as GitHub Actions secrets or a vault, and give each environment its own secrets. Where possible I use short-lived credentials, for example GitHub OIDC to assume an AWS role instead of storing access keys. Secrets are masked in logs, and only the jobs that need them can read them.

Question 5

Explain blue-green and canary deployments.

Accepted Answer

In blue-green there are two identical environments. Blue runs the current version, I deploy the new version to green, test it, then switch all traffic to green. Rollback is just switching back. In a canary release a small share of users, say 5%, get the new version first. I watch errors and latency, then increase the share step by step, or roll back if the numbers look bad. Rolling updates replace instances gradually without a second full environment.

CI/CD interview questions