CI/CD Interview Questions and Answers

Both build on continuous integration, but they differ in what reaches production.

• Continuous delivery: every change that passes automated tests is always in a deployable state and can be released on demand. The final step to production is a manual approval or a button press. Teams release frequently but keep human control.
• Continuous deployment: every change that passes the pipeline is deployed to production automatically, with no manual gate. This requires very high test coverage, strong monitoring, and fast rollback.

Both need:

• Automated build, test, and security checks.
• Versioned artefacts and reproducible builds.
• Feature flags to decouple release from deploy.
• Observability and alerting.

Continuous delivery suits regulated or high-risk systems, while continuous deployment suits mature teams with low-risk, high-frequency changes. The difference is only the final production gate.

Optimise for independent, fast, and safe delivery per service.

• Per-service pipelines: each repository builds, tests, and deploys its own service, avoiding a monolith pipeline that couples release cycles.
• Fast feedback: run linting, unit tests, and security scans first, then integration and end-to-end tests.
• Build once: produce an immutable artefact, such as a container image or package, tagged with the commit SHA, and promote the same artefact through environments.
• Shared libraries and contracts: version APIs and run consumer-driven contract tests so services can evolve independently.
• Deployment: use Kubernetes or a platform with health checks, progressive rollout, and automatic rollback.
• Environment parity: keep dev, staging, and prod as similar as possible.

stages: [lint, test, build, scan, deploy-staging, e2e, deploy-prod]

Use monorepo-aware change detection to avoid rebuilding unrelated services, and keep pipelines under ten minutes.

A build artefact is the immutable output of a build: a container image, JAR, binary, or package. Versioning means each artefact has a unique, traceable identifier.

Why:

• Reproducibility: you can redeploy exactly the bits that were tested instead of rebuilding and hoping.
• Traceability: a tag tied to a commit and pipeline run lets you find what changed and who made it.
• Rollback: redeploying a previous artefact is fast and reliable.
• Promotion: build once, then move the same artefact through staging and production. Rebuilding per environment risks differences.

Practices:

• Tag with the commit SHA plus a semantic version.
• Store in a registry or artefact repository with retention policies.
• Sign and scan artefacts for supply-chain security.
• Never overwrite a released tag; immutability is the point.

docker build -t registry.example.com/api:$(git rev-parse --short HEAD) .
docker push registry.example.com/api:$(git rev-parse --short HEAD)

Avoid building on production hosts.

A canary releases the new version to a small slice of traffic before a full rollout.

Process:

1. Deploy the new version alongside the stable one.
2. Route a small percentage of traffic, for example 5 percent, to the canary.
3. Monitor error rates, latency, and business metrics.
4. If healthy, gradually increase traffic; if not, route everything back to stable.

kubectl set image deployment/api api=api:2.0
kubectl rollout pause deployment/api

Canary is often implemented with a service mesh such as Istio, an ingress controller with weights, or a feature flag. It limits blast radius and gives real-user feedback.

Requirements: good observability, comparable metrics between versions, and automation to promote or abort. Unlike blue/green, canary runs both versions simultaneously, so ensure compatibility and avoid session affinity issues.