Lesson 19 · Senior CI/CD judgment
Mock senior CI/CD interview pack
A retrieval-first mock pack for turning the whole CI/CD course into clear, interview-grade answers you can say under pressure.
Your win: run a realistic senior CI/CD mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.
Why this mock is really training something important
A lot of people think they know CI/CD because the pages feel familiar when they reread them. But recognition is not the same thing as retrieval. Interviews punish that gap immediately. So this page is not just a recap page. It is the page that forces the course back out of your head in spoken form.
That is why the rule here is simple: answer first, check later. If you peek too early, you train recognition instead of recall.
The format
This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.
- Round 1 · Delivery flow and CI gates — 6 questions
- Round 2 · Security and supply-chain realism — 6 questions
- Round 3 · Rollback, runners, and review judgment — 6 questions
- Time target — 60–90 seconds per answer
Round 1 · Delivery flow and CI gates
- Why is “merge deploys staging” too vague for this repo?
- What problem does the `diff` router solve?
- Why is `Ok to test` important operationally?
- Why does the repo prefer composite actions so heavily?
- What makes the deploy chain trunk-based but not immediate?
- Why is push-based delivery a real trade-off instead of a default good?
- Truthfulness. Merge creates a tag; a later cron picks it up for staging build/deploy; prod is manual.
- Selective CI. The router avoids rebuilding the whole monorepo on every PR while preserving required checks.
- Intent gate. `Ok to test` keeps expensive CI from auto-running on every PR state without explicit readiness.
- Reuse shape. Step-shaped reuse fits composite actions; cross-workflow chaining happens with dispatch rather than `workflow_call`.
- Trunk cadence. Small merges go to one trunk, but deployment is still batched through tags and schedule.
- Push-based trade-off. Simpler explicit deploys, but no in-cluster GitOps reconciliation or automatic drift healing.
Round 2 · Security and supply-chain realism
- Why is OIDC/WIF a maturity improvement over static keys?
- What is the difference between attestation creation and admission enforcement?
- Why is audit-only Binary Authorization still worth talking about?
- What is the main danger of partial guardrails?
- How would you summarize the repo’s CI/CD security posture honestly?
- Why isn’t “manual prod deploy” enough to call a pipeline secure?
- Short-lived identity. Jobs exchange identity dynamically instead of storing durable cloud keys.
- Proof vs gate. Attestation proves artifact lineage; enforcement decides whether admission is blocked.
- Useful partial state. Audit-only still builds process, evidence, and future enforcement readiness — but is not a hard stop.
- False confidence. Teams may overestimate what risks are truly prevented.
- Honest posture. Keyless auth is strong, supply-chain proof exists, enforcement is partial.
- Manual is not security. Human approval may slow release, but it does not replace identity, artifact integrity, or policy enforcement.
Round 3 · Rollback, runners, and review judgment
- What is the honest rollback story here?
- Why does deploy use `cancel-in-progress: false`?
- What makes ARC operationally useful in this repo?
- How does the org matrix change blast-radius thinking?
- What would you look for when reviewing a CI/CD design?
- How would you summarize this repo’s overall delivery philosophy honestly?
- Rollback. Redeploy a known older release tag through the same push-based path; clear but dependent on detection speed.
- Do not interrupt rollout. Canceling an in-flight deploy risks a half-updated system.
- Runner value. ARC provides autoscaling self-hosted capacity, dynamic sizing, and dind/kind capability for heavy jobs.
- Blast radius. Fan-out improves throughput but can widen exposure if issues are not caught early.
- Review lens. Ask what is truly guaranteed, what is partial, how recoverable failures are, and how understandable the pipeline remains under pressure.
- Delivery philosophy. Practical push-based delivery with real guardrails, real trade-offs, and honest gaps rather than idealized automation claims.
Self-scoring rubric
| Score | Meaning |
|---|---|
| 0 | I could not explain it without notes. |
| 1 | I gave fragments, but the answer was incomplete or fuzzy. |
| 2 | I explained the main idea, but missed the trade-off, weakness, or repo consequence. |
| 3 | I gave a strong, clear answer with mechanism + trade-off/weakness + repo consequence. |
What this mock is really training
It is training answer shape under pressure. Can you start with the mechanism? Can you name the weakness honestly? Can you land the answer in a repo-grounded consequence instead of floating at the level of DevOps slogans? That is the difference between “I studied the topic” and “I can defend the system out loud.”
So do not aim for perfection on the first pass. Aim for honest retrieval, then use the answer points to tighten the structure.
Q1. The main rule of this mock pack is…
Sources. This pack synthesizes the whole course into retrieval practice.