Companion question bank for the 3-part tutorial series in this folder: 01-cicd-fundamentals.md, 02-infrastructure-as-code.md, 03-gitops.md.

Answers are short and plain — expand out loud using the diagrams and worked examples in the tutorials.

---

Part 1 Questions: CI/CD Fundamentals

1. What is Continuous Integration, in one sentence?#

Developers merge small code changes frequently, with an automated process building and testing every single merge immediately — shift-left applied to integration bugs.

2. Distinguish Continuous Delivery from Continuous Deployment.#

Delivery: every change that passes CI is automatically made ready to deploy, but a human still decides when to actually release it. Deployment: that human gate is removed too — every passing change goes live automatically. Most real organizations practice Delivery, not full Deployment.

3. Why should pipeline stages run cheapest/fastest first?#

So a broken build fails and reports back within seconds, not after waiting many minutes for a slow test suite to even start — the same "fail fast, cheap checks first" principle from the DevSecOps series' layered scanning pipeline.

4. Compare the four deployment strategies in one line each.#

Recreate: stop everything old, then start everything new (causes downtime). Rolling: gradually replace instances, no downtime, but both versions briefly coexist. Blue-Green: two full environments, instant traffic switch and near-instant rollback, but double infrastructure cost. Canary: small % of traffic to the new version first, limiting blast radius.

5. Why is blue-green's rollback meaningfully faster than a rolling deployment's rollback?#

Rolling back a blue-green switch just means flipping the router back to the still-running old environment — near-instant. Rolling back a rolling deployment means running the same gradual replacement process again in reverse, which takes real time proportional to fleet size.

6. Why does a canary deployment connect to the error budget concept?#

By exposing only a small % of traffic to a risky change, a team deliberately spends a small, controlled sliver of error budget to validate it — rather than exposing 100% of users and burning a much larger chunk of budget to find the same bug.

7. What's the difference between a canary deployment and a feature flag?#

A canary controls what % of traffic hits NEW CODE. A feature flag controls what % of traffic sees NEW BEHAVIOR, even within the exact same running code. They're complementary — you can canary-deploy code that itself contains a feature flag.

8. Why do feature flags matter for rollback risk specifically?#

They decouple deploying code from releasing a feature — a bad feature can be disabled instantly by flipping a flag, with no new deploy (and none of a deploy's associated risk) needed at all.

9. Name the four DORA/Four Keys metrics.#

Deployment Frequency, Lead Time for Changes, Change Failure Rate, Time to Restore Service.

10. What's DORA's counter-intuitive finding about speed vs. stability?#

Elite performers are simultaneously fast (frequent deploys, short lead time) AND stable (low change failure rate, fast recovery) — speed and stability aren't actually a tradeoff at the organizational level, contradicting the instinct that "moving fast breaks things."

---

Part 2 Questions: Infrastructure as Code

11. What problem does Infrastructure as Code solve?#

It replaces manual, undocumented, click-through-the-console infrastructure changes with version-controlled, reviewable, auditable code — directly attacking the "toil" problem from the SRE Fundamentals series, applied to infrastructure.

12. Distinguish provisioning from configuration management, with example tools.#

Provisioning creates the actual infrastructure itself (Terraform, CloudFormation). Configuration management configures what runs ON already-existing infrastructure (Ansible, Chef, Puppet).

13. What is idempotency, and why is it the single most important IaC property?#

Running the same operation any number of times produces the same end result as running it once. It's what makes IaC safe to re-run after a failure or partial success — the exact same underlying philosophy as the Kubernetes reconciliation loop.

14. Why is terraform plan such an important safety step?#

It's a dry run showing exactly what will be created, changed, or destroyed BEFORE anything actually happens — giving a human (or an automated policy gate) a chance to catch a mistake before it becomes real, potentially irreversible damage.

15. Why does losing the Terraform state file matter so much?#

It's Terraform's only record connecting your code to the specific real resources it created. Without it, a re-run could create duplicate resources or fail to recognize existing ones — a small file with outsized, critical importance.

16. Why does Terraform need state locking, not just remote state?#

Two simultaneous apply operations against the same unlocked shared state can write conflicting updates, corrupting it. Locking blocks a second apply until the first one completes and releases the lock.

17. What is drift, and what usually causes it?#

Reality (the real infrastructure) no longer matching what the code/state believes it should be — usually caused by someone making a manual change directly in the cloud console, bypassing the IaC tool entirely.

18. What's the practical discipline for preventing drift with plain Terraform?#

Treat the code as the sole source of truth and never make manual console changes to anything Terraform manages — every change goes through plan/review/apply. (GitOps, Part 3, enforces this even more strictly and automatically.)

19. Why are Terraform and Ansible often used together rather than as substitutes?#

They solve genuinely different jobs — Terraform provisions the infrastructure (the VM, the network), Ansible configures what runs on it once it exists. A common pattern: Terraform creates the servers, Ansible configures them.

20. Is Ansible agent-based or agentless, and why does that matter?#

Agentless — it connects over standard SSH and runs remotely, with no permanent agent software needing to be pre-installed on target servers, a real, distinctive difference from some other configuration management tools.

---

Part 3 Questions: GitOps

21. What's the core idea that distinguishes GitOps from "just using IaC"?#

Git becomes the single, ENFORCED source of truth, with a dedicated tool continuously and automatically reconciling actual state to match it — not just "infrastructure is defined in code," but a tool actively, continuously enforcing that the code IS what's running.

22. Name the four GitOps principles.#

Declarative, versioned and immutable (stored in Git), pulled automatically (agents pull, rather than being pushed to), continuously reconciled.

23. What's the difference between push-based and pull-based deployment?#

Push: an external CI pipeline actively pushes changes to the cluster, holding standing production credentials to do so. Pull: an agent running INSIDE the cluster continuously watches Git and applies changes itself — nothing external needs any credentials to modify the cluster.

24. Why is the pull-based model considered more secure, tied to a real-world incident?#

It eliminates the need for any external system (like a CI pipeline) to hold standing production write credentials — directly reducing the exact class of supply-chain attack surface that enabled the SolarWinds incident, where a compromised build system had a direct path to modify what customers trusted.

25. What are ArgoCD and Flux, and what do they have in common?#

The two dominant GitOps tools for Kubernetes, both CNCF projects implementing the same core reconciliation principles — continuously comparing Git's desired state against the live cluster and converging any difference.

26. What do ArgoCD's prune: true and selfHeal: true settings actually do?#

prune: if something is removed from Git, it gets deleted from the real cluster too. selfHeal: if someone manually changes something directly in the cluster (drift), it's automatically reverted back to match Git on the next reconciliation pass.

27. How does GitOps's self-healing improve on plain Terraform's drift-prevention approach?#

Plain Terraform relies on team DISCIPLINE — everyone consistently choosing to go through code, never the console. GitOps self-healing is AUTOMATICALLY, CONTINUOUSLY enforced by the tool itself, not just relied upon from every individual engineer.

28. How does multi-environment promotion typically work in a GitOps workflow?#

It's just a Git commit/PR updating a value (like an image tag) in the target environment's directory — fully auditable, fully reversible, requiring no special tooling beyond Git and the GitOps agent already watching the repo.

29. Why do secrets create a genuine tension with GitOps's "everything in Git" principle, and how is it resolved?#

Git is fundamentally the wrong place for raw secrets (deleting one doesn't remove it from history). Resolved via Sealed Secrets (the value is encrypted before committing, decryptable only by the target cluster) or External Secrets Operator (Git stores only a reference/pointer; the actual value is fetched live from a real secrets manager like Vault).

30. How does a rollback work in GitOps, and why is that a strong answer?#

git revert on the bad commit — the GitOps agent sees the reverted commit as the new desired state and automatically reconciles the cluster back to the previous, known-good configuration. It's strong because it reuses the exact same, already-trusted mechanism (Git history) as every other change, with no special rollback tooling needed.

31. Why does GitOps give a strong disaster recovery story "almost for free"?#

Since Git already is the complete, declarative source of truth for everything that should exist, recovering from a total cluster loss is just pointing a brand-new cluster's agent at the same repo — the same reconciliation loop that handles everyday drift correction does the entire rebuild automatically.

---

Quick-Fire / Rapid Recall#