CI/CD interview questions and answers

"Walk me through your deployment process." He described it well: pull request, tests, merge, a build on main, and a deploy. The interviewer waited a beat and asked what happens when the deploy is bad. He said they would fix forward. She asked how long that takes. Forty minutes, maybe an hour. She asked how long customers see the broken version. And there it was — the actual question, which had been the question all along.

Most CI/CD interview questions are not about which tool you have used. Jenkins, GitHub Actions, GitLab CI and Argo all do the same things with different syntax, and interviewers know it. What they are testing is whether you understand what a pipeline is *for*: shipping safely and getting back to a known-good state fast. This guide covers the questions that recur, in the order they usually arrive.

The pipeline you should be able to draw

Be able to sketch this in ninety seconds, tool-agnostic:

• Commit and trigger. What runs on a pull request versus on the main branch, which checks are required to merge, and why you do not run the two-hour suite on every push.
• Build once, promote the artifact. This is the single most important principle and the one candidates most often miss. You build one immutable artifact — a container image, a JAR, a bundle — and promote *that exact artifact* through staging to production. Rebuilding per environment means the thing you tested is not the thing you shipped.
• Test stages, ordered by speed. Fast unit tests first so failures come back in two minutes, then integration, then end-to-end and performance. Fail fast, fail cheap.
• Artifact storage and versioning. Tagged, immutable, ideally signed, and the deployment references a version rather than a branch name.
• Progressive rollout. Canary or blue-green, with health checks gating each increment.
• Rollback and observability. Automated revert when error rates breach a threshold, and monitoring that notices before your users do.

CI versus CD versus CD

Asked constantly, answered vaguely. The precise version:

• Continuous integration — every change is merged to the mainline frequently and verified automatically. The point is small, frequent merges, not just "we run tests."
• Continuous delivery — every passing build is *deployable* to production at any time, with the final push being a human decision.
• Continuous deployment — every passing build *is* deployed automatically, with no human gate.

Then add the honest part: continuous deployment requires a test suite you genuinely trust and fast automated rollback, and most organisations should not do it until they have both.

Deployment strategies

• Blue-green. Two identical environments; you deploy to the idle one, verify, then switch traffic. Rollback is another switch, so it is very fast. Costs double the infrastructure during the deploy, and shared state such as the database still needs care.
• Canary. Route a small percentage of traffic to the new version, watch metrics, increase gradually. Catches problems that only appear under real traffic. Needs good observability to be meaningful — a canary nobody is watching is just a slow deploy.
• Rolling update. Replace instances gradually. The default in Kubernetes, cheap, but both versions serve traffic simultaneously, so your API and database changes must be backwards compatible.
• Feature flags. Decouple deploy from release entirely — ship the code dark, turn it on for a cohort. The honest cost is flag debt, which becomes a real maintenance problem if nobody removes them.

The follow-up you should be ready for: how do you deploy a breaking database migration? The expected answer is the expand-and-contract pattern — add the new column, write to both, backfill, switch reads, then remove the old column in a later release. Never one migration that both adds and removes.

Rollbacks, the question that decides the round

• Rollback should be one command or automatic, and it should be rehearsed. A rollback path nobody has tested is not a rollback path.
• Database changes are not always reversible, which is exactly why expand-and-contract exists. Say this — it shows you have actually done it.
• Automated rollback triggers: error rate, latency percentile, or a failing health check breaching a threshold during a canary.
• Roll forward versus roll back. Rolling forward is acceptable when the fix is trivial and verified. It is not an excuse for having no rollback.

# a canary gate: promote only if the new version's error rate stays under budget
steps:
  - deploy: { target: canary, weight: 5% }
  - wait:   { duration: 10m }
  - check:
      metric: http_error_rate
      threshold: 0.01          # 1% — breach triggers automatic rollback, not a page
      on_breach: rollback
  - deploy: { target: production, weight: 100% }

Secrets, security and supply chain

Increasingly asked, and a strong differentiator:

• Never in the repository. Use a secrets manager or the CI provider's encrypted secrets, injected at runtime.
• Short-lived credentials over long-lived keys — OIDC federation between your CI provider and your cloud, so no static cloud keys exist at all.
• Least privilege for the pipeline itself. A build job that can deploy to production is a large blast radius.
• Dependency and image scanning in the pipeline, with a policy for what blocks a build versus what files a ticket.
• Artifact provenance. Signing images and generating an SBOM. Naming this unprompted is a senior signal in 2026.
• Protect the main branch. Required reviews, required checks, and no direct pushes — including for administrators.

Our DevOps engineer interview questions guide covers the wider round and Docker interview questions covers the image layer.

Flaky tests and pipeline speed

• How do you handle a flaky test? The correct answer is quarantine and fix, with an owner and a deadline — not a blanket retry, which hides real failures. Automatic retries in the pipeline should be visible and tracked.
• Speeding up a slow pipeline: parallelise across runners, cache dependencies and layers properly, run only tests affected by the change where your tooling supports it, and move genuinely slow suites to a scheduled run rather than every commit.
• What is a good pipeline duration? Under ten minutes for the PR feedback loop is the usual target, because beyond that developers context-switch and stop watching.
• Trunk-based development versus long-lived branches. Trunk-based with feature flags produces smaller, safer changes; long-lived branches produce large, risky merges. Have a view.

The four DORA metrics

Worth knowing by name because interviewers use them as shorthand: deployment frequency, lead time for changes, change failure rate, and time to restore service. If you are asked to improve a team's delivery, framing your answer around which of these four you are targeting is a strong structure.

The behavioral question inside the technical round

You will almost certainly be asked about a bad deployment. Have a real one ready: what shipped, how you found out (monitoring or a customer — be honest), what you did first, how long recovery took, and what you changed in the pipeline afterwards so that class of failure could not recur.

The last part is the whole point. A story that ends "and we were more careful after that" is a story with no engineering in it. Our behavioral interview questions guide covers the structure.

Where each prep option actually helps

• The DORA / Accelerate research — the source of the four metrics and the vocabulary senior interviewers use.
• Your own pipeline — the highest-yield preparation is being able to describe one you actually built, including what was bad about it.
• The GitHub Actions and GitLab CI documentation — enough to write a workflow from memory, which does occasionally get asked.
• Google's SRE book — for error budgets and the release-engineering chapter, which reframes deployment as a risk decision.
• ChatGPT — good at writing pipeline YAML. It will not ask how long customers saw the broken version, which is the question that matters.
• Greenroom — the spoken layer. Ari, the AI interviewer runs infrastructure rounds out loud and pushes on the failure path. Honest tradeoff: Ari will not review your workflow file, so pair it with real practice.

Frequently asked questions

What is the difference between continuous delivery and continuous deployment?

Continuous delivery means every passing build is deployable to production at any time, with the final push remaining a human decision. Continuous deployment means every passing build is deployed automatically with no human gate. The honest addition that scores well is that continuous deployment requires a test suite you genuinely trust plus fast automated rollback, and most teams should not adopt it before they have both.

What is the difference between blue-green and canary deployment?

Blue-green runs two identical environments, deploying to the idle one and switching all traffic at once, which makes rollback nearly instant but costs double infrastructure during the deploy. Canary routes a small percentage of real traffic to the new version and increases it gradually while watching metrics, which catches problems that only appear under production load but requires good observability — a canary nobody is monitoring is just a slow deploy.

How do you roll back a bad deployment?

Rollback should be one command or fully automatic, triggered by error rate, latency percentile or health check breaches during a progressive rollout, and it must have been rehearsed rather than assumed. The complication is the database: schema changes are not always reversible, which is why the expand-and-contract pattern exists — add the new column, write to both, backfill, switch reads, then drop the old column in a later release.

How do you deploy a breaking database migration safely?

Use expand and contract across multiple releases rather than a single migration that both adds and removes. First add the new column or table, then write to both old and new, then backfill historical data, then switch reads to the new path, and only in a later release remove the old column. At every intermediate point both the old and new application versions can run, which is what makes rolling updates and rollbacks safe.

How do you handle flaky tests in a CI pipeline?

Quarantine the test out of the blocking path, assign an owner and a deadline, and fix the underlying cause — usually timing, shared state or test ordering. Blanket automatic retries are the common wrong answer because they hide real failures; if retries are used at all they should be visible and tracked so flakiness rates are measurable rather than invisible.

Why should you build once and promote the same artifact?

Because rebuilding per environment means the thing you tested is not the thing you shipped. Dependencies can resolve differently, build tooling can drift, and a subtle difference between the staging and production builds is very hard to debug. Building one immutable, tagged, ideally signed artifact and promoting that exact version through each environment removes an entire class of works-in-staging failures.