Continuous Integration and Continuous Delivery (CI/CD) Pipelines
This domain tests pipeline design: how a commit becomes one immutable artifact, how that artifact is verified by automated gates, and how it is promoted through environments. Expect questions on pipeline-as-code structure, artifact handling, deployment strategies, and DORA delivery metrics.
Core rules
- Build once, deploy many. Compile and package once; promote by digest or checksum. Rebuilding per environment invalidates every test result you produced earlier.
- Pipeline as code lives in the repository beside the code, is code-reviewed, and is versioned with the commit it builds.
- Typical stage order: checkout → lint/unit → build → scan (SCA, SAST, image) → integration/contract tests → publish artifact + SBOM + signature → deploy to staging → smoke/E2E → approval → progressive production rollout.
- Fast feedback ordering: cheapest, most-likely-to-fail checks first; parallelise independent jobs; cache dependencies keyed on a lockfile hash.
- Ephemeral runners; no long-lived cloud keys - federate via OIDC and scope the trust policy to a repository and branch.
- Deployment strategies: rolling, blue/green, canary with automated analysis. Every deploy needs a rollback or forward-fix path, and schema migrations must be backward-compatible (expand/contract).
- DORA measures: deployment frequency, change lead time, change failure rate, failed deployment recovery time, plus deployment rework rate.
Worked example
A team's CI builds the jar in staging and builds it again for production from the same commit. Production fails on a dependency that resolved to a newer patch release. Reasoning: the artifact tested is not the artifact shipped, so every gate result is void, and change lead time becomes incomparable across runs. Fix: build once, publish to a registry under an immutable tag (the git SHA), sign it with cosign, attach an SBOM and provenance, and have each environment pull by digest. Gates then attach to a digest rather than to a branch name.
Traps
- Treating "pipeline green" as deployment success - confirm with a post-deploy smoke test and a real SLO signal.
- Adding manual approval gates everywhere, which inflates change lead time without measurably reducing risk; prefer automated evidence.
- Retagging
latest, or rebuilding for hotfixes, which bypasses scanning and signing. - Running end-to-end suites on every commit so feedback arrives after the developer has moved on.