Quiz: CI/CD & Developer Guardrails

Instructions

Answer each question. Review your answers against the chapter material before proceeding.

Q1: Why are pre-commit hooks not sufficient as the only guardrail layer?

A) They are too slow to run locally B) Developers can bypass them with --no-verify and they only run on the committer’s machine C) They cannot validate YAML syntax D) They require internet access to function

Q2: What does cancel-in-progress: false protect against in the Terraform CI pipeline?

A) Prevents multiple developers from pushing simultaneously B) Prevents a running infrastructure apply from being cancelled by a newer push C) Prevents plan jobs from running in parallel D) Prevents branch deletion during apply

Q3: Why does the approval gate have a 60-minute timeout?

A) Terraform plans expire after 60 minutes B) To prevent stale plans from being applied long after review context has changed C) GitHub Actions has a maximum job duration of 60 minutes D) To reduce CI costs

Q4: What is the purpose of uploading the tfplan artifact with 1-day retention?

A) To save storage costs B) To ensure the apply job executes the exact plan that was reviewed, not a regenerated one C) To allow multiple apply attempts from the same plan D) To provide audit logs for compliance

Q5: What does CodeRabbit’s “chill” profile mean?

A) It only reviews code on Fridays B) It uses a non-aggressive review tone, focusing on real issues rather than nitpicks C) It skips security scanning D) It only reviews files under 100 lines

Q6: In the guardrails layering model, what does the cluster admission layer (Kyverno) catch that CI cannot?

A) YAML syntax errors B) Terraform formatting issues C) Manifests applied directly to the cluster bypassing Git and CI entirely D) Shell script bugs

Q7: Why does the destroy workflow require a confirmation string (“DESTROY”)?

A) To prevent accidental trigger from automated systems or misclicks B) To verify the user has admin permissions C) To ensure the workflow runs slowly D) To log the destroy request

Q8: What 3-stage validation does flux-kustomize-validate.sh perform?

A) Lint, format, deploy B) YAML syntax check, kustomize build, kubeconform schema validation C) Pull, build, push D) Init, plan, apply

Q9: Why should block-secrets.sh run as a pre-commit hook rather than only in CI?

A) CI cannot scan for secrets B) Once a secret is committed and pushed, it exists in Git history even if the commit is later reverted C) Pre-commit hooks are faster than CI D) Secrets are only dangerous locally

Q10: A developer argues: “I’ll just skip hooks this once with --no-verify because my change is trivial.” What is the correct response?

A) Allow it — trivial changes don’t need validation B) Allow it — CI will catch any issues C) Deny it — bypassing any layer weakens the entire model, and “trivial” changes have caused production incidents D) Allow it — but require a second reviewer

Answer Key

1. B — --no-verify bypasses hooks, and they only protect the local machine.
2. B — Running applies must not be interrupted by newer pushes.
3. B — Stale plans lose their review context and may apply outdated changes.
4. B — The reviewed plan artifact is passed exactly to apply, preventing plan drift.
5. B — Non-aggressive, real-issues-focused review tone.
6. C — Admission policies catch direct cluster mutations that never went through Git.
7. A — Explicit confirmation prevents accidental destruction.
8. B — YAML syntax, kustomize build, kubeconform validation.
9. B — Secrets in Git history persist even after revert; prevention beats remediation.
10. C — No layer should be bypassed; trivial changes cause incidents too.