CI/CD Pipelines — Stages, Artifacts, Caching & Supply Chain
Interview hub on CI/CD pipeline design: stages/gates, immutable artifacts, CI speed, branching/previews, and supply-chain controls (OIDC/SBOM/signing).
- 1Gist
- 2Maps
- 3Q&A
- 4Sandbox
Voice readout needs Web Speech Synthesis in this browser.
A service is about to ship to production
Prefer
Build once, promote the digest
CI produces one immutable artifact, attests it, and later environments pull that same digest. Config arrives at runtime.
- Staging green is evidence about the bits production will run.
- Rollback is a previous digest, with a signature and an SBOM still attached.
- The audit question has one answer: this commit, this builder, this digest.
Alternative
Rebuild in each environment
Each stage compiles again so it can bake env flags into the binary. Staging and production become cousins.
- A green staging run validated a different artifact.
- Floating lockfiles can pick different dependencies on the second build.
- Incident response cannot say which bytes were live.
What must be true before this change can hurt production
The source decision tree branches on pass and fail. This ladder is the same rule in one column: cheap signal, one digest, attestations, then a promotion gate.
- 1
Fail fast
Lint, types, and unit tests stop the change before an image build. - 2
Build one artifact
Push an immutable digest. Record it as a pipeline output. - 3
Attest or block
Digest, SBOM, and signature are present, or promotion stops. - 4
Prove the digest
Integration, contract, and scan run against the thing you will ship. - 5
Promote, then watch
Preview or staging uses that digest. Production reuses it after the gate. Observe and roll back the same way.
Overview
A pipeline is a productized path from commit to running software. Stages and gates decide when something may promote. Artifacts and digests define what is promoted. Caching and parallelism decide how fast you get signal. Branching and previews decide where humans look. Signing, SBOMs, and OIDC decide whether you can trust the bits.
CI/CD is a control plane for change. It is the policy around .github/workflows, not the YAML file itself. Every stage has a cost curve: lint is seconds, a full end-to-end suite is minutes, and production promotion may wait on a human or on a progressive traffic shift.
Slow CI trains people to skip checks. Flaky CI trains people to ignore red. Insecure CI trains attackers to inject. Senior interviews ask whether you can trade trunk-based flow against long-lived branches, mutable tags against digests, self-hosted runners against OIDC to cloud, and "build once" against a rebuild per environment.
Ask this before you add a stage: what must be true before this change can hurt production, and how do we prove it cheaply?
Pipeline shapes
| Shape | Strength | Weakness | Prefer when |
|---|---|---|---|
| Classic staged (build, test, scan, deploy) | Clear gates, easy audit | Long critical path if every job is serial | Most services |
| Fan-out / matrix | Parallel OS and language coverage | Cache-miss storms, flake amplification | Libraries, multi-arch |
| Build once, promote many | Same bits everywhere | Needs an immutable registry | Prod-critical apps |
| Rebuild per environment | Easy env-specific compile flags | Drift, and "works in staging" lies | Avoid for prod binaries |
| Progressive delivery | Limits blast radius | Needs metrics and an automated rollback | User-facing traffic |
Progressive delivery on this page is a pipeline gate: the digest is eligible to roll. The traffic split itself is Rolling, Blue-Green and Canary. This cluster does not re-teach Deployments, probes, or autoscaling.
Flow
- 1
1. Commit or pull request
- next2. Fail fast on cheap checks
- 2
2. Fail fast on cheap checks
- next3. Build one immutable digest
- 3
3. Build one immutable digest
- next4. Attest SBOM and signature
- 4
4. Attest SBOM and signature
- next5. Test and scan the artifact
- 5
5. Test and scan the artifact
- next6. Preview or stage that digest
- 6
6. Preview or stage that digest
- next7. Prod gate keeps the digest
- 7
7. Prod gate keeps the digest
- next8. Observe and roll back
- 8
8. Observe and roll back
Lesson map
CI/CD Pipelines — Stages, Artifacts, Caching & Supply Chain
Interview hub on CI/CD pipeline design: stages/gates, immutable artifacts, CI speed, branching/previews, and supply-chain controls (OIDC/SBOM/signing).
Architecture. Architecture
Select a node to see why it exists, or an edge to see the protocol, direction, effect, and consequence.
Mermaid export
flowchart TB a["1. Commit or pull request"] b["2. Fail fast on cheap checks"] c["3. Build one immutable digest"] d["4. Attest SBOM and signature"] a -->|1. Commit or pull request| b b -->|2. Fail fast on cheap checks| c c -->|3. Build one immutable digest| d
Rule of thumb: build once, attest once, promote the same digest. Rebuild only for a genuine multi-target need, such as a second architecture. Do not rebuild to inject staging config.
What the rest of the cluster adds
- Pipeline Anatomy — stages, jobs, steps, soft versus hard gates, and environment promotion.
- Artifacts and Registries — tags versus digests, SLSA provenance, immutability, and the handoff between jobs.
- CI Performance — cache keys, sharding, path filters, and the cost of a flaky job.
- Branching, Previews and Promotion — trunk-based versus GitFlow, ephemeral previews, and the promotion state machine.
- Supply Chain Security — OIDC federation, cosign, SBOMs, and fail-closed admit checks.
What stays in other clusters
Pipeline design and artifact trust live here. Three neighbors are easy to drag into the same interview answer. Leave them where they are.
- Kubernetes workloads. Desired-state controllers, probes, requests and limits, and replica autoscaling live in Kubernetes Workloads. When the question is "who shifts traffic after the digest is eligible," answer from Rolling, Blue-Green and Canary. The pipeline's job ends at eligibility, the digest, and the policy that allows the rollout.
- Test flakes. Time, shared state, order dependence, and quarantine ownership live in Flaky Tests. This cluster only covers the CI view: a flaky job burns trust in red builds, retries need a cap, and the owner sits with the suite.
- Schema migrations. Expand/contract ordering is a pipeline gate, named on the anatomy page. The migration mechanics stay in the database cluster.
Rebuild per environment
Rebuilding in each environment makes env-specific compile flags feel easy, and small teams ship that way for a while.
The bill shows up later. Staging green does not prove the production bits. "Which commit built prod?" becomes "which rebuild?" Each rebuild can pick different dependencies if lockfiles float, so the attack surface grows with every environment.
The alternative is one artifact digest, config through the environment or a runtime flag service, and a policy gate that promotes the digest. That split is the artifacts lesson and the branching lesson.
Choose the next move
The sandboxes encode the hub rule. They do not call a registry. They only name the next legal move for a digest you already described.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Press Run. Snippets must be self-contained — no network, files, or native modules.
Interview Q&A
What is the difference between CI and CD?
Answer
CI continuously integrates and validates changes: build, test, and scan on every commit or pull request. CD automates delivery. Continuous delivery stops at a production-ready artifact waiting on a gate. Continuous deployment pushes through to production when the gates pass.
Why build once and promote many times?
Answer
Confidence transfers with the bits. If staging and production are different builds, you validated a cousin of production. Promote the digest you already ran.
Tag latest versus a digest. Which one is for production?
Answer
The digest, or a tag the registry refuses to move. latest is mutable, so rollback and audit both lie. A human tag such as v1.2.3 is fine after immutability is enforced. The registry lesson is the full comparison.
Where do progressive delivery and pipelines meet?
Answer
The pipeline produces a signed digest and decides eligibility. Progressive controllers decide the traffic split. Deployments, probes, and autoscaling are the Kubernetes Workloads cluster. The traffic page is Rolling, Blue-Green and Canary.
Self-hosted runners versus GitHub-hosted plus OIDC?
Answer
Self-hosted runners buy cache locality and special hardware, and they raise the patch and compromise cost. Hosted runners plus OIDC buy short-lived cloud credentials and less secret sprawl, with cold starts and minute quotas. Prefer OIDC over long-lived cloud keys on either topology. Federation details are the supply-chain lesson.
How do you keep pull-request CI around 10 to 15 minutes?
Answer
Cache on the lockfile and the runtime, select tests from a dependency graph, shard by duration, skip docs-only work with path filters, quarantine flakes with an owner, and move the heavy suites behind a label or the merge queue. Mechanics are the CI performance lesson. Flake isolation is Flaky Tests.
What is an SBOM, and why attach it in CI?
Answer
A software bill of materials is the inventory of components. Attach it, and preferably sign it, at build time so CVE response and license policy can query what shipped.
How does OIDC federation remove static cloud keys from CI?
Answer
The CI provider mints a short-lived token. The cloud identity provider trusts the issuer and the subject claims (repository, ref, environment) and issues temporary credentials. The deploy role does not need a long-lived access key in repository secrets.
Trunk-based versus GitFlow for CD?
Answer
Trunk-based development with short-lived pull requests maximizes delivery frequency and shrinks merge debt. GitFlow's long-lived release branches fit versioned products with a freeze window, and they slow feedback and multiply hotfix paths. The branching lesson is the comparison.
Name one metric for pipeline health.
Answer
Keep a small set: p50 and p95 time-to-green on pull requests, change-fail rate, mean time to restore, and the share of production deploys that promote a digest already staged. Ad-hoc rebuilds of main are the number you want to drive down.
What should you say in the first minute?
Answer
Stages decide when. Digests decide what. Caches decide how fast the signal returns. Previews decide where humans look. Signatures, SBOMs, and OIDC decide whether the bits are trustworthy. Traffic shifting and test isolation are neighboring clusters.
Pitfalls
- Treating the workflow file as the design, with no story for the digest that production runs.
- Rebuilding in the production job "with the prod flag" and calling staging proof.
- A
latesttag that moves under a running environment. - Retry-until-green as the flake policy.
- A progressive-delivery answer that explains replica surge instead of the eligibility gate.
A staff engineer asks how a change gets to production. Answer with the gate that can block it, the digest that must not change, one way you keep pull-request time under a quarter hour, and where signing or OIDC fits. Leave replica counts and probe timeouts for the Kubernetes cluster.