Core Track Guardrails-first chapter in core learning path.

Estimated Time

  • Reading: 25 min
  • Lab: 40 min
  • Quiz: 5 min

Prerequisites

What You Will Produce

In your fork: a ruleset on main that requires a pull request with hooks and secrets green; the platform’s hooks installed, and seen refusing a commit to main, a broken Terraform file and an amend of a pushed commit; the same broken file pushed with --no-verify - caught by the CI job that runs every hook, its merge refused by the ruleset, and a push straight to main refused too. The lab ends with the branch removed, nothing changed on main, and every Kustomization Ready and none suspended.

Chapter 05: CI/CD & Developer Guardrails

Learning Objectives

By the end of this chapter, you will be able to:

  • Explain what CI gives a team: the plan of a change for everyone to read, without tools or credentials on each laptop, and a place to discuss it before it runs
  • Install the platform’s hooks, and explain why every hook runs again in CI - and what --no-verify does and does not skip
  • Read a pull request’s checks: tell a required check from an advisory one, and a check that passed from one that never ran
  • Trace a Terraform change from the plan on its pull request to a deliberate, approved apply of a fresh plan

Recall Check

Before continuing, quickly recall:

  • Why does the platform apply only a saved plan that a person has read, and only while it is fresh? (Chapter 02)
  • What does Flux apply when a change is merged into main? (Chapter 03)
  • Which check refuses a plaintext Secret before the commit - and where does it run a second time? (Chapter 04)

If you can’t answer these, revisit the corresponding chapter before proceeding.

Context

Every chapter so far added a check: the Terraform guard (Chapter 02), the Flux validation (Chapter 03), sops-encrypted (Chapter 04). They are pre-commit hooks: Git runs them on your machine before a commit exists. That is the cheapest place to stop a mistake - and the easiest one to skip: git commit --no-verify, or a fresh clone where nobody ran make install-hooks.

So the same checks run again on GitHub, on every pull request - and that is only the start of what CI gives a team. To plan a change of the Hetzner platform you would need Terraform, its providers, the Hetzner token, the state keys and the SOPS key on your laptop. With CI you need none of them: you push a branch, open a pull request, and CI shows the plan - to you and to everyone who reviews it. They see what you changed and what it would do, comment on the exact line, and the people with the right to apply decide when it runs. Nobody “just runs something” and finds out later what it broke.

Until October 2026 this platform had a gap: CI ran only the secret checks, the Flux checks and the Hetzner plan - every other hook ran nowhere but on a laptop. The incident is what that gap allows.

Work through each lesson section; the chapter video, once it is published, gives the concept overview.

Two Paths from a Commit to the Cluster

Diagram: your machine; git commit the hooks run here --no-verify skips them; pull request on GitHub; the same hooks again Secrets guard · Flux Diff Terraform plan; merge allowed when the REQUIRED checks pass; after the merge; flux/** Flux applies what is on main; Hetzner Terraform the merge only plans; apply = a separate run, approved by a person

Detailed Lessons

Hands-On Materials

Labs, quizzes and runbooks for this chapter are free - sign in with your email, Google or GitHub to open them.

  • Lab: Every Check Twice Free · sign in
  • Quiz: Chapter 05 (CI/CD & Developer Guardrails) Free · sign in