CNPE Study Plan — ten weeks to the professional

The CNPE punishes a study plan built the way most people build one: read every domain page once, in blueprint order, evenly. That plan fails for two separate reasons here. First, the five domains are not equal — two of them are 25% of the paper and two are 15%, so an even split still misallocates real hours. Second, and more importantly, the CNPE is performance-based: nobody asks you to recognise a correct Argo CD Application, they hand you an empty terminal and a live cluster and ask you to produce one, inside 120 minutes, needing 64% or above to pass. Reading a lesson page is necessary and nowhere near sufficient. This page is the corrective: a ten-week plan that turns the official weights into an explicit hours budget, wires every domain to its lesson, its lab track and its practice bank, hands you a week-by-week build schedule, tells you how to spend six mock exams without wasting them, and gives you objective gates that say "ready" or "not yet" without asking you to guess.

Place yourself first — the readiness self-assessment

☺ Like you’re 10: Before you plan ten weeks of building, find out how much building you can already do. Some people need ten weeks. Some need sixteen. Twelve honest checks tell you which.

"Ten weeks" is not a fact about the CNPE; it is a fact about a particular starting point — someone with solid kubectl fluency who has never built a whole platform end to end. The exam is performance-based and online-proctored: a Linux remote desktop, a terminal, a browser, one or more live clusters, and 15–20 tasks to complete in 120 minutes (the task count is from the Linux Foundation's Important Instructions: CNPE page, not the FAQ, which states only the pass mark). You need 64% or above. There is no multiple choice to fall back on and, unlike a knowledge exam, no amount of re-reading substitutes for having built the thing before with your own hands. Score yourself before you plan.

One more fact shapes every week below, and it surprises almost everyone the first time they read it: the CNPE is not broadly open-book. During the exam you may open only kubernetes.io/docs (and its translations), kubernetes.io/blog, whatever a task's own Quick Reference box links, and documentation installed locally on the machine (man pages, /usr/share). Argo CD, Flux, Tekton, Argo Rollouts, Crossplane, Backstage, Prometheus, OpenTelemetry, Kyverno, Gatekeeper, Istio and Helm are all squarely inside the exam domains, and none of their doc sites are on that list — see the docs map and what you must know cold. That single fact is why this plan spends so many hours on labs rather than lessons: reading about a Rollout teaches you the shape; typing one from a blank file, with no tab to fall back on, is the actual skill being scored.

Twelve statements — one point each

Give yourself a point for each statement that is true right now, on a real keyboard — not "I've read about it," but "I have done this, cold, without a browser tab open to remind me."

• ① The Kubernetes floor
• I can generate a Deployment, Service and ConfigMap with kubectl create --dry-run=client -o yaml and hand-edit the result without checking kubectl explain for the basic fields
• Before I touch anything in a task, I always run kubectl config use-context and pin the namespace first — every single time, without being reminded
• ② GitOps & CI/CD (25%)
• I can write an Argo CD Application (or a Flux GitRepository + Kustomization) from a blank file, with prune and selfHeal set correctly, from memory
• I can configure a canary rollout that shifts traffic in steps and explain exactly what makes it abort
• ③ Platform APIs & Self-Service (25%)
• I can write a CRD with a validation schema and explain what its controller does when the object is deleted
• I can write a Crossplane XRD + Composition + Claim, or precisely explain why a claim is stuck NotReady
• ④ Observability & Operations (20%)
• I can wire a ServiceMonitor to a real target and write the PromQL for an error rate without opening a browser tab first
• I can write a PrometheusRule alert and explain what a burn-rate SLO alert is actually watching for
• ⑤ Security & Policy (15%)
• I can write a Kyverno (or Gatekeeper) policy in audit mode, then flip it to enforce
• I can scope an RBAC Role + RoleBinding to one namespace and write a default-deny NetworkPolicy with one explicit exception
• ⑥ Exam craft
• I can run a universal triage sequence — describe, events, logs, previous logs — on a broken pod without stopping to think what command comes next
• I can name the four resources the CNPE actually lets me open, and list at least six tool doc sites that are not on that list

The arithmetic — allocate hours by weight, not evenly

☺ Like you’re 10: Five boxes, but not the same size. Pour your practice hours into them in the same shape as the marks — the two big boxes get five more hours each than the small ones.

The CNPE blueprint splits the work into five weighted domains:

Decide a total domain-study budget — hours spent reading, labbing and drilling one domain, not counting foundations, integration or mocks, which get their own budget below. Then:

hours for a domain = total domain-study hours × that domain's weight. No "GitOps feels more fun so I'll linger," no "security is scary so I'll save it for last." The blueprint already answered the question; your only decision is the total.

This plan uses 100 hours of domain study — spread across seven of the ten weeks — plus a separate 50-hour bookend for foundations, integration, the six mock sittings and the four-day taper that carries the last two of them. Applying the formula to 100 hours (a deliberately round number: it makes every domain's hours equal to its weight number, so the arithmetic below is easy to check with a calculator):

The CNPE's weights are flatter than the CNPA's — nothing here is worth 36% or as little as 8% — so weighting matters less dramatically than it does for the associate exam, but it is not nothing. An even split still underfunds each 25% domain by 5 hours and overfunds each 15% domain by 5 hours. Given that half the paper — a clean 50% — lives in the two 25% domains, five hours misdirected away from each of them is real: it's most of a whole week's domain-study budget, redirected toward the two domains that can, between them, only ever return 30% of the score.

Points per hour — and why this one isn't just a metaphor

Divide 100 hours across 100 weighted points and every domain returns 1 point per hour — a clean constant, and unlike the equivalent claim for a knowledge exam, this is not a loose analogy for the CNPE. The six mock exams later on this site's practice bank are literally scored this way: eighteen tasks, weighted exactly to the blueprint, worth 100 points total. So when you fund GitOps & CD at 25 hours instead of 20, you are directly buying the same 25 points a real mock sitting assigns that domain. Split evenly and an hour on Architecture is worth 20% more than it should be, while an hour on GitOps or Platform APIs is worth 20% less — and the deficit compounds across two domains at once.

The full ten-week bill plus the final taper, and do the arithmetic for your own budget

100 hours is the domain-study line only. The whole plan also carries an 8-hour Week 1 (foundations and cluster habits), a 14-hour Week 9 (integration, drilling and your first full mock) and a 20-hour Week 10 (both simulator sessions and Sets 3–5) — 142 hours across ten weeks, about 14 hours a week, unevenly spread (as light as 8 hours in Week 1, as heavy as 20 in Week 10) — and then a four-day taper, days 71–74, worth 8 hours more and carrying the last two sittings, for 150 hours in all. That is a serious commitment, deliberately heavier than the associate-level CNPA plan's 12.5 hours a week — building takes longer than reading, and this is the professional exam. If 150 hours is wrong for you, change the total and keep the shape:

python3 - 100 <<'PY'
import sys

budget = float(sys.argv[1])          # total DOMAIN-STUDY hours (foundations/integration/mocks are separate)
domains = [
    ("GitOps & Continuous Delivery",        25),
    ("Platform APIs & Self-Service",        25),
    ("Observability & Operations",           20),
    ("Platform Architecture & Infrastructure", 15),
    ("Security & Policy Enforcement",         15),
]
even = budget / len(domains)
print(f"{'domain':40}{'wt':>5}{'by weight':>12}{'even':>9}{'delta':>9}")
for name, w in domains:
    hrs = budget * w / 100
    print(f"{name:40}{w:4}%{hrs:11.1f}h{even:8.1f}h{hrs - even:+8.1f}h")
print()
print(f"total {budget:.1f}h  ·  {budget/100:.2f} h per blueprint point  ·  {100/budget:.2f} points per hour")
PY

Run it with python3 - 70 if seven weeks is all you have, or python3 - 130 if you want more lab reps per domain. The shape survives a shrinking calendar; only the total should move.

The domain map — weight, hours, lessons, labs, practice bank

☺ Like you’re 10: One row per part of the test. It tells you how long to spend, which lesson to read, which lab to actually build, and which practice pile to work afterwards.

This is the plan's reference table — everything after it is a calendar wrapped around these five rows. Read the lesson to understand the idea; build the lab to prove you can do it; drill the bank to find out what you still fumble under a clock.

One skill doesn't have its own weighted row and still shows up inside every single task: diagnose & remediate. Almost every CNPE task starts from something already slightly wrong, and the exam does not grade your explanation, it greps your cluster's actual state. Run the troubleshooting labs alongside whichever domain you're on, and keep the triage playbook and the speed reference open in a tab while you work — not during the exam, but every single week before it.

Weeks 1–4 — cluster habits, foundations, then the exam's first 40%

☺ Like you’re 10: Week one, get your tools ready. Then one week for the small foundation domain, two weeks for the first big one.

Week 1 — cluster habits and the baseline (8 hours)

Before any domain page, build the habits that every later week assumes. Stand up a local cluster (Lab 0 of the lab track), read what & why we platform, platform as a product and the reference architecture, then run the readiness self-assessment above. Spend real time on the docs map now, not in Week 9 — knowing on day one that Argo CD's own docs will not be open on exam day changes how you study every week that follows.

# the cluster habits every later week assumes
kind create cluster --name cnpe-prep
kubectl get nodes
kubectl get ns

# a tiny alias kit, muscle-memory from week 1
alias k=kubectl
export do='--dry-run=client -o yaml'
export now='--force --grace-period=0'

# practise the boilerplate-generation habit immediately
kubectl create deployment web --image=nginx --replicas=3 $do > web.yaml
kubectl explain deployment.spec.template.spec.containers.resources

Week 2 — Platform Architecture & Infrastructure (15 hours)

☺ Like you’re 10: This is the ground everything else stands on — who shares the cluster, who gets evicted first, and what it all costs.

Read Architecture & Infrastructure, then work through the twelve architecture labs: multi-tenancy boundaries, quotas and LimitRanges, scheduling and affinity, autoscaling to zero, storage classes, and putting a number on cost with OpenCost. Close the week with an untimed cold pass at the Architecture practice bank, scoring yourself against the bands on the practice-tasks page.

Weeks 3–4 — GitOps, then CI/CD & Progressive Delivery (25 hours)

☺ Like you’re 10: Two weeks for the biggest single domain — first the poster-and-robot idea, then the safe way to ship changes onto it.

Week 3 (12.5 h): read GitOps Workflows — the four OpenGitOps principles, reconciliation and drift, Argo CD vs Flux, repo structure — then work the GitOps labs: install Argo CD, watch an Application go Synced, cause drift on purpose and watch it revert, then do the equivalent the Flux way.

Week 4 (12.5 h): read CI/CD & Progressive Delivery, then work the CI/CD labs: a Tekton pipeline building an image with no Docker daemon, then an Argo Rollouts or Flagger canary that promotes a good version and rolls back a bad one automatically. Close the week with a full, untimed pass at the GitOps & CD practice bank — one bank covers both weeks, because the exam's own competency does too.

Weeks 5–8 — Platform APIs, then Observability, then Security

☺ Like you’re 10: The other big domain first — turning messy YAML into a self-service button — then watching everything, then locking it down.

Weeks 5–6 — Platform APIs & Self-Service (25 hours)

Week 5 (12.5 h): read Platform APIs, CRDs & Operators, then work the CRD-and-controller half of the Platform APIs labs: write a CRD with a validation schema, scaffold a controller with Kubebuilder, watch it reconcile a custom resource into real Deployments and Services.

Week 6 (12.5 h): read Self-Service & Portals, then finish the labs with Crossplane compositions and a Backstage software template. Close the week with a full, untimed pass at the Platform APIs & Self-Service practice bank.

Week 7 — Observability & Operations (20 hours)

☺ Like you’re 10: Build the watchtower — then break something on purpose and use it to find out why.

Read Observability & Operations, then work the twelve observability labs: install the Prometheus stack, wire a ServiceMonitor, write PromQL and a recording rule, make an alert fire, push a trace through OpenTelemetry into Jaeger, and defend an SLO with a burn-rate alert. Close with a full, untimed pass at the Observability practice bank.

Week 8 — Security & Policy Enforcement (15 hours)

☺ Like you’re 10: The guardrails — say no at admission time, not after something has already gone wrong.

Read Security & Policy, then work the twelve security labs: a Kyverno policy from audit to enforce, RBAC scoped to a tenant, a default-deny NetworkPolicy, strict mTLS with Linkerd or Istio, an image scanned and signed. Close with a full, untimed pass at the Security practice bank.

Weeks 9–10 — integrate, drill, and the final stretch

☺ Like you’re 10: Now wire all the pieces into one working platform, then spend the last stretch proving you can do it fast, under a clock, with the pressure on.

Week 9 — integrate, drill, and the first full sitting (14 hours)

Build the lab track's capstone: wire Backstage, Argo CD, Crossplane, the rollout, the dashboards and the policies into one golden path, so a brand-new service ships with no hand-written manifest. Read anti-patterns, best practices, the tool landscape and the case studies to connect the five domains into one coherent story. Then sit Mock Exam Set 1 — 120 minutes, closed to everything but the permitted docs — the first time all five domains meet each other under a single clock. Because Set 1 is assembled from the banks you have just spent eight weeks drilling, a low score here cannot be a knowledge problem — it is a pacing problem, and pacing is the cheapest thing on this whole plan to fix. Spend the rest of the week on the mistake log and a re-drill of whatever domain dropped points.

Week 10 and the four-day taper — day by day, the simulator, and the last five sittings (20.5 + 8 hours)

Only new material here is whatever your Set 1 gaps demanded. Everything else is proof.

Six mock exams, spent carefully — using them without burning them

☺ Like you’re 10: A practice test for a "pick the answer" exam is like a bag of sweets — eat it twice and the second time you're just remembering the wrapper. A practice test for a "build the thing" exam is more like practising scales on a piano: playing the same scale five times doesn't ruin it, it's the whole point.

The CNPA study plan spends a long section on why you must never re-sit a knowledge paper inside twenty-one days: the moment you recognise the correct proposition — "the answer is C, GitOps means pull not push" — the paper stops measuring knowledge and starts measuring memory of that specific paper. The CNPE's six mock exams are a genuinely different situation, and it is worth being precise about why, because the instinct to treat them the same way would cost you good practice for no reason.

A CNPE mock does not ask you to recognise anything. It asks you to produce a working Argo CD Application, a passing Kyverno policy, a canary that actually promotes. Recognising the shape of the task in advance saves you the five minutes you'd otherwise spend reading the brief carefully — it does not let you skip typing the manifest, wiring the selector, or watching the "done when" check actually pass on a live cluster. That is closer to genuinely fine than the CNPA situation, and it is fine on purpose: doing the same category of task — write a canary, write a default-deny policy, wire a ServiceMonitor — across five different mock papers is exactly the spaced retrieval practice that turns "I read how to do this" into "my hands already know how to do this." That repetition is the goal, not a leak.

Where real burning still happens

The risk doesn't disappear, it just moves to a narrower target. Three things genuinely waste a CNPE mock:

• Re-sitting the identical numbered paper. Do Set 4 twice inside a fortnight and you'll remember which exact Deployment name was broken and which exact field the CRD was missing — you'll finish fast and feel great, and you'll have measured your memory of that scenario, not your ability to diagnose an unfamiliar one. This site gives you six distinct papers precisely so you never have to do this — see the differences below.
• Drilling a bank task until you're typing memorised YAML instead of reading the brief and reasoning from the fields. The practice-tasks page is explicit about this: do every task cold, and re-do failures the next day rather than re-reading the worked solution five times in a row.
• Reading a worked solution before you've genuinely attempted the task. This converts a mock from a skill measurement into a copying exercise, and copying exercises don't survive contact with a blank terminal on exam day.

The six papers are built to make the first mistake hard to make by accident:

The mistake log — for hands-on work

☺ Like you’re 10: Every stumble is a free lesson, but only if you write down exactly what tripped you and what the fast, correct move actually was.

A CNPE mistake log tracks a different shape of error than a multiple-choice one. There's no wrong option to eliminate next time — there's a command you reached for slowly, a manifest you had to hunt for the field names of, a root cause you diagnosed wrong, or worst of all, perfect work applied in the wrong namespace. Four categories cover almost everything:

Keep it in two plain-text files, the same way the CNPA plan does, adapted for hands-on shape:

mkdir -p ~/cnpe-prep
cd ~/cnpe-prep

printf '%s\n' 'date,sitting,domain,category,task_gist,what_slowed_me,rule' > mistakes.csv
: > rules.md

printf '%s\n' \
  '2026-07-22,SetA,gitops,knowledge,"hand-edited a synced Deployment, got confused when it reverted",thought selfHeal was a bug not a feature,R1' \
  >> mistakes.csv

cat >> rules.md <<'MD'
## R1 — a reverted edit is selfHeal working, not a bug
When a live edit to a GitOps-managed resource disappears within seconds, that
is **selfHeal correcting drift**, not a broken cluster. The fix always goes
into Git, never onto the running object.
Trigger: "I changed it and it changed back."
What slowed me down: I spent four minutes checking controller logs for an
error before realising there wasn't one — the system was working exactly as
configured.
MD

grep -c '' mistakes.csv

Every rule gets the same four parts: the trigger (what you'll see in a task that means this applies), the rule (the correct move, stated generally), the because (the concept underneath it), and what slowed you down (the wrong turn, named specifically so you recognise it faster next time). Tag each rule with its domain and count them weekly — a cluster of rules in one 25% domain is the plan telling you exactly where Week 10's spare hour belongs.

When you're ready — the objective gates

☺ Like you’re 10: "I feel ready" isn't a measurement, especially for building things — confidence and skill move on different clocks. Here are five things you can actually check.

All five should hold in the final days of Week 10. Any that doesn't tells you exactly what's left to do.

Gates you should ignore

Three feelings masquerade as readiness here and aren't. "I've read every lesson" — reading is input, the gates measure output, and this exam only scores output. "My lab worked once" — once, warm, with the solution fresh in your head, is not the same as cold two weeks later; that's what the mock sittings are for. "I understand why it works" — understanding is necessary and the exam does not grade your explanation, it greps your cluster's state. Gates one through five are sufficient. Book the exam.

The day before, and the sitting itself

☺ Like you’re 10: The night before, the best thing you can do is stop building, check your kit, and sleep. Really.

New material on the last day costs more than it gains — it displaces consolidated muscle memory and eats the sleep that protects it. Keep the day before deliberately small.

The day-before checklist

• ① Logistics — while there is still time to fix them
• Run the exam provider's system check on the actual machine you'll use
• Confirm your government-issued photo ID matches your registration exactly
• Re-read the current Important Instructions: CNPE page — proctoring rules, permitted items, environment versions
• Clear the room: desk empty, second screen unplugged, phone out, door closed and lockable
• Check your exam start time in your own timezone and set two alarms
• Test webcam, microphone and network in the same room, at the same time of day
• ② Light recall — 45 minutes, no more
• Read rules.md top to bottom, once, slowly
• One pass of the Know-It-Cold manifests — recognition, not learning
• Re-read the docs map once, so the allowlist boundary is fresh
• ③ Stop
• No new labs. No new tools. No new mock. Nothing you haven't built before.
• Eat properly, get outside for twenty minutes, sleep eight hours

In the sitting

Habits that turn muscle memory into points on a performance-based paper. Context first, every task — use-context, then pin the namespace, before touching anything; perfect work in the wrong place scores zero. Read every task before you start and bank the cheap ones first — sequential order is a trap. Flag anything past its fair share of time — roughly five to seven minutes per task at this pace — and come back later with a fresher head. Verify, don't assume: after every task, run kubectl get/describe (or hit the endpoint) and confirm the change is really live before you move on. And remember partial credit is real: with a 64% bar, several candidates have passed with tasks left untouched, so an unfinished paper can still clear the bar — getting most of the way through many tasks beats perfecting a few. All of this is drilled at length in Field Notes and the triage playbook — read both once more this week, not for new facts, but so the habits are the last thing in your head before the timer starts.

Afterwards, whatever the result: write the last entries in your mistake log while it's fresh. If you passed, that log is the starting point for whatever comes next — see the certifications overview. If you didn't, you now own the most accurate gap list you'll ever have, and this plan re-runs in half the time, because the labs are already built.

Two companions worth reading alongside this page. The CNPE Exam covers registration, cost, killer.sh and what candidates report about the sitting itself. Field Notes distils first-hand accounts into the tactics that keep recurring. And if the associate-level exam is part of your path too, the CNPA study plan is the same method applied to a knowledge-based paper — read it once to see exactly how differently "burning a mock" works when the thing being tested is a memorised proposition rather than a skill.