Lesson 18 · Senior CI/CD judgment
Senior CI/CD interview questions
High-signal questions about delivery flow, guardrails, runners, supply chain, and rollback judgment — with answer structures that sound like real operational experience.
Your win: answer senior CI/CD questions with mechanism + trade-off + repo-grounded consequence, not just broad DevOps slogans or tool-name recitation.
Why these questions feel different
The base course taught the delivery system itself. This page asks whether you can defend that system honestly, especially where it is partial, batched, or operationally nuanced. That makes the answers sound less like memorized definitions and more like judgment.
The strongest answers here usually do three things: name the mechanism, name the trade-off or weakness, and connect it to a concrete repo consequence. That structure is what makes the answer sound credible in a senior interview.
How to get the most out of this page
Do not read the table passively. Cover the right-hand column and answer each question out loud first. Then compare your version with the answer shape. If your answer names the mechanism but misses the trade-off, you are still one layer short. If it names the trade-off but never grounds it in this repo, it may sound generic rather than credible.
The goal is not to memorize the exact wording below. The goal is to train the answer shape until it feels natural.
Question bank
| Question | Best answer shape |
|---|---|
| Why is “merge deploys” an inaccurate summary of this repo? | Because merge to develop creates a release tag, then a later cron picks it up for staging build/deploy, while prod remains manual dispatch. |
| What does the `diff` router buy you in a monorepo? | Selective execution: most PRs skip most jobs, keeping CI cost and latency lower without dropping required-check enforcement. |
| Why is Binary Authorization not a full hard gate here? | Because attestations are created, but policy enforcement is `DRYRUN_AUDIT_LOG_ONLY`, so the mechanism exists without blocking runtime admission. |
| Why is OIDC/WIF a meaningful CI security improvement? | It removes long-lived cloud keys from CI and replaces them with short-lived identity exchange for specific jobs. |
| What is the honest rollback story in this repo? | Rollback means manually redeploying a known previous release tag through the push-based deploy path, which is clear and auditable but still depends on detection speed and rollout spread. |
| Why use `cancel-in-progress: true` in CI but false in deploy? | CI should drop stale runs; deploy should never interrupt a live rollout and risk a half-updated cluster. |
| Why does this repo use composite actions instead of reusable workflows so heavily? | Because many of its reuse points are step-shaped building blocks, combined with dispatch chaining between workflows rather than `workflow_call`. |
| What makes an ARC runner strategy operationally valuable? | Autoscaling self-hosted runners, job-shaped sizing, and dind/kind capability where needed — if that complexity clearly supports repo workload patterns. |
| What is the senior risk of partial guardrails? | False confidence: the team may believe the pipeline enforces controls more strongly than it actually does. |
| What should a senior CI/CD review ask first? | What the pipeline truly guarantees, where it is partial or misleading, and how recoverable the failure modes are. |
Use the playbook and repo map together
The playbook compresses the judgment layer; the repo map gives you the concrete paths and behaviors that make answers sound real.
Check yourself (from memory)
Q1. A strong senior CI/CD answer usually includes…
Sources. Repo CI/CD map; curated CI/CD resources.