Hands-On · The Capstone Hub

Build one platform, start to finish

The CNPE is a performance-based exam — you don’t answer questions about platforms, you build and fix them live. This hub is where that muscle memory gets built. Rather than nine disconnected exercises, you’ll stand up one real (if tiny) internal developer platform on a local cluster and grow it across six deep, connected parts: GitOps foundation, a pipeline and a canary, a platform CRD, a self-service portal, observability, and policy guardrails — each part picking up exactly where the last one left off, ending in a golden path where a brand-new service ships with zero hand-written infrastructure. If you only have an afternoon, the fast path below is still here for you.

☺ Explain it like I’m 10

Reading about riding a bike doesn’t teach you to ride. This is the part where you get on and pedal. You’ll build a small version of the whole “kitchen” the Platform Guild builds in the story — the conveyor belts, the vending machine, the watchtower, the safety rails — one piece at a time, on your own laptop, and unlike a pile of separate toy kitchens, it’s all the same kitchen, growing one room at a time, until a developer-duck can cook a whole meal by herself.

🦫🛠️Your host for this track: Benny the Beaver — the builder. He hands each part to the right specialist (Recon, Mira, Ellie, Timmy, Pip, Sol) and doesn’t sign it off until it actually works. The whole Guild is on call.

⚠ Before you start

Every part below is local and throwaway — nothing here touches production or costs money. You’ll want a laptop with Docker (or Podman), a local Kubernetes cluster via kind (minikube works too, but the parts below assume kind's commands), kubectl, helm, and git. Commands and version numbers drift — always follow each project’s current quickstart. Tear the cluster down when you’re done (kind delete cluster --name platform-dev) and nothing lingers.

The world you’re building

☺ Like you’re 10: Before any building starts, here’s the map: one cluster, one little app, two drawers to keep things tidy in.

Every part of this capstone — the hub you’re reading and all six parts — builds inside one continuous project, so nothing you learn in Part 1 goes stale by Part 6. Here is the whole world, once, so you never have to re-derive it:

The cluster is created with kind create cluster --name platform-dev and stays up for the whole capstone (minikube is a fine substitute if that’s what you have, but translate the commands yourself).
The workload is a small payments/ledger-style service called ledger — the same fictional service this site’s mock exam papers already use, so the scenario should feel familiar. Its image is ledger:TAG, pushed to a placeholder registry, registry.local/ledger.
Namespaces split cleanly in two: ledger hosts the application itself, and platform (sometimes written platform-system) hosts every platform add-on — Argo CD, the Prometheus stack, Kyverno, and the rest. Every part keeps this split consistent.
The GitOps repo is a single Git repo with an apps/ directory holding Argo CD Application manifests (Argo CD’s own App-of-Apps pattern points here) and a ledger/ directory holding the ledger service’s own Kubernetes manifests.

platform-dev (kind cluster)
├── namespace: platform          # Argo CD, Prometheus/Grafana, Kyverno, Linkerd control plane…
├── namespace: ledger             # the ledger Deployment, Service, ServiceMonitor…
└── (git) platform-capstone/
    ├── apps/                     # Argo CD Application manifests — the App-of-Apps root points here
    └── ledger/                   # the ledger service's own Kubernetes manifests

◆ Key idea

Every capstone part opens by stating exactly what state your cluster is in when you arrive (inherited from the part before) and what state it’s in when you leave (handed to the next one). You should never be confused about continuity — if a part ever feels like it’s starting from nothing, re-read its opening paragraph.

The six parts

☺ Like you’re 10: Six chapters of the same story. Each one hands the next chapter a cluster that’s a little more finished than the one before.

Work them in order. Each part pairs 1:1 with an Exam Blueprint lesson, so you always know which exam domain your hands are earning you reps in. Each has its own 10–14 checkbox milestones, its own progress bar, and real, runnable manifests — not just prose.

#	Part	Pairs with	What you leave with
1	Foundation — 🦫 Benny & 🤖 Recon	Architecture & Infra (D1) + GitOps (D2)	A kind cluster, Argo CD installed, an `apps/` App-of-Apps reconciling — drift reverted, Git deletions pruned.
2	Delivery — 🦫 Benny & 🐦 Pip	CI/CD & Progressive Delivery (D2)	A Kubernetes-native pipeline building the `ledger` image, shipped via an Argo Rollouts canary that auto-aborts a bad version.
3	Platform APIs — 🦋 Mira & 🤖 Recon	Platform APIs, CRDs & Operators (D3)	A new noun for “ledger” — an operator or a Crossplane XRD/Composition — that reconciles and self-heals a deleted child object.
4	Self-Service — 🦋 Mira, 🐿️ Nutty & 🦆 Dot	Self-Service & Developer Portals (D3)	Backstage running, `ledger` in the Software Catalog, and a Software Template that scaffolds a new service already wired.
5	Observability — 🐘 Ellie	Observability & Operations (D4)	kube-prometheus-stack, a `ServiceMonitor`, a golden-signals Grafana dashboard, a firing alert, and a triaged, deliberately broken pod.
6	Security & the golden path — 🐢 Timmy & the whole Guild	Security & Policy Enforcement (D5)	Policy, RBAC, NetworkPolicy, mTLS, a Trivy scan, tenancy and cost visibility — and every part chained into one automatic golden path.

Deep-dive the concept behind any part via its linked lesson before or after you build — the lesson explains why, the part makes you prove it works.

The fast path — for an afternoon

☺ Like you’re 10: No time for six chapters? Here’s the one-page summary of the whole story, still worth doing.

The six parts are the deep version of this track — real manifests, real breakage, real triage, 60+ checkboxes across everything. If you only have an afternoon, or you want one condensed pass before the exam, work this shorter nine-item version instead. It touches every domain at a lighter depth, using the exact same ledger/platform-dev world as the parts above, so anything you build here isn’t wasted if you come back and go deep later.

0 / 9 fast-path items complete

0Stand up the ground — ☁️ Nimbus & 🦉 Owl

Create the cluster with kind create cluster --name platform-dev. Install kubectl and, optionally, k9s for a fast terminal UI. Look around: kubectl get nodes, kubectl get ns, kubectl get pods -A. This is the resource plane your whole platform stands on.

Done when: kubectl get nodes shows a Ready node and you can list system pods in kube-system.

Concept: The Reference Architecture · Architecture & Infrastructure · Deep version: Part 1 — Foundation

1Git becomes the control panel — 🦫 Benny & 🤖 Recon

Install Argo CD (or Flux) into a platform namespace. Create an Application pointing at a Git repo path with automated sync, prune: true, and selfHeal: true. Watch it sync to Healthy. Now cause drift: kubectl scale the deployment by hand — watch Recon revert you within seconds. Delete a manifest from your fork and watch prune remove the live resource.

Done when: your app is Synced/Healthy, a manual edit is auto-reverted, and a Git deletion removes the live object.

Concept: GitOps Workflows · Deep version: Part 1 — Foundation

2A pipeline and a safe rollout — 🦫 Benny & 🐦 Pip

Build the ledger image with a Kubernetes-native pipeline — a Tekton Pipeline or an Argo Workflow (image build via Kaniko, no Docker daemon). Deploy it with an Argo Rollouts Rollout (or Flagger) configured as a canary: shift 10% → 50% → 100% with a pause. Ship a deliberately broken version and watch the rollout abort back to the stable one.

Done when: a good version promotes through the canary steps, and a bad version is automatically rolled back.

Concept: CI/CD & Progressive Delivery · Deep version: Part 2 — Delivery

3Extend the API with a platform CRD — 🦋 Mira & 🤖 Recon

Give the platform a new noun. Either scaffold a tiny operator with Kubebuilder that defines a CustomResourceDefinition and reconciles it, or install Crossplane, define a CompositeResourceDefinition (XRD) + Composition, and create a Claim for a ledger database. Create your custom resource and watch the controller reconcile it into real objects. Delete a child object and watch it come back.

Done when: applying one friendly custom resource makes the controller create and keep the underlying objects in sync (delete one — it comes back).

Concept: Platform APIs, CRDs & Operators · Deep version: Part 3 — Platform APIs

4The self-service front door — 🦋 Mira, 🐿️ Nutty & 🦆 Dot

Run Backstage locally (npx @backstage/create-app@latest). Register ledger in the Software Catalog with a catalog-info.yaml. Author a Software Template so “create a new service” is one click that produces a repo with a pipeline and manifests. Play Dot: scaffold a service and confirm you didn’t touch a single raw YAML file.

Done when: a teammate (or you, as Dot) can pick a template in the portal and get a ready-to-ship project without asking anyone.

Concept: Self-Service & Developer Portals · Deep version: Part 4 — Self-Service

5Raise the watchtower — 🐘 Ellie

Install kube-prometheus-stack (Prometheus + Alertmanager + Grafana). Add a ServiceMonitor for ledger, build a Grafana panel for the four golden signals, and write a PrometheusRule that alerts on a high error rate or an exhausted error budget. Break something on purpose (a bad image or a tiny memory limit) and triage the CrashLoopBackOff/OOMKilled with kubectl describe and kubectl logs --previous.

Done when: you have a golden-signals dashboard, a firing alert, and a written one-line root cause for the failure you injected.

Concept: Observability & Operations · Deep version: Part 5 — Observability

6Install the guardrails — 🐢 Timmy & 🐦 Pip

Add policy-as-code with Kyverno (or OPA/Gatekeeper): a policy that blocks :latest tags or requires non-root, first in audit then enforce. Scope an RBAC Role + RoleBinding for a tenant (never cluster-admin). Add a default-deny NetworkPolicy. Turn on mutual TLS by meshing the ledger namespace with Linkerd. Scan the ledger image with Trivy and read its findings.

Done when: a policy-violating pod is refused at admission, your tenant’s ServiceAccount can’t exceed its Role, and a Trivy scan reports on your image.

Concept: Security & Policy Enforcement · Deep version: Part 6 — Security

7Share the road: tenancy & cost — 🦉 Owl & 🦥 Sol

Create a second tenant namespace alongside ledger. Give each a ResourceQuota + LimitRange so neither can starve the other, and a NetworkPolicy so they can’t reach into each other. Install OpenCost and read per-namespace spend. Try to exceed a quota on purpose and watch the request get rejected.

Done when: a tenant is capped by its quota, tenants are network-isolated, and you can point at each tenant’s cost.

Concept: Architecture & Infrastructure · Anti-Patterns · Deep version: Part 6 — Security

CapstoneDot ships before lunch — 🦆 Dot & the whole Guild

Wire the pieces into one golden path. From the Backstage template, a scaffolded service opens a Git PR; Argo CD reconciles it; the platform CRD provisions its dependencies; the rollout ships it as a canary; and the dashboards and policies attach automatically because they’re baked into the template. Now be Dot: create a brand-new service and take it to “running in the cluster” without filing a single ticket.

Done when: one self-service action produces a running, observed, policy-checked service — and you didn’t hand-write any infrastructure to get there. That’s the golden path.

Concept: Self-Service · Platform as a Product · Full build: Part 6 — the wired-together golden path

🦆 Dot’s-eye view

“Whichever version you did — the fast path or the six deep parts — run the golden path once as me. If getting a new service to production still feels like paperwork and waiting, the platform isn’t done — go back and make it smoother. If it feels like magic, you’ve built the thing this whole course is about.”

What you’ll have built

☺ Like you’re 10: By the end, your laptop holds a tiny working version of everything the story is about — the belts, the vending machine, the watchtower, and the safety rails.

Finish the six parts (or the fast path) and you’ll have hands-on reps with every CNPE domain: a GitOps-reconciled cluster (Domain 2), a Kubernetes-native pipeline and progressive delivery (Domain 2), a custom platform API and operator (Domain 3), a self-service portal and provisioning (Domain 3), a full observability stack with alerting and incident triage (Domain 4), policy-as-code, RBAC, mTLS and image scanning (Domain 5), and multi-tenancy with cost visibility (Domain 1). That’s not exam trivia — it’s the muscle memory the performance-based test rewards. Pair this with the exam guide and the exam-prep checklist.

⚖ CNPA vs CNPE — This hub’s format is CNPE-specific — CNPA has no lab or task component at all; it’s a closed-book, multiple-choice exam with no hands-on portion whatsoever. But the concepts these six parts build reps in (reconciliation, progressive delivery, platform APIs, self-service, observability, policy) are exactly what CNPA tests via closed-book recall, so working through this capstone still strengthens CNPA prep — just not as a lab-for-lab match.

🦫 Benny’s challenge · going further

Already comfortable? Level up any part: put everything under GitOps so the whole platform (add-ons included) reconciles from one repo; add a second cluster and fan your apps out with an Argo ApplicationSet; wire an AnalysisTemplate so the canary promotes on real Prometheus metrics; or sign your image with cosign and make admission reject anything unsigned.

🎬 At the Platform Guild

🦊

Foxy: Six deep parts sounds like a lot. Can’t I just do the fast path and call it done?

🦫

Benny: You can, Foxy, and it’ll still teach you real things. But the fast path is the map — the six parts are the actual territory, with real manifests and real breakage. If you have the time, take it.

🐢

Timmy: And when a part breaks — and it will — that’s the lesson. Fixing a real CrashLoopBackOff at your desk beats meeting your first one on the clock.

🦆

Dot: Just remember who it’s all for. If I can’t ship on it, it doesn’t count.

🐢 Timmy’s checkpoint

1. Which capstone part proves you understand reconciliation and drift? 2. Which two parts together let a service ship with no ticket? 3. Before the exam, which part’s skill — fast kubectl triage of a failing pod — will you lean on most under time pressure?

Check your answers

Part 1 — Foundation: a hand-edit is auto-reverted and a Git deletion is pruned. That is reconciliation defeating drift.
Part 4 — Self-Service (the Backstage template / self-service front door) plus Part 6 — Security & the golden path, which wires it to GitOps, the platform CRD, the rollout, observability, and policy — together they are the golden path.
Part 5 — Observability: triaging CrashLoopBackOff/OOMKilled with describe and logs --previous. “Diagnose & remediate” is a whole exam competency, and speed here saves you minutes.