Checkpoint A: Your Delivery Pipeline

You have completed Chapters 01-05. Before moving into runtime hardening, pause and look at what you have built.

This page is a consolidation — not new material. Its purpose is to show you the assembled delivery pipeline and the guardrails you can now rely on.

What You Have Built

You can now deliver code from a developer workstation to a Kubernetes cluster through a fully guarded pipeline:

Workstation ─► Git ─► CI ─► Review ─► Flux ─► Cluster
    │           │       │      │        │        │
    │           │       │      │        │        └── Chapter 04: GitOps reconciliation
    │           │       │      │        └─────────── Chapter 03: SOPS-encrypted secrets decrypted inside the cluster
    │           │       │      └──────────────────── Chapter 05: AI-assisted review + human approval gate
    │           │       └─────────────────────────── Chapter 05: Plan-Approve-Apply in GitHub Actions
    │           └─────────────────────────────────── Chapter 02: Terraform plan-review-apply with state locking
    └─────────────────────────────────────────────── Chapter 01: Context verification + one-change-per-PR

The Guardrails You Have in Place

After five chapters, these are the non-negotiable rules protecting your pipeline:

Guardrail	Source	What It Prevents
One change per PR	Chapter 01	Correlated blast radius
`guard-kube-context.sh`	Chapter 01	Wrong cluster or namespace writes
`guard-terraform-plan.sh`	Chapter 01, 02	Unplanned or stale applies
SOPS + Age encryption	Chapter 03	Plaintext secrets in Git history
GitOps reconciliation	Chapter 04	Manual kubectl drift
Pre-commit hooks	Chapter 05	Invalid manifests, leaked secrets, direct-to-main commits
Plan-Approve-Apply	Chapter 05	Automated infrastructure mutation without human sign-off

Self-Check

You are ready for Chapter 06 when you can answer without looking:

Where does context verification happen in the pipeline? At what stages?
What is the difference between a stale plan and a fresh plan, and why does it matter?
If a plaintext secret is accidentally committed, what is the full response sequence?
How does Flux know which image to deploy to each environment?
Which layer catches a git commit --no-verify bypass, and why is that layer also not the last one?

If any of these are unclear, revisit the relevant chapter before moving forward.

What Comes Next

The next block (Chapters 06-09) shifts from how code reaches the cluster to how workloads behave inside the cluster:

Chapter 06 — Network Policies: who can talk to whom
Chapter 07 — Security Context: how pods run with minimum privilege
Chapter 08 — Resource Management: how CPU and memory are shared
Chapter 09 — Availability Engineering: how services survive disruption

These four chapters layer runtime constraints onto the safely-deployed workloads you now know how to ship.