CI/CD Interview Questions

A curated set of CI/CD interview questions covering the concepts and practical tooling questions you'll actually be asked.

Q: What's the difference between Continuous Integration, Continuous Delivery, and Continuous Deployment? Continuous Integration means developers merge code into a shared branch frequently, with every merge automatically built and tested. Continuous Delivery goes further — every change that passes CI is automatically packaged into a release-ready artifact, but a human still approves the actual push to production. Continuous Deployment removes that manual approval entirely: anything that passes all automated checks goes straight to production. All three sit on top of the same automated pipeline; they differ only in how much of the release path is automated versus human-gated.

Q: Why does running the pipeline on every commit catch bugs earlier than testing before a big release? Because the pipeline gives feedback within minutes of a change being introduced, while the author still has full context on what they just wrote and why. Without this, bugs surface weeks later during integration or a pre-release testing pass, when many changes have piled up, the original author may have moved on to something else, and it's far harder to isolate which specific change caused the regression.

Q: How should secrets like API keys and deploy credentials be handled in a pipeline? They should never be hardcoded into a workflow file or committed to the repository, since the file itself is visible to anyone with read access. Instead, use the CI platform's encrypted secrets store (e.g. GitHub Actions' repository/organization secrets), inject them as environment variables at run time, and rely on the platform's log masking so secret values never appear in build output. Sensitive deploy environments should also be gated with required-reviewer approval and restricted to specific branches.

Q: What is a branch-based deployment strategy, and why gate deploys to main? It means only changes reaching a specific branch (typically main) trigger a production deployment, while other branches and pull requests still run the build/test stages for feedback but never deploy. This ensures every production release corresponds to reviewed, merged code, and prevents an untrusted or in-progress pull request — including one from an external contributor — from ever reaching production.

Q: What's the difference between blue-green and canary deployment? Blue-green deployment runs two identical production environments ("blue" = current live version, "green" = new version); traffic is switched from blue to green all at once after the green environment is verified healthy, and blue is kept warm for an instant rollback. Canary deployment instead rolls the new version out to a small percentage of real traffic first, monitors it, and gradually increases that percentage if it looks healthy — trading a slower rollout for the ability to catch a bad release while it's only affecting a small slice of users, rather than everyone at once.

Q: How does a rolling deployment differ from blue-green, and what does it cost you in exchange for being cheaper? A rolling deployment replaces old instances with new ones a few at a time within the same environment, using no extra infrastructure beyond what's already running — unlike blue-green, which needs a whole second environment provisioned alongside the first. The trade-off is rollback speed and blast radius: blue-green can revert instantly by switching a router back to the old environment, while reverting a rolling deployment means running the rollout again in the opposite direction, and a bad version is exposed to some fraction of real traffic for as long as that takes.

Q: What is a matrix build, and why would a project use one? A matrix build runs the same job once for every combination of a set of variables you define — commonly multiple language/runtime versions crossed with multiple operating systems — instead of hand-writing a near-duplicate job for each combination. It's how a library confirms it actually works everywhere it claims to support, with each combination reporting its own separate pass/fail status so a break in one specific version/OS pairing is immediately obvious rather than hidden inside one aggregate result.

Q: Why does dependency caching matter in a CI pipeline, and what has to be true of the cache key for it to be safe? Without caching, every pipeline run reinstalls every dependency from scratch, which can dominate total run time on a project with a large dependency tree. The cache key has to change whenever the dependencies actually change — typically by including a hash of the lockfile (hashFiles('package-lock.json')) — so a stale cache is never silently reused against a lockfile it no longer matches; a fixed, unchanging key would make the pipeline fast but wrong.

Q: What's the difference between dependency vulnerability scanning and secret scanning in a pipeline, and why run both? Dependency vulnerability scanning checks third-party packages your project depends on against a database of known CVEs, catching a vulnerability that already exists in code you didn't write. Secret scanning instead checks the diff of every commit or PR for patterns that look like real credentials — an API key, a private key, a database password — catching a mistake in code you did write, before it's merged. They cover two entirely different risks, so a mature pipeline runs both rather than treating either as a substitute for the other.

Q: If a secret scanner flags a real leaked credential in a commit, is deleting it from the code enough to fix the problem? No. The credential must be revoked and rotated immediately — a value that was ever committed, even briefly, should be treated as compromised, since it may already have been cloned, scraped by an automated bot, or cached somewhere outside your control before anyone noticed. Removing it from the latest commit (or even rewriting history to erase it) only stops it from being visible going forward; it does nothing to invalidate a credential that's already potentially in someone else's hands.