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 03: GitOps reconciliation
    │           │       │      │        └─────────── Chapter 04: 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. Read the last column carefully: the platform repository has every one of them, but your fork copied its code, not its settings. A guardrail counts for you only where the last column says what you did and saw.

Guardrail	Source	What It Prevents	In your fork
One change per PR	Chapter 01	Correlated blast radius	a habit - nothing enforces it
`guard-kube-context.sh`	Chapter 01	Wrong cluster or namespace writes	in the code you cloned; it guards only the commands you run through it, and the agent hook only if you connected it (Chapter 01)
`guard-terraform-plan.sh`	Chapter 02	Unplanned or stale applies	in the code you cloned; you saw it refuse an apply
GitOps reconciliation	Chapter 03	Manual kubectl drift	your kind cluster’s Flux reads your fork - if you built it with `flux_git_repository_url` in `terraform.tfvars` (Chapter 00); check with `kubectl --context kind-sre-control-plane -n flux-system get gitrepository flux-system`
SOPS + Age encryption	Chapter 04	Plaintext secrets in Git history	your own Age key; you encrypted and decrypted a secret
Pre-commit hooks	Chapter 05	Invalid manifests, leaked secrets, direct-to-main commits - on your machine, where `--no-verify` skips them	installed in your clone (`make install-hooks`); you saw them refuse
The same hooks in CI, as required checks	Chapter 05	A pull request that skipped the hooks locally - it cannot merge until `hooks` passes	Actions on, and your own ruleset (Ch05 A5); you saw `hooks` fail, the merge and a direct push refused
Plan-Approve-Apply	Chapter 05	Automated infrastructure mutation without human sign-off	platform only - it needs the platform’s cloud secrets and approvers; you read it, you did not run it

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?
When I check Flux, I read the SUSPENDED column as well as READY - a suspended Kustomization applies nothing new from Git (Chapter 03)
Which layer catches a git commit --no-verify bypass, and why is that layer also not the last one?
Which of the guardrails above exist only on the platform, and which did you enable and see working in your fork?

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.