Exam Prep · Common preparation · Checklist

The exam-readiness checklist

One list, two exams. Phases ①–④ get you ready for the Certified Cloud Native Platform Engineer (CNPE) — the performance-based professional exam, where reading about a canary is not the same as shipping one. Phases ⑤–⑦ get you ready for the Cloud Native Platform Engineering Associate (CNPA) — the knowledge-based associate exam, where nothing is graded but your answers and there is no documentation tab to fall back on. Tick items off as you go; your progress is saved in this browser.

Which phases apply to you

Sitting CNPE? Work phases ①–④: Foundations & mindset (think like a platform product owner), Domain mastery (get the reps in on real tools), Observe & secure (run it well and guard it), and Exam readiness (the terminal habits and logistics that win the clock). Those four map onto the five CNPE domains — see the exam guide for the weights.

Sitting CNPA? Work phases ⑤–⑦: Blueprint & vocabulary, Domain recall, and Question technique & the sitting. They map onto the six CNPA domains — see the CNPA hub for the weights. Phase ① is worth ticking too: the platform-as-a-product ideas in it are examined on both papers, and CNPA leans on them harder than CNPE does.

Sitting both? Do phase ① once, then ⑤–⑦ for the associate and ②–④ for the professional — in that order, because the associate material is the conceptual half of the professional one. And whichever you are sitting, the three shared pages apply: how to study for a CNCF exam, the Kubernetes baseline you need before either paper, and exam day — proctoring & environment.

• ① Foundations & mindset — think like a platform product owner · both exams
• Explain platform-as-a-product and the Golden Path out loud — the platform is a product and developers are its customers
• Tell an IDP (the paved road) from a developer portal (Backstage — just its storefront)
• Sketch the reference architecture and its planes from memory (developer control, integration & delivery, resource, security, observability)
• Place your team in Team Topologies — a platform team is its own team type (not an enabling team), stream-aligned teams are its customers, cognitive load is the metric
• Judge every capability with one litmus test — “does it actually help Dot ship without filing a ticket?”
• ② Domain mastery — get the reps in (hands-on) · CNPE
• Run a GitOps sync, then break it — hand-edit a resource and watch Argo CD or Flux self-heal the drift
• Build a CI pipeline that builds an image and bumps a manifest — with Tekton or Argo Workflows
• Ship a canary — shift ~10% of traffic with Argo Rollouts or Flagger and let metric analysis auto-roll-back a bad version
• Write a CustomResourceDefinition and reconcile it with an operator (observe → diff → act)
• Provision cloud infra from a Crossplane Claim — a developer asks for a database in YAML, no ticket
• Scaffold a new service from a Backstage Software Template and watch it land fully paved
• ③ Observe & secure — run it well and guard it · CNPE
• Wire the metrics stack — Prometheus scraping, Alertmanager routing, Grafana dashboards
• Define one SLO with an error budget, built on the four golden signals (latency, traffic, errors, saturation)
• Triage a broken pod on sight — CrashLoopBackOff, OOMKilled, and Pending/unschedulable
• Enforce a policy as code with Kyverno or Gatekeeper via an admission webhook
• Lock down access — RBAC least-privilege, a default-deny NetworkPolicy, and mTLS between services with a mesh
• Add supply-chain checks to the pipeline — generate an SBOM and scan the image before it ships
• ④ Exam readiness — win the clock · CNPE
• Drill kubectl speed — aliases, imperative --dry-run=client -o yaml to scaffold YAML, and kubectl explain
• Make it a reflex to set your context and namespace at the start of every task (kubectl config set-context --current --namespace=…)
• Do both killer.sh practice sessions — they’re included with registration and harder than the real thing
• Know the docs allowlist cold — only kubernetes.io/docs, kubernetes.io/blog/, whatever the task’s Quick Reference box links, and locally installed docs (man, /usr/share). Project sites like Argo CD, Flux, Crossplane, Backstage, Prometheus or Kyverno are not open, so that YAML has to come from kubectl explain and your head — see the exam guide
• Rehearse the clock — 120 minutes for 15–20 tasks, so time-box each one, flag-and-move when stuck, and remember you only need 64% to pass. Then book the exam
• ⑤ Blueprint & vocabulary — know the shape of the paper · CNPA
• Recite the six CNPA domains and their weights — 36 / 20 / 16 / 12 / 8 / 8 — and name the two that are 56% of the paper between them
• Say the CNPA/CNPE difference in one sentence — comprehension versus capability, multiple-choice versus live cluster — and know that neither is a prerequisite for the other
• Read all six domain pages end to end — core fundamentals, observability & security, continuous delivery, platform APIs, IDPs & DevEx, measuring
• Budget your hours by weight, not evenly — the four-week study plan does the arithmetic, and gives Core Fundamentals the week it is worth
• Internalise that CNPA is closed-book — no docs tab, unlike CNPE, CKA, CKAD and CKS. Revise for recall, not for lookup
• ⑥ Domain recall — explain it with the page closed · CNPA
• Draw the reconciliation loop from memory — desired state, observed state, diff, act — and name the three domains it earns marks in
• Separate the pairs candidates mix up — golden path vs guardrail, prune vs self-heal, RED vs USE, authorisation vs admission, DORA vs SPACE, continuous delivery vs continuous deployment
• Name the four observability signals — metrics, logs, traces, events — and say which one needs context propagation to work at all
• Explain what a policy engine actually enforces, and at which point in the API request it does so
• Name the four DORA metrics and say which two measure throughput and which two measure stability
• ⑦ Question technique & the sitting · CNPA
• Work all four practice banks — 68 questions — after reading each matching domain page, never instead of it
• Sit Mock Set 1 cold and timed, then Set 2, Set 3 and Set 4 spaced at least a week apart — and keep the ones you have not sat genuinely sealed
• Review by explaining the distractors — for ten questions you got right, write one sentence on why each wrong option is wrong. The ones you cannot explain were luck
• Before you pay, confirm duration, question count, pass mark, price, retake terms, eligibility window and validity on the official Linux Foundation and CNCF pages — never from a third-party site, this one included

Check your answers

1. Hands-on before exam day: all of Phase ② (a GitOps sync + self-heal, a CI pipeline, a canary with auto-rollback, a CRD reconciled by an operator, a Crossplane claim, a Backstage template) and the doing-items in Phase ③ (wire Prometheus/Alertmanager/Grafana, triage a broken pod, enforce a Kyverno/Gatekeeper policy, set RBAC + NetworkPolicy + mTLS, add an SBOM + image scan). The exam scores what you produce in a live cluster, so your fingers need the muscle memory — reading isn’t enough.
2. Most-skipped, most-regretted: the two killer.sh sessions plus the kubectl-speed and set-your-namespace-every-task habits. Candidates run out of time, not knowledge — the ones who finish are those who practised the clock and never lost a task to “oops, wrong namespace.” Timmy books his killer.sh time before he books the exam.
3. CNPA: phases ⑤, ⑥ and ⑦ are yours, and phase ① is worth ticking as well because the platform-as-a-product ideas are examined on both papers. Closed-book means there is no documentation tab to rescue a half-remembered idea, so the unit of revision is retrieval, not lookup: shut the page and explain the thing out loud. If you can only recognise it when you see it, you do not yet know it.