Field Notes — how people actually passed

Every other page on this site teaches you the material. This one asks what individual people who sat the exam chose to publish afterwards — how it felt, what they wished they'd practised, which resources moved the needle. It now covers both credentials, and deliberately not in the same proportions. Part One distils the CNPE, which launched first and already has a small shelf of detailed public write-ups. Part Two is the CNPA, which launched in 2025 and — as of this writing — simply does not have that shelf yet. We went looking. Here is exactly what we found, what we didn't, and what's still worth doing about it.

Part One — CNPE: what sitting the exam is actually like

☺ Like you're 10: Two hours, a real computer with real broken things on it, and a pile of jobs to fix. Nobody asks you to pick A, B, C or D.

Start from what is officially documented, because that is the only guaranteed part. The CNPE is a 120-minute (2-hour), performance-based, online proctored exam. You work inside a Linux-based remote desktop, solving tasks using the terminal and web-based interfaces. Tasks are performed on designated SSH hosts rather than the base system; kubectl (aliased to k), yq, curl, wget and man pages are pre-installed. Proctoring uses streaming audio, video and screen sharing. Component versions — currently Kubernetes v1.35 and etcd v3.6 — are stated in the official Important Instructions page and updated regularly, so check it for the versions in force on your exam date. No multiple choice, no essay: a cluster, a set of tools, and a list of things that must be true by the time the clock stops.

How many tasks, really?

This is the number the community gets wrong most often. The Linux Foundation's official instructions state the CNPE consists of 15–20 performance-based tasks. One candidate — Michał Tomczak, writing up his own sitting — reported 17 tasks, and several third-party prep sites now repeat "17 tasks" as if it were fixed. It isn't. Seventeen sits inside the official 15–20 band, so it is a plausible single exam form — one data point, not a guarantee.

Planning arithmetic, not trivia

Plan for the worst case: up to 20 tasks in 120 minutes — an average of six minutes per task including reading, doing and verifying, and the tasks are not evenly sized. That single piece of arithmetic explains almost every tactic later in this part: why people flag and move on, why they don't deliberate over tool choice, why docs-navigation speed beats recall. Two more official anchors: a score of 64% or above is required to pass (official CNPE FAQ, confirm current cut score before you sit), and results are emailed within roughly 24 hours of completing the exam. Martin Hope's community write-up independently reports the same 64% and 24 hours — a consistency check, not extra authority.

"The hardest hands-on exam CNCF ever released"

That characterisation is Tomczak's. His argument isn't that individual tasks are cryptic — it's that the exam asks you to enable workflows rather than configure isolated objects. A CKA task tends to be "make this Pod schedulable." A CNPE task, in his account, is closer to "make it possible for a developer to get X without filing a ticket." That demands a product mindset — the why behind a capability, not only the how of one CRD. If that framing feels unfamiliar, spend an hour with Platform as a Product before another hour of YAML.

The preparation strategies that keep recurring

☺ Like you're 10: Four habits show up in almost every story: read the syllabus properly, build one whole thing instead of many small things, practise finding answers in the manual, and break stuff on purpose.

Read enough write-ups and the same four practices surface regardless of the author's background. They are not glamorous. They are, apparently, what works.

1. Dissect the syllabus, bullet by bullet

Tomczak's first pillar is syllabus-driven preparation: take the official CNCF curriculum, go domain by domain, and translate every single bullet into a practical task you can perform on a cluster. Not "read about Composition Functions" — "write an XRD, a Composition and a claim that produces a namespace with a quota." He treats the CNCF Platforms White Paper as the source of truth for vocabulary and framing, and the curriculum PDF as the checklist. A syllabus bullet is a noun phrase; an exam task is a verb — if you can't state a bullet as a verb with a success condition, you don't know it yet. The Exam Guide lays the domains out with weights; the Checklist is the verb-shaped version; the CNPE Study Plan turns both into weeks.

2. Build a whole platform, not a pile of tutorials

The second pillar is the one most people skip. Rather than following twenty isolated tool tutorials, build a complete Internal Developer Platform from scratch so that multiple tools must work together — then spin it up, destroy it and rebuild it repeatedly. The integration is the lesson: Argo CD syncing a Crossplane claim that provisions a database a Backstage template just requested is a very different mental object from three separate "hello world" installs. The Lab Track is structured exactly this way, and the Reference Architecture gives you the target shape.

3. Documentation-navigation drills

Every write-up says a version of this. Paul Yu puts it most directly: you do not need to memorise, because you get docs in the exam; the skill is navigating them fast, and "the difference between passing and failing is often how efficiently you find what you need." Tomczak's third pillar turns that into a drill — practise navigating each project's official docs until you have a mental map of where the config examples live. Hope adds the behavioural rule: if you don't recognise something, go straight to the docs instead of reasoning from first principles.

4. Break things on purpose

Paul Yu recommends deliberately breaking things and then fixing them, which dovetails with the rebuild habit. A platform you only ever saw working teaches you the happy path; a platform you have broken teaches you the failure signatures — the wording of an ImagePullBackOff event, what a Crossplane claim looks like when the Composition doesn't match, what a Degraded Argo CD app shows in its resource tree. Reliability & Incidents and Anti-Patterns catalogue the signatures worth inducing on purpose.

The reference practice stack and exam-day tactics

☺ Like you're 10: Here's the whole toy platform one person built to practise on, and the exact playbook people used when the clock started.

Tomczak published the stack he built as his practice platform — complete, with every exam domain represented and the pieces wired together rather than parked side by side. You don't need these exact tools; you need an equivalent that exercises the same capabilities.

The reference stack

# 0. a throwaway cluster (destroy and rebuild this often — that IS the practice)
kind create cluster --name idp-lab

# 1. D2 — delivery: Argo CD, then Argo Rollouts for canary
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# 2. D2 — CI inside the cluster: Tekton pipelines
kubectl apply -f https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

# 3. D3 — the self-service control plane: Crossplane + a database provider
helm repo add crossplane-stable https://charts.crossplane.io/stable && helm repo update
helm install crossplane crossplane-stable/crossplane \
  --namespace crossplane-system --create-namespace
kubectl apply -f https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.25/releases/cnpg-1.25.0.yaml

# 4. D4 — observability: metrics, dashboards, traces
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kps prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace
# ^ installs Prometheus + Grafana + Alertmanager
helm repo add jaegertracing https://jaegertracing.github.io/helm-charts
helm install jaeger jaegertracing/jaeger --namespace observability --create-namespace

# 5. D5 — policy and runtime security
helm repo add kyverno https://kyverno.github.io/kyverno
helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco --namespace falco --create-namespace

# 6. D1 — cost visibility per namespace
helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm install opencost opencost/opencost --namespace opencost --create-namespace

The biggest time trap: unfamiliar tooling

Martin Hope's central lesson is blunt and probably worth several percentage points: the biggest time trap is unfamiliar tooling, not domain complexity. You already know how to think about progressive delivery. What kills you is meeting tkn for the first time under a running clock. The prescribed response: when you don't recognise something, go straight to the docs rather than reasoning from first principles — and spend extra prep time on the tools outside your daily work, not the ones you already like.

The triage loop

Tactical advice converges remarkably across authors. Read every task first — five minutes converting an unknown pile into a ranked queue. Flag and move at 5–7 minutes — Tomczak's rule, endorsed by Hope: with partial credit in play and up to twenty tasks to cover, nine minutes on one task costs you the two tasks you haven't read yet. Don't analysis-paralyse on tool choice — where a task lets you pick, pick one and execute; two minutes deliberating between Kustomize and Helm produces zero credit either way.

GUI when it's faster, terminal for everything else

The exam gives you web interfaces as well as a terminal. Tomczak's advice: use the GUI when it's genuinely faster — his example is reading a GitOps dependency graph, which a UI shows instantly and a CLI makes you assemble in your head — but terminal speed is still the backbone. Clicking is slow, imprecise under stress and hard to redo. The heuristic: read in the GUI, write in the terminal.

A troubleshooting sequence worth having in your fingers

Paul Yu gives an explicit order — rehearse it until it costs seconds, not thought:

# 1. what exists, and what state is it in?
k get pods,deploy,svc -n "$NS" -o wide
k get applications -n argocd            # or: k get kustomizations -A  (Flux)

# 2. what does the object itself say? (events live at the bottom of describe)
k describe pod/"$POD" -n "$NS"
k get events -n "$NS" --sort-by=.lastTimestamp | tail -20

# 3. what did the process say before it died?
k logs "$POD" -n "$NS" --tail=100
k logs "$POD" -n "$NS" --previous --tail=100      # the crash before the restart

# 4. what does the platform's own telemetry say?
# PromQL in Grafana/Prometheus, e.g. sum by (pod) (rate(container_cpu_usage_seconds_total{namespace="$NS"}[5m]))

# 5. what does the CONTROLLER think? (the step people skip)
k describe application "$APP" -n argocd | sed -n '/Status/,$p'
k logs -n kyverno deploy/kyverno-admission-controller --tail=50
k get crd | grep -i crossplane && k get composite,claim -A

Step 5 is the one that separates CNPE troubleshooting from CKA troubleshooting: when a platform misbehaves, the Pod is frequently innocent — the controller that was supposed to create it never reconciled, or an admission policy silently rejected it. Ask the controller.

The materials, the write-ups, and reading them critically

☺ Like you're 10: This is the shopping list, and then the four people who wrote the whole thing down.

One resource is already in your pocket if you've registered: exam registration includes two Killer.sh simulator attempts, each granting 36 hours of access from activation (official CNPE FAQ), presenting a graded scenario set — the product page cites 20 questions — modelled on the real exam.

For budgeting: the CNPE exam costs $445 USD and includes one free retake, with 12 months of exam eligibility from purchase, and is valid for 2 years from your pass date. Verify current pricing at checkout. And once the reading is done, drill against the real thing: Mock Exam 1 on this site, then Killer.sh.

The four accounts

Reading them critically

Two habits keep you out of trouble. First, separate observation from inference: "I had 17 tasks" is an observation and almost certainly true; "the exam has 17 tasks" is an inference from a sample of one, and it's wrong. Second, notice how third-party sites launder single reports into fact — at least one prep site now states "17 tasks" flatly with no attribution. You'll see the exact same pattern show up again in Part Two, except there the honest answer isn't "one number got over-quoted" — it's "there almost isn't a number to quote yet."

Part Two — CNPA: what public accounts exist (and their limits)

☺ Like you're 10: This test is so new that almost nobody has written the "here's exactly how it went" story yet. We looked hard. Here's what's actually out there.

The CNPA was introduced by CNCF in mid-2025 and is a genuinely young credential — it simply hasn't had years to accumulate the kind of write-up pile the CNPE has in Part One. We ran a deliberate search for public CNPA pass accounts, blog posts and forum threads before writing this section, rather than assuming either "plenty exist" or "none exist." The honest finding sits in between: we found three public first-hand accounts, and one of them turns out to describe a pre-launch beta sitting rather than the exam most readers will actually take. That is a thin record — nowhere near Part One's four detailed, cross-referencing write-ups — and this page will not dress it up as more than it is.

The three accounts, distilled

What's genuinely useful here, and what to discount

Three things are worth keeping. First, two independent accounts agree on 120 minutes and a pure multiple-choice format — a real (if small) consistency check on the official page. Second, both accounts that discuss content agree the questions are scenario- and judgement-based rather than definition-recall — you're asked to reason about a situation, not to recite a term. Third, mock-exam practice is the one preparation tactic all three independently converge on, exactly as it is for the CNPE in Part One.

Preparing from the CNPA's own mechanics

☺ Like you're 10: When you don't have enough reviews to trust, read the rulebook instead — it's short, and it's guaranteed to be true.

With first-hand testimony this thin, the more reliable move is to reason forward from what the CNPA officially is, rather than backward from three accounts. Four facts anchor everything else: it's 120 minutes — the Linux Foundation's one stated exception to the 90 minutes other multiple-choice exams get; the pass mark is 75% or above; it is fully closed-book — the Resources Allowed page states plainly that candidates are not permitted to access tools, resources or external sites during any Linux Foundation multiple-choice exam, CNPA included; and it is scored across six weighted domains.

What closed-book changes versus the CNPE's docs-open model

This is the single biggest structural difference between the two parts of this page, and it flips the CNPE's most-repeated tactic on its head. Part One's docs-first reflex works because the CNPE lets you look things up — speed of navigation is the skill. The CNPA allows none of that: no kubernetes.io, no notes, nothing. Every fact has to already be in your head when the question appears. That means the CNPA rewards recall and recognition under time pressure, not lookup speed — closer in spirit to a school exam than to an open-book practical.

Turning domain weights into a time-and-attention budget

Treat the weights as a budget, not decoration. Core Fundamentals at 36% is worth more than a third of your score on its own — start there, and pair it with What & Why We Platform and Platform as a Product. Add the 20% Observability, Security & Conformance domain and you're accounting for 56% of the exam from two domains. The three 8–16% domains are where candidates under-invest because they feel narrower — they aren't; each is cleanly testable and cheap to shore up in an afternoon. The CNPA Study Plan turns this exact table into a week-by-week schedule, and the CNPA Mock Exam is where you find out whether the plan worked.

Borrowing discipline from KCNA and KCSA — inference, not CNPA testimony

☺ Like you're 10: Since almost nobody has reviewed the new park yet, we're peeking at reviews of the older, very similar park next door — and saying clearly that's what we're doing.

Two older Linux Foundation associate credentials — KCNA (Kubernetes and Cloud Native Associate) and KCSA (Kubernetes and Cloud Native Security Associate) — sit in the same family as the CNPA: multiple-choice, closed-book, associate-level, no hands-on component. Both have run for years and have accumulated a real body of public pass write-ups, unlike the CNPA. Everything in this section is reasoning by analogy from that older, more mature record — it is explicitly not first-hand CNPA testimony, and it should be weighted accordingly.

What KCNA/KCSA write-ups consistently report

Public accounts of both exams converge, independently and repeatedly, on the same handful of tactics: budget time per question up front rather than discovering the pace partway through (a stated example: at roughly 1.5 minutes per question, spending 3 minutes on one leaves you with barely a minute for each remaining item); read the full question and eliminate obviously wrong options before picking; flag anything you're unsure of and return to it once the easy questions are banked; and study for understanding what a resource does and why rather than memorising exact command syntax, since these are knowledge exams, not typing tests. Sitting these exams is reported to take most candidates a few weeks of moderate, steady study rather than a cram sprint — the opposite pacing from Part One's compressed CNPE timelines.

What does not transfer

Be equally clear about the limits. Domain content doesn't transfer — KCNA is Kubernetes/cloud-native fundamentals and KCSA is Kubernetes security specifically, while the CNPA's six domains are platform-engineering-shaped (GitOps, self-service APIs, developer portals, DORA metrics) and only partially overlap either one. Timing doesn't transfer, as above. And difficulty framing doesn't transfer cleanly either: multiple KCNA/KCSA write-ups describe those exams as approachable for anyone with foundational Kubernetes exposure, while the two live CNPA accounts we found both describe it as harder than its official "Beginner" label suggests. Borrow the study habits; verify every number against the CNPA's own official pages.

What's common to both exams, and where they genuinely diverge

☺ Like you're 10: Some advice works no matter which test you're taking. Some advice only works for one of them. Knowing which is which saves you from practising the wrong thing.

Strip away the tooling and both parts of this page converge on the same three habits. Mock-exam discipline — burn a real timed attempt (Killer.sh for CNPE, the CNPA Mock Exam here) specifically to find gaps, not to reassure yourself. A mistake log — every wrong answer or failed task recorded with why you got it wrong, which How to Study for a CNCF Exam covers as a cert-neutral method for both credentials. And honest, objective readiness signals — a target score on a real mock, not a feeling — booked as a forcing function rather than deferred until you "feel ready," which by most accounts never quite arrives on its own.

Where they diverge is exactly where their grading models diverge. The CNPE rewards hands-on muscle memory and docs-navigation speed — you're never asked to recall a manifest from nothing, only to produce or find one fast enough. The CNPA rewards closed-book recall and multiple-choice recognition speed — nothing to look up, so the fact has to already be loaded, and the skill is spotting which of four plausible sentences is actually correct. Train the first by building, breaking and rebuilding a cluster. Train the second by explaining concepts out loud until they're boring and grinding practice questions until you stop second-guessing the right answer.