CI/CD Pipeline Interview Questions – Practice Quiz for Developers

Both build on continuous integration and produce a release-ready artifact from every passing pipeline. The line between them is the production gate: continuous delivery stops at a deployable artifact and a human decides when to release, so going live is a business decision; continuous deployment removes that gate and every change passing the pipeline goes straight to production. Conflating the two leads teams to claim 'continuous deployment' while still requiring manual approvals — or to auto-ship before they have the test coverage and rollback safety it demands.

A canary exposes the new version to a small percentage of real users and ramps up only if metrics stay healthy, so problems hit few users and you watch live signal before committing. Blue-green keeps two full environments and flips all traffic from the old (blue) to the new (green) in one cut, giving an instant all-or-nothing switch and an instant switch-back to roll back. Blue-green needs double the capacity; canary needs traffic-splitting and good observability. Both can roll back — the difference is gradual-by-percentage versus atomic-full-switch.

Artifacts and caches look similar but serve opposite contracts. An artifact is the required output of one job handed to a downstream job — without it the downstream job fails (a compiled binary, a built image manifest, a coverage report). A cache is a best-effort optimisation: dependency downloads or build intermediates that, on a miss, are simply rebuilt with no correctness impact, only slower. Treating a needed build output as a cache is dangerous because a cache miss or eviction silently breaks the dependent job; secrets belong in a secret store, never either mechanism.

Fail-fast means giving the developer the quickest possible signal: order cheap, deterministic checks first so a lint error or a broken unit test fails the pipeline in seconds, before you spend minutes on an end-to-end suite or a scan. Running the slow stage first wastes compute and delays feedback when an early check would have caught the problem. Ordering still matters even with parallelism, because you gate expensive stages behind cheap ones to avoid paying for runs that were already doomed. The payoff is faster feedback loops and lower CI cost.

With OIDC, the CI provider presents a signed identity token for the specific workflow run and the cloud provider exchanges it for short-lived, scoped credentials via a trust policy — nothing long-lived is stored in CI, and the credential expires on its own. A stored long-lived access key is a standing liability: it sits in CI secrets, can be exfiltrated by a malicious dependency or a misconfigured workflow, and stays valid until someone manually rotates it. OIDC tokens are still sent over the network and the cloud still authenticates; the win is no durable secret and automatic expiry, which shrinks the blast radius of a leak.

Supply-chain hardening is about provenance and least privilege. Pinning dependencies and actions to an immutable commit SHA stops an attacker who repoints a mutable tag (a common attack) from injecting code into your build. Signed provenance/attestations let downstream consumers verify an artifact really came from your trusted build, the core idea behind SLSA. The two distractors are the opposite of hardening: broad token permissions widen the blast radius of any compromised step (least privilege is the rule), and unrestricted egress lets a malicious step exfiltrate secrets or pull attacker-controlled payloads. 'Make it never fail' and 'let it reach anything' are convenience choices that trade away security.

True. CI is a practice, not a tool: the discipline is integrating small changes into a shared mainline often — ideally several times a day — so that conflicts and breakages are found while they are tiny and cheap to fix, verified by an automated build and test on every integration. A common misconception is that installing a CI server (or running tests on long-lived feature branches that merge once a month) 'is' CI. Without frequent integration into the mainline you still get the big, painful 'merge hell' that CI exists to eliminate, no matter how good the test automation is.

The mechanism is two parallel environments and an atomic traffic switch, with the old one kept warm for instant rollback. The signal in the answer is naming honest tradeoffs: doubled capacity cost, an all-or-nothing blast radius (vs a canary's gradual ramp), and the hard part everyone forgets — database/schema compatibility and session draining across both versions. Candidates who only recite 'switch from blue to green' without the cost and stateful-data caveats haven't run it in production.

The core idea is that the pipeline definition is source-controlled alongside the application, so it gets the same review, history, and reproducibility as any other code. The practical payoff — and the usual interview follow-up — is auditability and disaster recovery: a UI-clicked pipeline has no diff, no review, and vanishes with the server, whereas pipeline-as-code is just another file you can restore, branch, and roll back.

The canonical flow is build once, then verify, then ship: a push triggers the pipeline; the code is compiled/packaged into a single versioned artifact; that exact artifact is tested and run through quality and security gates; only if every gate passes is it deployed. Building one immutable artifact and promoting it (rather than rebuilding per stage) is what guarantees you ship what you tested. Putting deploy before the gates, or rebuilding at each stage, breaks that guarantee — you'd risk shipping something that was never the thing you validated.

Keying the cache on a hash of the lockfile (e.g. hashFiles('**/package-lock.json')) means the key only changes when the dependency set changes, so unchanged dependencies hit the cache and the entry refreshes when they do change. restore-keys is the fallback list: when the exact key misses, the runner matches a prefix and restores the closest older cache, so you reuse most of it and only download the delta rather than rebuilding from scratch. A fixed, non-hashed key never updates; omitting restore-keys turns every dependency bump into a full cold download.

The make-or-break insight is build-once-promote-many: a single immutable, SHA-versioned artifact flows through every environment so production runs exactly what staging tested, with environment differences pushed into deploy-time config/secrets rather than separate builds. Strong answers gate promotions (automated checks everywhere, a human approval before prod), inject secrets via short-lived credentials, and make rollback a redeploy of the previous good version with expand-contract migrations so it's actually safe. Candidates who rebuild per environment or whose only recovery is a hotfix haven't operated a real promotion pipeline.

pull_request_target runs in the context of the base repository, so it has access to repository secrets even for a pull request from a fork — unlike the normal pull_request trigger. The fatal combination here is then checking out and running the PR's own code (github.event.pull_request.head.sha) with npm install && npm test: an attacker opens a PR with a malicious package.json script or test that reads secrets.DEPLOY_KEY from the environment and ships it to an attacker server. GitHub's own guidance is to never check out or execute untrusted PR code in a pull_request_target workflow that holds secrets. Pinning checkout, using npm ci, or the runner image are red herrings — the bug is executing untrusted code with secret access.

The trap is that retrying makes the dashboard green while leaving a non-deterministic test in place — which erodes trust in the suite and can retry away a real regression. The mature answer: detect/track flakes, quarantine them so they report without blocking, and fix the root cause (races, shared state, real clocks/network) under an SLA before un-quarantining. Naming concrete causes and the quarantine-plus-fix discipline is what separates someone who has stabilised a flaky suite from someone who just adds retries: 3.

A canary is deploy, expose a little, measure, ramp, then commit: the new version goes out taking no traffic, a small percentage is routed to it, its live metrics (errors, latency, saturation) are compared to the stable baseline, and only if it stays healthy is traffic increased step by step until it serves everything — otherwise the analysis triggers an automatic rollback. The measure-before-ramp ordering is the whole point: skipping the comparison and ramping blind turns a canary into an ordinary risky rollout, defeating the limited-blast-radius benefit.