How to Study for a CNCF Exam

Most people who fail a CNCF exam did not fail because the material was too hard. They failed because they studied the way they studied at school — reading front-to-back, highlighting, re-reading the highlights — and that method is almost perfectly mismatched to how these exams are scored. This page is the method, not the material. It works for both credentials on this site, and it says out loud exactly where the two diverge: the CNPE is performance-based — 120 minutes, 15–20 hands-on tasks on live clusters, 64% to pass — and the CNPA is knowledge-based multiple choice across six weighted domains, with 120 minutes and a 75% cut score. Same subject. Two completely different training regimes. (As always, confirm current format, duration and cut score on the official CNCF and Linux Foundation pages before you register — those figures get revised.)

Two exams, two training regimes

☺ Like you’re 10: One test watches your hands. The other reads your mind. You practise hands by doing; you practise knowing by explaining.

Everything else on this page follows from one distinction, so get it straight first. A performance-based exam grades the state you leave behind. Nobody watches how you got there — if the Application ends up with prune and selfHeal on, you scored, whether you typed it, patched it, or pasted it from the docs. A knowledge-based exam grades which option you selected. Nobody cares whether you could have built the thing; they care whether you can tell a correct statement from three plausible neighbours.

Those two grading rules point at opposite skills. Performance rewards speed and recall of shape — the ability to produce a correct manifest without thinking about where the fields go. Knowledge rewards discrimination — the ability to hold four near-identical sentences side by side and notice that one of them says “push” where it should say “pull.”

Where the methods diverge

Most of this page applies to both. This table is the part that does not — pin it up somewhere.

The one habit both exams reward

Retrieval. Not reading — retrieval. The act of pulling something out of your head with the book shut is what moves it from “recognised” to “owned,” and it is the only study activity whose difficulty is a feature. Re-reading feels smooth and teaches almost nothing; a blank page feels awful and teaches a lot. Every technique below is a different wrapper around the same core move: shut the tab, produce the thing, then check.

Read the curriculum as a checklist, not as prose

☺ Like you’re 10: The exam publishes a list of everything it can ask. Turn that list into a to-do list with ticky boxes, instead of reading it once like a story.

Both exams ship a published curriculum: a list of domains, each with a weight, each containing competencies. Almost everybody reads it once, nods, and then goes off to watch a video course. That is the single biggest wasted asset in exam prep. The curriculum is not an introduction — it is the specification of the question pool. Nothing outside it can be asked, and everything inside it can.

Turn every competency into a verb

Curriculum lines are written as nouns: “Declarative Resource Management.” Nouns cannot be ticked off, because there is no moment at which you have finished a noun. So rewrite each one as something you either can or cannot do:

Notice the shape difference. The CNPE column always contains a verb plus a clock. The CNPA column always contains a sentence you could say out loud. If your rewrite has neither, you have written a mood, not a study item.

Build a confidence ledger

Now make it queryable. A plain text file beats any app here, because you want to be able to sort it and count it without leaving the terminal you are already living in. One line per competency, with a confidence score you update honestly after every session. Seed it with your exam’s domains — the file is the same shape either way:

mkdir -p ~/cncf-prep && cd ~/cncf-prep

printf 'competency|domain|conf|last\n' > ledger.psv

If you are sitting the CNPE, the domain column carries its five weighted domains:

cat >> ledger.psv <<'EOF'
Application and infrastructure deployment|D2 GitOps 25%|0|never
Progressive delivery strategies|D2 GitOps 25%|0|never
CRDs and the operator pattern|D3 Platform APIs 25%|0|never
Self-service golden paths and portals|D3 Platform APIs 25%|0|never
Metrics, logs, traces and alerting|D4 Observability 20%|0|never
Cluster and tenant architecture|D1 Architecture 15%|0|never
RBAC, admission policy and supply chain|D5 Security 15%|0|never
EOF

If you are sitting the CNPA, it carries its six — weighted 36 / 20 / 16 / 12 / 8 / 8, which is a much more lopsided blueprint and so a much more opinionated ledger:

cat >> ledger.psv <<'EOF'
Cloud native architecture and the reconciliation loop|D1 Core Fundamentals 36%|0|never
Kubernetes primitives and platform building blocks|D1 Core Fundamentals 36%|0|never
Signals, SLOs and platform security posture|D2 Observability Security Conformance 20%|0|never
GitOps principles and deployment strategies|D3 Continuous Delivery 16%|0|never
CRDs, operators and infrastructure provisioning|D4 Platform APIs 12%|0|never
Golden paths, portals and developer workflows|D5 IDPs and DevEx 8%|0|never
DORA metrics and platform adoption measures|D6 Measuring your Platform 8%|0|never
EOF

Either way, one line per published competency — copy the wording from your curriculum rather than paraphrasing it, so the ledger and the blueprint stay diffable. Score each line 0–3 on a scale that has nothing to do with feelings: 0 = never attempted; 1 = did it with the docs open; 2 = did it cold but slowly; 3 = did it cold, inside budget, twice, on different days. Only a 3 counts as done. Then the ledger answers the only question that matters at the start of a session — “what should I work on today?”

cd ~/cncf-prep

awk -F'|' 'NR>1 && $3<=1 {printf "%-46s %-22s conf=%s  last=%s\n", $1, $2, $3, $4}' ledger.psv | sort -t' ' -k2

awk -F'|' 'NR>1 {s[$2]+=$3; n[$2]++} END {for (d in s) printf "%-22s avg %.1f over %d competencies\n", d, s[d]/n[d], n[d]}' ledger.psv | sort

The second command is the one that changes behaviour: it prints an average confidence per domain, which you can hold next to the published weights. A domain worth 25% sitting at average confidence 1.0 is where your next four sessions go — regardless of which topic you happen to find interesting.

Let the weights allocate your hours

Both blueprints are lopsided, and both reward reading the bars literally. For the CNPE the two delivery-and-API domains are 25% each — half the paper between them. For the CNPA a single domain, Core Fundamentals, is 36%, and with the 20% observability-security-conformance domain that is 56% from two domains.

The three-pass method

☺ Like you’re 10: Go over everything three times — fast, then slow, then from memory. Not once, slowly, forever.

The instinct is to start at competency one and go deep until it is perfect, then move on. That produces a candidate who is superb at GitOps and has never seen a ResourceQuota, because time ran out. Three passes over the whole curriculum beats one perfect pass over a third of it, every time — because the exam samples the whole blueprint and a zero anywhere costs the same as a zero everywhere.

Pass 1 — survey (about 15% of your time)

Read the entire curriculum and skim one page per competency. Take no notes. The only artefact you produce is the ledger, scored honestly. This pass exists to kill surprises: by the end of it there should be nothing in the blueprint you have never heard of. Expect it to feel unproductive. It is buying you the ability to plan.

Pass 2 — build and explain (about 60%)

The long middle. Work domain by domain in weight order, taking every ledger line from 0/1 to at least 2. This is where the regimes split hardest: CNPE candidates spend this pass with their hands on a cluster, working the lab track and the GitOps labs; CNPA candidates spend it explaining — reading a page, closing it, and writing the competency out in their own words. Both finish a session by updating the ledger.

Pass 3 — compress (about 25%)

Nothing new is allowed in pass three. You are only doing three things: retrieving from a blank page, drilling the weak lines your ledger and mistake log agree on, and sitting timed papers. If you find yourself learning a brand-new tool in pass three, you have mis-scheduled — bank it as a known gap and accept the risk rather than blowing your revision on it.

Spaced repetition, and the drills on this site

☺ Like you’re 10: Things you learn leak out of your head. If you go back and grab them again just as they are about to leak, they stick much longer — and you have to do it less and less often.

Memory for anything you are not using daily decays, and it decays fastest right after you learn it. Reviewing something just as it is starting to fade resets the clock and flattens the curve, so each successive review can be further away than the last. That is the whole idea: review at increasing intervals, timed to just-before-you-forget. It is not a productivity fad; it is the single most evidence-backed study technique there is, and it is nearly free.

A schedule you will actually keep

Ignore the elaborate algorithms. A fixed 1 / 3 / 7 / 21 ladder captures nearly all the benefit and requires no software: when you learn something, revisit it tomorrow, then three days later, then a week later, then three weeks later. Anything you fumble on a review drops back to the start of the ladder. Anything you nail at +21 is done — trust it and stop spending time on it.

The cheapest possible implementation is a dated file. Add lines as you learn things; each morning, grep for today:

cd ~/cncf-prep

printf '%s|%s\n' "$(date -v+1d +%F)" "argocd Application: prune + selfHeal from memory" >> reviews.psv
printf '%s|%s\n' "$(date -v+3d +%F)" "argocd Application: prune + selfHeal from memory" >> reviews.psv

grep "^$(date +%F)|" reviews.psv || echo "nothing due today — go do a fresh task instead"

That date -v+1d form is BSD/macOS. On Linux the equivalent is date -d '+1 day' +%F. Either way, the point is that scheduling a review must cost you one line, or you will stop doing it by Thursday.

Flashcards — recall, not recognition

The flashcards player on this site serves cards one at a time, keeps the ones you fumble in rotation, and drops the ones you know — which is spaced repetition with the bookkeeping done for you. Two rules make it work and both are about honesty. First, answer out loud before you flip. If you flip first and think “yes, I knew that,” you have trained recognition, which is a much weaker memory than recall, and on a CNPE terminal recognition buys you nothing at all. Second, use a five-second rule. Anything you cannot start answering within five seconds is not known, however familiar it feels — mark it for practice and let it come back.

The quiz — training discrimination

The self-check quiz is the same material turned into questions with shuffled options and an explanation on every answer, which makes it a good general-recall drill for either exam. It is written around the CNPE’s material rather than the CNPA blueprint, though, so if you are sitting the associate exam it is a supplement, not your main event: your domain-by-domain work belongs in the four CNPA practice banks — Core Fundamentals, Observability, Security & Conformance, Continuous Delivery and IDPs & Measuring — and your timed work in the four mock sets (1, 2, 3, 4). Whichever bank you are in, a multiple-choice paper is not really testing whether you know the right answer; it is testing whether you can reject three wrong ones that were written to be attractive. So change what you do with a question:

• Before you pick, say why each of the other three is wrong. Not “this one feels right” — an actual reason, in words.
• When you get one right, read the explanation anyway. Right answers for wrong reasons are the ones that fail you on exam day, and they are invisible unless you check.
• When you get one wrong, classify it before you move on: did you not know the fact, or did you know the fact and misread the question? Those need completely different fixes.

CNPE candidates should still use both tools, but with a demotion in status: the deck exists so that vocabulary is free while your hands are busy. You should never spend exam seconds recalling what selfHeal does. Keep know it cold and the speed reference in the same bucket — they are there to make the typing automatic, not to make you competent.

How to run a lab so it teaches you something

☺ Like you’re 10: Before you press enter, say out loud what you think will happen. Then press enter and find out if you were right. The surprises are the lesson.

You can spend forty hours in a terminal and learn very little, and most people do. The reason is that typing commands from a page is a transcription exercise: your eyes move, your fingers move, and your model of the system is never once consulted, so it is never once corrected. The fix is one small ritual.

Predict, then verify

Before every command that changes something, state the prediction — out loud or, better, written down. What object will exist? With what field values? What will kubectl get show? What will break? Then run it, and check the prediction against reality. When the prediction is right you have confirmed your model cheaply. When it is wrong you have found the exact spot where your understanding is broken — which is the only thing in a lab that was ever worth your time.

cd ~/cncf-prep

cat > prediction.txt <<'EOF'
After the image change I expect:
 - TWO ReplicaSets for app=web: the old one scaled to 0, a new one at 3
 - the Deployment's own .spec.replicas still 3
 - rollout strategy RollingUpdate, so no full outage in between
EOF

kubectl create deployment web --image=nginx:1.25 --replicas=3
kubectl rollout status deploy/web

kubectl set image deploy/web nginx=nginx:1.27
kubectl rollout status deploy/web

kubectl get rs -l app=web \
  -o custom-columns='RS:.metadata.name,DESIRED:.spec.replicas,IMAGE:.spec.template.spec.containers[0].image'
kubectl get deploy web -o jsonpath='{.spec.replicas}{"\n"}'

cat prediction.txt

Two kubectl flags make prediction-checking almost free, and both are worth burning into muscle memory because they are also how you avoid disasters at work. --dry-run=server shows you what the API server would produce, defaults filled in and admission webhooks applied. kubectl diff shows you exactly what a manifest would change about the live cluster before it changes it:

kubectl apply -f app.yaml --dry-run=server -o yaml | head -40

kubectl diff -f app.yaml

Break it on purpose

Reading that self-heal reverts drift is worth roughly nothing. Causing drift and watching it get reverted, while you stare at the clock, is worth a lot — and the CNPE is heavy on scenarios where something is already wrong. So end every lab by sabotaging it:

kubectl -n argocd patch application checkout --type merge \
  -p '{"spec":{"syncPolicy":{"automated":{"prune":true,"selfHeal":true}}}}'

kubectl -n checkout scale deploy/checkout --replicas=7

kubectl -n checkout get deploy checkout -w

Then generalise the habit: delete a Service and watch what the Ingress does; remove a label and watch the Endpoints empty; set a bad image tag and read the exact wording of the resulting event. The break-fix drills and the triage playbook are built entirely around this move, because “find and fix what is wrong” is a task type the exam loves.

Time-box every rep — CNPE

Everything from here to the end of this section is written for the performance exam; the CNPA equivalent is the paragraph after it. A performance exam is a speed exam wearing a knowledge exam’s clothes. If the paper carries, say, 17 tasks in 120 minutes, that is roughly seven minutes each including reading the prompt, and some of those tasks are five-minute tasks, which means some are fifteen. An untimed lab therefore trains the wrong thing: it trains you to be correct eventually. Put a clock on every rep from pass two onward.

cat > ~/cncf-prep/drill <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
task="${1:?usage: drill <task-slug> [minutes]}"
budget="${2:-7}"
log="$HOME/cncf-prep/times.psv"
start=$(date +%s)
finish() {
  elapsed=$(( $(date +%s) - start ))
  printf '%s|%s|%ss|budget %sm\n' "$(date +%F)" "$task" "$elapsed" "$budget" >> "$log"
  printf '\n[logged] %ss on %s (budget %sm)\n' "$elapsed" "$task" "$budget"
}
trap finish EXIT
printf '>> %s -- you have %s minutes. Ctrl-C the moment you are done.\n' "$task" "$budget"
sleep $(( budget * 60 ))
printf '\n[time] Budget gone. Stop. Write down what blocked you, then look it up.\n'
EOF
chmod +x ~/cncf-prep/drill

~/cncf-prep/drill argocd-app-prune-selfheal 7

The log file matters more than the timer. After a fortnight, sort it and look at which task slugs keep appearing — those are your slow tasks, and slow tasks, not unknown tasks, are what cost most people the CNPE.

Time-box every rep — CNPA

The same principle, a different unit: you time question sets, not cluster tasks. The allowance is published — the Linux Foundation’s Multiple Choice Exam FAQ allows 90 minutes for multiple-choice exams with the explicit exception of the CNPA, which is allowed 120 minutes, and sets the pass mark at 75%. Over sixty questions that is two minutes a question, not the ninety seconds you would be training yourself to if you drilled at 90 minutes — a third faster than the pace you will actually sit at, and fast enough that you would learn to skim where you should be eliminating. So drill in blocks that keep the real rhythm: twenty questions in forty minutes from one of the practice banks, or a full sixty in 120 from a mock set. Log the same two numbers the CNPE candidate logs — elapsed time and which items you flagged — because a question you got right in three minutes is a slow question, and slow questions are what run a knowledge paper out of clock. (Re-read the FAQ before you book: these figures do get revised.)

Keep a mistake log

☺ Like you’re 10: Write down every mistake in one place. After a few weeks you will notice you keep making the same three — and those three are your whole revision list.

Individual mistakes are noise. Patterns of mistakes are the highest-value information you will generate during the whole plan, and you cannot see patterns without writing things down. One file, appended to the moment something goes wrong, never edited later.

What an entry contains

Five fields, and the second-to-last one is the one everybody skips and the one that does the work:

cat >> ~/cncf-prep/mistakes.md <<'EOF'

## 2026-07-22 · D2 GitOps · Argo CD Application
- what I was asked: enable prune and self-heal on an existing Application
- what I actually did: edited the live Deployment, then hunted the UI for a toggle
- what was really wrong: I did not know the path spec.syncPolicy.automated
- the fix in one line: spec.syncPolicy.automated.{prune,selfHeal}: true
- class: knowledge-gap
- redrill: 2026-07-25
EOF

“What was really wrong” is a different sentence from “what I did wrong,” and forcing yourself to write it is what converts a mistake into a lesson. “I got it wrong” is not actionable. “I did not know which object owns that field” tells you exactly what to read.

Classify it — the fix depends on the class

Once entries are classified, one command every Sunday tells you what kind of candidate you currently are:

grep -h '^- class:' ~/cncf-prep/mistakes.md | sort | uniq -c | sort -rn

grep -h '^- redrill:' ~/cncf-prep/mistakes.md | awk -v today="$(date +%F)" -F': ' '$2 <= today'

A log dominated by knowledge-gap means you are early — keep reading and building. A log dominated by recall-lag means you know the material and need speed drills. A log full of wrong-context means you need a ritual, not more study. The prescription is completely different in each case, which is why the classification is not busywork.

The two traps

☺ Like you’re 10: Copying someone else’s steps feels like learning but isn’t. Reading the whole manual feels careful but isn’t. Both are ways of avoiding the scary bit: doing it yourself with nothing open.

Trap one — tutorial-following

You follow a well-written walkthrough. Every command works. Nothing errors. You finish with a running Argo CD, a canary rollout and a warm sense of competence. Two days later you cannot produce any of it. This is the illusion of competence, and it is the most common failure mode in cloud-native prep because our tutorials are so good — a tutorial removes every decision, and decisions are the thing being examined.

The tell is simple: if you did not have to decide anything, you did not learn anything. Three ways to convert a tutorial into actual practice:

• Read it, close it, then do it. Skim the whole walkthrough once for the shape. Then shut the tab and reproduce it. Reopen only when properly stuck, and log a mistake when you do.
• Change the parameters. The tutorial used namespace demo and three replicas; you use team-a and two, with a different port and a different label selector. Everything that breaks is a thing the tutorial was hiding from you.
• Do it again on a clean cluster tomorrow. Rebuild speed is the real measure. A kind cluster is thirty seconds, so there is no excuse.

kind delete cluster --name drill || true
kind create cluster --name drill
kubectl config use-context kind-drill
kubectl get nodes

Trap two — over-reading the documentation

The opposite failure, and the one that catches conscientious people. Kubernetes documentation is enormous and unusually good, so it is genuinely pleasant to read — and reading it can absorb unlimited time while producing nothing you can retrieve. Worse, on a performance exam it produces a specific bad habit: you learn to find things instead of to know them, and then you burn four minutes navigating during a task you should have typed from memory.

Documentation has exactly two legitimate roles in a study plan. Role one: look-up during pass two, to answer a specific question you already have, after which you close the tab. Role two, and only for the performance exams: navigation practice. If you are permitted to consult official docs during the CNPE, then finding a page fast is itself a timed skill — practise it deliberately, from the docs map, and know roughly which page holds which example before you sit down. Confirm the current allowed-resources list in the official handbook rather than assuming.

The discipline that keeps both roles honest: never read documentation without a question. If you cannot say what you are looking for, you are browsing, and browsing is entertainment.

Build a weekly cadence

☺ Like you’re 10: Small amounts, most days, always at the same time. That beats one giant panic weekend, every time.

Study plans fail on scheduling, not on content. Four focused hours spread across a week beats eight hours on a Sunday, because spacing is doing half the work and because a two-hour block is where fatigue quietly turns study into transcription. Build the week around one non-negotiable session length you can actually protect.

The shape of a study week

That is four and a half hours a week — about six weeks for the CNPA and eight to ten for the CNPE if you already work with Kubernetes. The Sunday half-hour is the one people cut and the one that makes the plan self-correcting; without it you will keep studying whatever you enjoyed most last week.

A 60-minute session template

When you miss a week

You will. The rule is: do not restart, and do not try to make it up. Come back with a single 30-minute retrieval session on whatever the ledger says is weakest, take the score hit honestly, and resume the normal week. Candidates who try to repay lost hours in one weekend usually quit the plan entirely within a fortnight. A study plan you resume is worth ten study plans you abandon.

How to know you are actually ready

☺ Like you’re 10: “I feel ready” is not evidence. “I did it twice, cold, in time” is evidence. Only book the exam on evidence.

Confidence is not a readiness signal — it is a mood, and it correlates with how recently you read something rather than with whether you can produce it. Both exams have an objective bar, so measure yourself against an objective test.

CNPE — the performance signals

• Two full timed mock papers above the cut, on different days, with time left over. The pass mark is 64%; treat 75%+ as your personal bar so a bad day still passes. Sit them from the mock exam sets.
• Every domain has cleared the 15% floor. A single domain you skipped can be enough to sink a paper that averages fine.
• Median task time comfortably inside budget. With 15–20 tasks in 120 minutes, you are aiming to finish a typical task in roughly six to seven minutes and to have a plan for the two that will take fifteen. Your times.psv answers this, not your memory of it.
• You can rebuild your core stack on a clean cluster from memory — Argo CD installed and syncing an app, a policy that blocks something, a scraped metric — without opening a walkthrough.
• The mistake log has gone quiet, and what remains is recall-lag, not knowledge-gap.
• You know how to skip. You have practised abandoning a task at the four-minute mark, flagging it, and coming back — which is a skill, and one you can only get by rehearsing it.

CNPA — the knowledge signals

• Two full mock papers comfortably clear, with no single domain dragging. The published cut score is 75% and the allowance is 120 minutes — both from the Linux Foundation’s Multiple Choice Exam FAQ, which states no question count for any exam; the sixty-question papers here are this site’s own convention — so sit the papers at two minutes a question and set your personal bar in the mid-eighties, because our wording is not the CNCF’s and 75% here is not the same event as 75% there. Re-check the figures before you book; they do get revised.
• You can write every domain’s competencies out from a blank page, one paragraph each, without notes — all six domains, including the 8% ones people skip.
• You can articulate why the wrong options are wrong, not merely pick the right one. Test this by covering the correct answer and arguing against the other three.
• Near-miss entries have dried up in the mistake log across at least two sessions.
• You can teach it. Explain golden paths, reconciliation and DORA to someone who does not work in infrastructure and have them follow. If you cannot, you have memorised phrasing rather than meaning.

Signals that mean nothing

When the objective signals are green, book it. Waiting for the feeling is how people spend a year “almost ready” — and both credentials are testing a live, moving field, so the material ages while you hesitate. The readiness checklist is the same idea in tickable form; work it until it is green, then go.

The last 72 hours

☺ Like you’re 10: The three days before the test are for polishing what you have, not for learning anything new. And sleep counts as studying.

Whatever you do not know 72 hours out, you will not know on the day — so stop trying. The final stretch has one job: arrive rested, fast, and calm, with the mechanics rehearsed so that none of your attention goes to logistics.

T-72 to T-48 — the last real work

Your final full-length timed paper goes here, on an unseen set, under exam conditions: right time of day, no phone, no pausing. Sit it, mark it, and then — this is the point of doing it now — you still have two days to act on what it finds. Take the two weakest items, drill them, and stop. Do not open a new topic. If the paper reveals something big and unlearnable in two days, that is real information about whether to reschedule, and it is much better to have it now than an hour before you start.

T-48 to T-24 — compress and rehearse

No new material at all. Three activities only:

• Read your own artefacts — the mistake log end to end, and the ledger’s remaining 1s and 2s. Your own notes are worth more than any page now, because they are indexed by your actual weaknesses.
• Speed reps, not new reps. Five to eight tasks you already own, timed, just to keep the hands warm — for CNPE, straight from the bank. For CNPA, one pass through the deck at five seconds a card.
• Rehearse the logistics. Test the machine, the browser and the network against the published system requirements. If your sitting is proctored, confirm your ID matches your registration name exactly, clear the desk and the room, and know how long before the slot you must be online. Every one of these is a real, common reason people lose a booking — and the rules differ between the performance and associate exams and are revised over time, so see exam day for the run-through and read the official candidate handbook for your specific exam.

The final 24 hours

Deliberately light. A single short pass over your one-page compression sheet — the manifests and definitions from know it cold, or the six domain summaries — and then stop, early. Cramming the night before measurably damages performance on both exam types, because it trades the consolidation that sleep does for a few hours of shallow re-reading you will not retain. Eat properly, get the full night, and set two alarms.

One method, two regimes. Now go point it at something: if you are missing the substrate, start with the Kubernetes baseline; if you have it, open your curriculum and build the ledger; and when the objective signals turn green, read exam day and book it.