Top 50 CI/CD Interview Questions (2026)

CI/CD automates how code moves from a commit to running software. CI (continuous integration) merges changes often and runs an automated build and tests on each one. CD covers continuous delivery (keep it releasable behind a manual gate) or continuous deployment (ship every passing change automatically).

Teams adopt it to ship faster with fewer failures. Automated tests catch bugs in minutes, an immutable artifact means you deploy exactly what you tested, and small frequent releases are easier to review and roll back than big rare ones. It's a way of working, not a single tool.

Continuous integration (CI) means merging code to a shared branch often, with automated build and tests running on every change so integration problems surface in minutes, not weeks.

Continuous delivery keeps that branch always releasable and adds a manual approval to push to production. Continuous deployment removes the approval: every change that passes the pipeline ships to production automatically. Same acronym, one key difference: the human gate.

A typical pipeline runs commit, build, test, then deploy. A push triggers it, the code is built into an artifact or container image, automated tests and scans run, and if everything passes the artifact is promoted through environments to production.

The principle worth stating is build once, deploy everywhere: you build a single immutable artifact and promote that exact artifact through staging and production, rather than rebuilding at each stage. Rebuilding risks shipping something you never tested.

A pipeline is the automated sequence of steps that takes a code change and moves it toward production. It's defined as code (a YAML or config file in the repo) and runs on a CI/CD service that watches for triggers like a push or a pull request.

Each step, build, test, scan, deploy, either passes or fails, and a failure stops the pipeline so a broken change doesn't reach production. Defining it as code means the pipeline is versioned, reviewed, and reproducible, just like the app it builds.

Automation makes releases repeatable, fast, and auditable. A manual deploy depends on one person's memory and steps; an automated one runs the same way every time, logs what it did, and can be triggered by anyone with the right permission.

The deeper payoff is small batch size: when deploying is cheap and safe, teams ship small changes often, which makes each change easier to review and to roll back. Big rare manual releases are where the scary incidents live.

A build artifact is the packaged output of your build: a container image, a JAR, a binary, a tarball. It's what gets deployed. Immutable means once built and versioned, it never changes; a new build produces a new version rather than editing the old one.

Immutability is what makes 'the version in staging is exactly the version in production' true. If artifacts could change after the build, you'd be testing one thing and shipping another, and rollbacks would be unreliable.

Most pipelines trigger on a Git event: a push to a branch, a pull request opened or updated, or a tag created for a release. The CI service listens via a webhook and starts the matching workflow. You can also trigger on a schedule (nightly builds) or manually for a controlled deploy.

Scoping triggers matters: you might run tests on every pull request but only deploy to production on a push to main or a version tag. That's how one repo runs different work for different events.

Build compiles and packages your code into a single artifact: a container image, a binary, a bundle. Test runs your automated checks against that artifact or the code: unit tests, integration tests, linting, and security scans, failing the pipeline on any red.

Deploy takes the tested artifact and releases it to an environment, usually staging first, then production after it passes there. The key rule across all three is that the artifact built once in the build stage is the same one tested and deployed, never rebuilt.

Unit tests check one small piece of code in isolation, mocking its dependencies. They're fast and run on every commit, so they're the first gate in the pipeline. Integration tests check that multiple parts work together (your code plus a real database or another service), so they're slower and run a bit later.

In a pipeline you order them by speed and cost: fast unit tests fail early and cheaply, then integration tests catch the wiring problems units can't. Running the fast ones first is what keeps feedback quick.

Git is the trigger and the source of truth. A pipeline runs off a specific commit, so the exact code that shipped is always identifiable by its SHA. Branches and pull requests give you the review-then-merge gate, and tags mark the commits you build releases from.

The everyday flow: branch, commit, open a pull request that runs CI, merge once it's green, and the merge to main triggers the deploy pipeline. Without Git events, the pipeline has nothing to react to.

A runner (GitLab's term) or agent (Jenkins' term) is the machine or container that actually executes your pipeline jobs. The CI service schedules a job onto a runner, which checks out the code, runs the steps, and reports back the result.

Runners can be hosted by the CI provider (GitHub-hosted, GitLab shared runners) or self-hosted on your own machines when you need specific hardware, network access, or more control. Each job usually runs on a fresh, clean runner so builds don't leak state into each other.

Keeping the pipeline config as a YAML file in the repo (pipeline as code) means it's versioned, reviewed in pull requests, and travels with the code it builds. Change the pipeline and the change goes through the same review as any code change.

It also makes pipelines reproducible and self-documenting: anyone can read the file to see exactly how the app is built, tested, and deployed. Clicking through a UI to configure a build, by contrast, leaves no history and is easy to break silently.

Fail fast means stopping the pipeline as soon as a step fails, so you don't waste time and compute running later stages on a change that's already broken. If the build breaks, there's no point running deploys.

It also means ordering cheap, likely-to-fail checks first: linting and unit tests before slow integration tests and image builds. The developer gets red feedback in a minute instead of ten, which keeps the merge loop tight.

Environments are the separate places your app runs as it moves toward users. Development is where you build, staging mirrors production for final testing, and production is what real users hit. The pipeline promotes the same artifact through them in order.

The point of staging is a trustworthy rehearsal: it should match production closely so tests there predict how the release behaves for real. When staging drifts from production, it stops being a useful signal and bugs slip through.

You build one artifact and change only the configuration per environment, never the artifact itself. Config comes from environment variables, config files, or a secrets store injected at deploy time, so the same image points at the staging database in staging and the production database in production.

This keeps the 'build once, promote everywhere' rule intact. If you baked config into the image, you'd need a different build per environment, which breaks the guarantee that what you tested is what you ship.

A rollback is returning to a previous working version after a bad deploy. Because CI/CD keeps every build as an immutable, versioned artifact, rolling back is redeploying the last known-good artifact rather than scrambling to undo changes by hand.

That's the safety net that makes frequent deploys sane: if a release misbehaves, you restore service in seconds by pointing back at the previous version, then investigate calmly. Manual releases without stored artifacts make rollback slow and risky.

Branch protection is a rule on an important branch (usually main) that blocks direct pushes and forces changes through a pull request. It can require passing status checks, a minimum number of reviews, and an up-to-date branch before anyone can merge.

CI/CD leans on it because main is what gets deployed. If people could push straight to main, an untested change could deploy to production instantly. Protection makes the green pipeline and a review a hard gate, so only vetted code reaches the branch that ships.

A deploy script on one laptop depends on that machine's setup, that person being available, and their memory of the steps. A CI/CD tool runs the same defined steps on a clean, shared runner, triggered by a Git event, and logs every run so anyone can see what happened.

The result is releases that are repeatable, auditable, and not tied to one person. When the deploy lives in the pipeline, the whole team can trigger it, review it, and trust that staging and production ran the exact same steps.

Trigger on a push to main, build the image tagged by commit SHA so it's traceable, run tests against it, then push it to a registry. A separate deploy job or a GitOps controller picks up that image and rolls it out to the target environment.

The important habits: tag by immutable SHA rather than only 'latest', so you always know what's running, and split build and deploy into jobs with the deploy gated on tests passing. Store registry and deploy credentials in the CI secret store, never in the YAML.

Run jobs in parallel when they're independent: linting, unit tests, and a security scan can all run at once to cut total pipeline time. Run them in sequence when one depends on another's output, like deploy needing the build artifact first.

The tools express this with dependencies (needs in GitHub Actions, stages in GitLab). You parallelize the fan-out of independent checks, then have a dependent job wait on all of them. The goal is the shortest safe critical path, not maximum parallelism for its own sake.

Caching stores things that rarely change (downloaded dependencies, a build cache) between runs so the pipeline doesn't refetch or rebuild them every time. Caching your dependency install can cut minutes off each run, keyed on the lockfile so the cache busts only when dependencies actually change.

The risk is a stale or wrong cache producing a build that passes locally but fails elsewhere, or hiding a real dependency change. Key caches on a hash of the lockfile, and be ready to bust the cache when you suspect it's poisoned. A wrong cache is worse than no cache.

Rolling replaces old instances with new ones gradually with no downtime, but there's a window where both versions serve traffic and a bad version reaches everyone as it ramps. Blue-green runs two full environments and flips all traffic from old (blue) to new (green) at once, giving instant rollback but doubling infrastructure during the switch.

Canary sends a small slice of traffic to the new version, watches metrics, and ramps up only if it's healthy, giving the smallest blast radius at the cost of more automation and observability to run it. Feature flags are the finer-grained cousin: ship code dark and toggle it on for a subset of users independent of deploys.

Secrets never live in source control or in the image. Store them in the CI platform's encrypted secret store, or pull them from a dedicated manager (Vault, AWS Secrets Manager, GCP Secret Manager), and inject them into only the jobs that need them at runtime as environment variables or mounted files.

Prefer short-lived credentials over long-lived keys: OIDC or workload identity lets a job get a scoped, temporary token to deploy, so there's no static key to leak. Add secret scanning to catch anything accidentally committed, and never echo a secret into the build log.

A flaky test passes and fails without any code change, usually because of timing, ordering, or a shared resource. In CI/CD it's poison: it breaks builds at random, so people start rerunning until it goes green or ignoring red altogether.

That erodes trust in the whole pipeline, the exact thing CI depends on. The fix is to treat flakes as bugs: quarantine the test so it can't block the pipeline, find the real cause (a race, an unmocked dependency, test order coupling), fix it, and return it. Never make 'just rerun it' the culture.

A quality gate is a condition the pipeline enforces before a change can move forward: tests must pass, code coverage can't drop below a threshold, no high-severity vulnerabilities in the scan, no linting errors. Fail the gate and the pipeline stops.

Gates turn standards into something automatic rather than a reviewer's memory. The balance to name is strictness versus friction: gates that are too rigid (an unrealistic coverage number) get bypassed or resented, so they should block real problems without blocking honest work.

In a monorepo, one repo holds many services or packages, so running every test and building everything on every commit gets slow fast. The fix is change detection: figure out which projects a commit actually touched and only build and test those, plus anything that depends on them.

Tools like Nx, Turborepo, or Bazel do this with a dependency graph and caching, so a change to one service doesn't trigger the whole repo. The trade-off is more pipeline complexity, but on a large monorepo it's the difference between a two-minute and a forty-minute pipeline.

Tag every artifact so it's traceable back to the exact source. The common approaches are semantic versioning (v1.4.2) for releases, the Git commit SHA for every build so any deploy maps to a commit, or a combination. Pinning production to an immutable digest, not a moving tag like 'latest', guarantees you run the exact bytes you tested.

The reason it matters: when something breaks in production, you need to know precisely which build is running and diff it against the last good one. A meaningful tag or digest turns that from guesswork into a lookup.

Shift left means moving checks earlier in the pipeline, closer to when code is written, instead of only at the end before release. For security that means dependency scanning, static analysis (SAST), secret scanning, and container image scanning running on pull requests, not just a final audit.

The payoff is cheaper fixes: catching a vulnerable dependency or a hardcoded token at PR time is far easier than after it ships. The balance is speed, so you run fast checks on every PR and heavier scans on a schedule or before release.

On a pull request you run the fast, blocking checks that decide whether the change is safe to merge: linting, unit tests, quick integration tests, and lightweight security scans. They give the author feedback in minutes and gate the merge.

On deploy (after merge to main) you run the heavier work: build the production artifact, full integration or end-to-end tests against a staging environment, and the actual rollout. Splitting them keeps the PR loop fast while still doing the expensive validation before real users are affected.

Run migrations as an explicit, ordered step, not a side effect. A migration tool (Flyway, Liquibase, or a framework's migrations) applies versioned schema changes in order and records which ran, so every environment converges to the same schema. Migrations run before or alongside the deploy, gated so a failed migration stops the rollout.

The care needed is compatibility: a migration should work with both the old and new app code during a rolling deploy, because both run at once briefly. That's why big schema changes use the expand-and-contract pattern rather than a single breaking change.

Hosted runners (provided by GitHub or GitLab) are the default: no maintenance, clean environment every run, and they scale for you. Reach for self-hosted runners when you need something they can't give: specific hardware (GPUs, more memory), access to a private network to deploy internally, or heavy caching that's expensive to rebuild.

The trade-off is ownership: you patch, secure, and scale self-hosted runners yourself, and a persistent runner risks leaking state between jobs if you're not careful. So it's a deliberate choice for a real constraint, not a default.

Failures should reach the person who can fix them, fast and with context. Post build status back to the pull request so a red check blocks merge, and send a notification to a team channel or the commit author on a broken main branch, linking straight to the failing job's logs.

The goal is a short feedback loop without noise: notify on real failures and on a fixed-after-broken main, but don't spam the channel on every passing run. A broken main branch is an interrupt, so treat it like one.

Smoke tests are a small set of checks that confirm the most important things work right after a deploy: the app starts, the health endpoint responds, a login succeeds, a key page loads. They're fast and shallow on purpose, a sanity check rather than full coverage.

They run against the just-deployed environment as a post-deploy gate. If a smoke test fails in staging, the pipeline stops before promoting to production; if it fails in production, it triggers an alert or an automatic rollback. They catch the deploy that built fine but is broken in the running environment.

Most CI/CD tools support a protected environment or a manual approval step: the pipeline pauses before deploying to production and waits for a designated person to approve. That's the practical difference between continuous delivery (gate present) and continuous deployment (gate removed).

Add a gate when the cost of a bad deploy is high and automated confidence isn't enough yet: regulated systems, a release that needs a business sign-off, or a team still building trust in its tests. Remove it as your test suite and monitoring mature, because a rubber-stamp approval that nobody really reviews adds delay without adding safety.

Treat the pipeline as production, because it holds the keys to production. Use least-privilege, short-lived credentials (OIDC or workload identity, not long-lived keys), pin third-party actions and base images to immutable digests so a compromised tag can't inject code, and require reviews plus branch protection so no one pushes straight to a deploy branch.

Then add scanning as gates: dependency, container, and secret scanning, plus SBOM generation for supply-chain visibility. Sign artifacts and verify signatures at deploy so only trusted builds reach production. The threat model to name is supply-chain: your build system is a high-value target.

Supply-chain security is about trusting everything that goes into a build: base images, dependencies, build tools, and the pipeline itself. The attacks are real: a poisoned dependency or a compromised build step ships malicious code to everyone downstream, so securing only your own source isn't enough.

Concrete measures in the pipeline: pin dependencies and images to immutable digests, generate an SBOM so you know exactly what's inside a build, scan for known vulnerabilities, sign artifacts and verify signatures before deploy (Sigstore-style), and follow SLSA provenance so you can prove how an artifact was built. Defense in depth, because any single control can be bypassed.

Zero downtime comes from never removing capacity that's serving traffic. Deploy with a rolling, blue-green, or canary strategy so new instances come up and pass health checks before old ones are drained, and gate the rollout on readiness so traffic only reaches instances that are actually ready.

Two things make or break it: backward-compatible database changes (expand-and-contract, so old and new code both work during the overlap) and graceful shutdown (draining in-flight requests before an instance stops). The pipeline automates the rollout and, importantly, an automatic rollback on failed health checks.

Progressive delivery is CI/CD plus automated, metric-driven rollout control. Instead of shipping to everyone at once, the pipeline releases to a small slice (a canary), watches real signals like error rate and latency against a baseline, and automatically ramps up or rolls back based on whether the new version is healthy.

Tools like Argo Rollouts or Flagger drive this with analysis steps between traffic increases. It extends CI/CD by making the release itself a controlled, observable experiment rather than a single irreversible switch, which shrinks the blast radius of a bad change to a few users.

The enemies are slow feedback and queued jobs. Attack both: parallelize independent jobs, cache dependencies and build outputs keyed on real inputs, run only the tests affected by a change (test impact analysis, especially in a monorepo), and scale runner capacity so pipelines don't sit in a queue.

Then measure it: track pipeline duration and queue time as first-class metrics, because a pipeline that creeps from five minutes to thirty quietly kills the deploy cadence CI/CD exists to enable. Splitting fast PR checks from heavy pre-deploy validation keeps the loop developers hit most times a day tight.

GitOps makes a Git repository the single source of truth for the desired state of your deployments. A controller in the cluster (Argo CD, Flux) continuously compares the live state to what's declared in Git and reconciles any difference, so you deploy by merging a pull request, not by running a deploy command from CI.

What it changes: every change is reviewed, versioned, and auditable in Git; rollback is a git revert; and drift is auto-corrected because the controller keeps pulling reality back to the declared state. It also separates CI (build and test, produce an artifact) from CD (the controller reconciles the cluster), which is cleaner than CI pushing directly to production.

Roll back by default: redeploying the last known-good artifact is fast, well-understood, and restores service immediately, so it's the right instinct when users are hurting and you're not sure of the fix. It buys you calm time to diagnose.

Roll forward (ship a fix) makes sense when rolling back is impossible or worse, for example after a one-way database migration, or when the fix is small, obvious, and already tested. The senior judgment is: restore service first by whichever path is faster and safer, and don't let 'I can fix it in five minutes' delay a rollback that would restore service now.

Build the artifact once, then promote that exact artifact (same digest) from dev to staging to production, changing only environment config, never rebuilding. Each promotion is gated on the artifact passing that environment's checks, and the promotion itself is recorded so you have an audit trail of what reached production and when.

The failure to avoid is rebuilding per environment or promoting by tag that can move under you. Promote by immutable digest so 'the thing that passed staging' and 'the thing in production' are provably identical, which is the whole reliability argument for a promotion pipeline.

The pipeline is code, so treat it like code: keep it in version control, review changes in pull requests, and test it. Validate config syntax in CI, run the pipeline against a branch before merging changes to it, and lint reusable pipeline components. Shared logic goes into reusable workflows or templates so you don't copy-paste the same YAML across repos.

The failure mode is a pipeline that only its author understands and that breaks silently when a dependency updates. Pinning action and image versions, documenting the pipeline, and having more than one person able to fix it are what keep it from becoming a fragile bus-factor-one system.

Keep the pipeline logic cloud-agnostic and push the differences into config and environment-specific deploy steps. Build one artifact, then have per-target deploy jobs that apply the same rollout strategy to each cloud or region, ideally in a controlled order (canary in one region, then expand) rather than all at once.

The hard parts are ordering and consistency: you don't want a bad release hitting every region simultaneously, and state or data replication across regions has its own latency and consistency trade-offs. Roll out region by region with health gates between them so a bad deploy stops after the first region.

Bake the controls in so compliance is automatic, not a manual checklist. Enforce required reviews and branch protection, record every deploy (who, what artifact, when) as an immutable audit log, generate an SBOM per build, and require a separation of duties where the person who merges isn't the only one who can approve a production release.

The goal is that meeting the requirement and doing the work are the same action: because every change flows through a reviewed, logged pipeline, the audit trail exists as a byproduct. That's stronger and cheaper than reconstructing evidence after the fact for an auditor.

Feature flags decouple deploy from release: you ship code dark (merged and deployed but off), then flip it on for a percentage of users or a segment independent of any deploy. That pairs perfectly with trunk-based development and continuous deployment, since risky code can be merged safely behind an off flag.

The cost is flag debt and testing complexity. Stale flags pile up and every live flag multiplies the number of code paths, so a change must work with each flag on or off. Mature setups enforce flag hygiene: an owner and an expiry per flag, and cleanup once a feature is fully rolled out or removed.

First correlate: a fresh incident right after a release is a deploy until proven otherwise, so I check what just shipped. Then mitigate before diagnosing fully: roll back to the last known-good artifact to stop user pain, because restoring service comes before understanding the cause.

Once service is stable, resolve the root cause properly, then run a blameless postmortem. The part specific to CI/CD is closing the loop in the pipeline: add the test or check that would have caught this, or a stricter health gate on rollout, so the same class of bug can't ship again. Detect, mitigate, resolve, and harden the pipeline.

The DORA metrics are the standard four: deployment frequency (how often you ship), lead time for changes (commit to production), change failure rate (what share of deploys cause a problem), and time to restore service after a failure. Together they balance speed against stability, so you can't game one by wrecking another.

Read them as a pair: high deployment frequency with a low change failure rate and fast restore is a healthy pipeline. Shipping often but breaking things constantly, or being stable only because you rarely deploy, both show up clearly. Pipeline duration and queue time are useful operational metrics underneath these.

An ephemeral (or preview) environment is a temporary, full deployment of a pull request, spun up automatically when the PR opens and torn down when it merges or closes. Reviewers get a live URL to click through the change instead of only reading the diff, and integration tests can run against a real running stack.

They fit CI/CD as an extension of the PR pipeline: build the artifact, deploy it to a throwaway namespace or environment, run tests, post the URL back to the PR. The trade-offs are cost and cleanup: you pay for the extra environments and need reliable teardown, or orphaned environments pile up and the bill grows.

Make deploy steps idempotent, so running one twice has the same effect as running it once. Declarative apply (kubectl apply, terraform apply) converges to the desired state whether the resource exists or not, which is why a retried deploy doesn't create duplicates or half-apply a change.

The failure to avoid is imperative steps that assume a clean starting state: a script that creates a resource fails on the second run because it already exists, so a flaky-network retry breaks. Design each step to be re-runnable, and where a step truly can't be (a one-way migration), make that explicit and guard it so an accidental retry can't corrupt state.