Study console
A study path through every domain and competency in the official CNPE curriculum, built on the lab in this repo. Each section is sized for one evening: read the concepts, do the exercises against the lab, and finish with a command whose output proves the thing works. The lab's rule applies here too: never trust "the pod is Running"; make it do something.
file:// copy and a hosted one keep separate stores. Export writes it to a JSON file that Import merges in elsewhere. On the hosted site you can also sign in with GitHub to keep a copy across browsers and machines. Sync is optional and off by default. It sends section, exercise and mock-exam ticks, drill history, activity days, and your last-read section. Press / to jump to any section by name, tool or concept, g for a drill session, q for the quest, ? for every shortcut.The map
Weights are not study time. Domains 2 and 3 are half the exam and mostly mechanical skills that improve with reps. Domain 4's incident competency is a practice skill too. Domain 1 and half of domain 5 are things you likely already know if you run Kubernetes for a living; check yourself against the exercises before spending evenings there.
Plus two mock exams (fifteen timed tasks each across all five domains, no task repeated between the papers, with grading commands and a built-in 120-minute clock; paper 2 keeps its own score) and the drill: every self-check question as flashcards, on a spaced-repetition schedule and weighted toward what you miss. There is also CNPE Quest, a role-playing game over the whole map: talk to the townsfolk of each section to learn its theory and commands, pass the town's trial (its own self-check cards, recorded into the drill), then fight the fault in its dungeon with real commands against a simulated cluster. All of it feeds the study uptime above, and the probe is any heartbeat: a card answered, an exercise verified, a section completed or a mock task scored keeps the day green.
Weak spots
Accuracy is your lifetime drill record in this browser, split by domain; the mock exams keep their own per-domain score on their pages. Five answers in a domain is the minimum before the panel will call it weak: one bad card is noise, a trend is a signal.
The exam
From the certification page and the official curriculum PDF:
- Performance-based. You solve tasks on a remote Linux desktop with a terminal and web UIs, not multiple choice.
- 120 minutes, 15 to 20 tasks. The Linux Foundation's own instructions give that range, so budget 6 to 8 minutes a task, which is why
make breakuses a 7-minute clock. Tasks are weighted; the heavy ones are usually the multi-step ones in domains 2 and 3. - One SSH host per task. You land on a base machine (hostname
base) that has none of the tools installed. Each task's info box names the host tosshinto, and you mustexitback to base before the next one. Forgetting to exit, or running a task's commands on the wrong host, is a zero for that task with no error to warn you. The environment tracks the latest Kubernetes minor within a couple of months of release (v1.35 with etcd v3.6 at the time of writing), so read release notes for the minor in front of you, not the one you run at work. - Documentation is limited, and less generous than people assume. The exam instructions allow browsing kubernetes.io/docs plus the task-specific links in each question's Quick Reference panel, and prohibit everything else. Tool docs reach you only through those links. That makes
kubectl explain,kubectl api-resourcesand--helpyour primary references, which is why every section here leans on them. The per-section "Docs to know your way around" lists are for study time. - Tools named as examples: Argo, Crossplane, Flagger, Flux, Gatekeeper, Grafana, Istio, Jaeger, Kyverno, Linkerd, OPA, OpenCost, OpenTelemetry, Prometheus, Tekton. The PDF is explicit that you will not be tested on deep tool-specific knowledge beyond the listed competencies.
- Registration includes two killer.sh simulator sessions (20 questions each), one retake, a 12-month eligibility window, and a certificate valid 2 years.
- The passing score is not disclosed. Ignore any number a course quotes.
- The simulator is more generous than the exam. killer.sh gives you two runs of 20 scenarios with graded solutions, and it is the best signal you get before the day. Its allowed-docs list is wider than the real one, so run it with the browser closed to everything but kubernetes.io, or the real thing feels like a downgrade.
- Tools move under a live exam. Kyverno 1.17 (February 2026) deprecated the classic
ClusterPolicy,PolicyandCleanupPolicykinds; 1.19 (August 2026) declared the CEL-basedValidatingPolicy,MutatingPolicy,GeneratingPolicy,ImageValidatingPolicyandDeletingPolicystable, with removal of the legacy kinds planned for 1.20. The cluster in front of you decides which is installed, so learn the new kinds first and be able to read the old one (section 5.2). The same applies to Crossplane v1 versus v2 (3.5) and Argo CD 2 versus 3 (2.2): check the installed version before you type.
Tasks to rehearse
A performance-based exam can only grade what it can read back from the cluster: an object exists with these fields, a status condition is True, a request is admitted or refused, a metric or log line exists. Every task below ends in something like that. Rehearse it until the check passes first time; the exact nouns will differ.
| # | Task | What the grader reads back | Rehearse in |
|---|---|---|---|
| 1.1 | Expose a Service through Gateway API, or fix a Service whose endpoints are empty; make a StatefulSet's storage bind on a given class; spread a Deployment across zones | HTTPRoute Accepted/ResolvedRefs True, EndpointSlice populated, PVC Bound with the right class, pods on distinct zones | 1.1, 1.2, 1.3 |
| 1.2 | Find the most over-requested workload from cost data and right-size it; add an HPA or apply a VPA recommendation | requests changed to the stated values, HPA/VPA object present with the stated targets | 1.5, 1.2 |
| 1.3 | Onboard a tenant namespace: quota, LimitRange, default-deny NetworkPolicy, PSS labels, a scoped Role | each object present with the stated limits; a test pod refused for the stated reason | 1.4 |
| 2.1 | Point Argo CD (or Flux) at a repo path and get the app Synced and Healthy; fix an app that is OutOfSync or stuck; enable self-heal and prune | Application (or Kustomization) status Synced/Healthy (Ready True), the workload present, drift reverted after a manual edit | 2.1, 2.2, 2.3, 2.6 |
| 2.2 | Author or repair a Tekton Pipeline: wire a workspace, pass a result between tasks, make a run succeed; or the same task in Argo Workflows | PipelineRun (or Workflow) Succeeded, the image or artifact it was meant to produce present | 2.4, 3.4 |
| 2.3 | Convert a Deployment to a Rollout (or Flagger Canary) with the stated steps and an analysis; promote or abort a stuck one | Rollout Healthy at the new revision with the stated steps in spec; AnalysisRun Successful; or the old revision restored | 2.5 |
| 3.1 | Write a CRD with the stated fields, validation and printer columns; make a bad instance fail at admission | CRD Established, a valid CR accepted, an invalid one refused with a schema or CEL message | 3.2 |
| 3.2 | Build a workflow (Argo Workflows) that provisions a namespace or a tenant from parameters, with the RBAC it needs | Workflow Succeeded and the provisioned objects present, submitted as the stated ServiceAccount | 3.4 |
| 3.3 | Install an operator and use its CRD to run a service (a database, say); diagnose a CR that never becomes Ready | the CR's Ready condition True, its child objects owned and healthy | 3.3 |
| 3.4 | Create or extend a Crossplane XRD and Composition (or a kro ResourceGraphDefinition) and consume it as a developer would | XR Synced and Ready True, the composed resources present with the patched values | 3.5, 3.6 |
| 4.1 | Get a workload scraped (ServiceMonitor with the right selectors and port name); write a PrometheusRule that fires; make its logs appear in Loki; route traces to Jaeger | target UP in Prometheus, alert Firing, LogQL returning lines, a trace visible | 4.1, 4.2, 4.3, 4.4 |
| 4.2 | Produce a deployment-frequency or lead-time figure from the delivery system's metrics; build a recording rule or dashboard panel for it | the PromQL or rule object present and returning a value | 4.5 |
| 4.3 | A namespace is broken (bad image, missing ConfigMap, quota, webhook, DNS, PSS); find and fix it under the clock | pods Running and Ready, the app answering | 4.6, make break |
| 5.1 | Enforce STRICT mTLS for a namespace, and allow only one identity to call a service | PeerAuthentication STRICT, AuthorizationPolicy present, plaintext refused, the allowed caller succeeding | 5.5 |
| 5.2 | Grant a group or ServiceAccount exactly the stated verbs across N namespaces; make a secret available from an external store | auth can-i as the subject matches the matrix; ExternalSecret SecretSynced and the Secret present | 5.1 |
| 5.3 | Enable audit logging with the stated policy; produce an SBOM or a vulnerability or compliance report for an image or the cluster | audit lines for the stated resource, the report CR present with the stated format | 5.4 |
| 5.4 | Write a Kyverno (or Gatekeeper, or ValidatingAdmissionPolicy) rule that refuses X and mutates Y; move a namespace to a stricter PSS profile | a violating object refused with the policy's message, a compliant one admitted, the mutation visible on the object | 5.2, 5.3 |
| 5.5 | Add a scan step that fails the pipeline on the stated severity; sign the image and make admission verify the signature | PipelineRun Failed on a bad image and Succeeded on a good one; unsigned image refused at admission | 5.6 |
Each task ends with a sentence like "ensure the application reports Healthy" or "the pod must be rejected". That sentence is the grader's check. Read it first, decide how you will observe it yourself, do the work, then run that observation before moving on. The mock exams' grading blocks are written the same way so the habit forms.
Competency coverage
Where each one is taught, and how the lab proves it. If a row's proof column says exercise, the evidence is a command inside the section rather than a make validate check.
| # | Competency (official wording, abbreviated) | Section | Proof |
|---|---|---|---|
| 1.1 | Architecture best practices: networking, storage, compute | 1.1, 1.2, 1.3 | validate: nodes/zones/Gateway CRDs/metrics-server; storage exercises |
| 1.2 | Cost management for right-sizing and scaling | 1.5, 1.2 | validate: opencost ready; kubectl-cost exercises |
| 1.3 | Optimizing multi-tenancy resource usage | 1.4 | validate: tenant quotas, NetworkPolicies, egress probe |
| 2.1 | GitOps workflows for app and infra deployment | 2.1, 2.2, 2.3 | validate: Argo CD + Flux wired to Gitea; drift-revert exercise |
| 2.2 | CI/CD pipelines integrated with Kubernetes | 2.4 | validate: tekton deployments + catalog tasks; pipeline run exercise |
| 2.3 | Progressive delivery (blue/green, canary) | 2.5 | validate: argo-rollouts, flagger; canary promote/abort exercise |
| 2.x | Troubleshooting delivery failures | 2.6 | break drills + staged failures |
| 3.1 | Designing and creating CRDs | 3.1, 3.2 | exercise: hand-written CRD with validation, rejected bad input |
| 3.2 | Workflows for self-service provisioning | 3.4 | exercise: workflow provisions a namespace end to end |
| 3.3 | Operators for automation and integration | 3.3 | validate: XR reconciled, cnpg ready; operator diagnosis exercise |
| 3.4 | Automation frameworks for self-service | 3.5, 3.6 | validate: XR created its namespace, kro ready, golden path |
| 4.1 | Monitoring, alerting, logging, tracing | 4.1, 4.2, 4.3, 4.4 | validate: targets UP/0 DOWN, loki holds streams; alert-fire and trace-find exercises |
| 4.2 | Platform efficiency via deployment metrics | 4.5 | exercise: DORA-style PromQL over Argo CD metrics |
| 4.3 | Diagnosing and remediating incidents | 4.6 | make break, the whole fault library under the clock |
| 5.1 | Secure service-to-service communication | 5.5 | validate: ztunnel/istiod/SPIRE healthy; mTLS verification exercise |
| 5.2 | RBAC and security controls across resources | 5.1 | exercise: auth can-i matrix as user dev-a; rbac break drill |
| 5.3 | Audit trails and policy compliance (SBOM, reports) | 5.4 | validate: audit log bytes, sbomreports, compliance reports |
| 5.4 | Policy engines and admission controllers | 5.2, 5.3 | validate: kyverno policies loaded; denied-pod exercises |
| 5.5 | Security scanning in deployment pipelines | 5.6 | exercise: pipeline fails on CRITICAL CVE, cosign sign/verify |
Linkerd appears only as the MESH=linkerd make mesh alternative (section 5.5 tells you what transfers), and classic Rego-based OPA is covered through Gatekeeper constraint templates in section 5.2, which is the form the exam tool list means.
How to run a session
- Bring up the layers named in the section's lab layers tile. Tear down what you don't need; the full stack saturates a laptop.
- Read the concepts. They are deliberately dense rather than long: the exam tests hands, not recall, but the hands need a correct model.
- Do every exercise, and mark it verified when its check passes. If the output doesn't match, that is the real exercise.
- Close the loop with
make validatewhen a section says so. - Note what you had to look up. That list is your personal weak-spot index, and it beats any pre-made one.
Study plan
Twenty-nine sections plus drills. Compress by skipping sections whose exercises you can already do cold. The order matters more than the pace: domain 2 before 3 (Crossplane and Backstage build on Argo CD), domain 4 before the break drills, mocks last.
| Phase | Sessions | What |
|---|---|---|
| 1 | 1–5 | Domain 1, all sections. make up, keep the cluster. |
| 2 | 6–11 | Domain 2. Add gitea gitops cicd. Finish with three staged failures from 2.6. |
| 3 | 12–17 | Domain 3. Add api, then portal for section 3.6. |
| 4 | 18–23 | Domain 4. Swap cicd down if the laptop struggles, add obs. End with two make break drills. |
| 5 | 24–29 | Domain 5. Add sec spire, then mesh for 5.5. First killer.sh session after 5.3. |
| 6 | 30+ | Mock exam 1 under 120 minutes, then mock exam 2 on a rebuilt lab two days later; fresh tasks predict better than a rerun you half-remember. Daily make break with rotating FAULT=. Second killer.sh in the final week. Re-run every exercise you flagged. |
The two killer.sh sessions are the only external signal you get before the real thing. Don't burn both early: the first tells you what to fix, the second tells you whether you fixed it.
Exam-day tactics
- Time-box at 7 minutes. Flag and move on; a stuck task costs you two easy ones. The mock exam trains this.
kubectl explain <kind> --recursivebefore searching docs. Faster, and always version-correct for the cluster in front of you.kubectl api-resources | grep <tool>first on any unfamiliar tool. Every platform tool in this curriculum is operated through CRDs, and their names tell you most of the model.- Verify the way the grader would: create, then
getand read status conditions, not just the apply exit code. - Know your contexts. The exam, like this lab, can put tasks on more than one cluster.
kubectl config get-contextsbefore anything else. - Read the whole task before typing. The last clause is usually the graded one.