CNPA Study Plan — four weeks to the associate

Most study plans fail in the same way: they take the syllabus, count the domains, and give each one an equal slice of the week. The CNPA blueprint punishes that immediately, because it is not an even exam — one domain is 36% of your score and two others are 8% each. Study evenly and you will spend the same hours on a domain worth four and a half times less. This page is the corrective: a four-week plan that turns the official weights into an explicit hours budget, tells you what to read and drill each week, hands you a day-by-day final week, and gives you objective gates that say “ready” or “not yet” without you having to guess.

Place yourself first — the readiness self-assessment

☺ Like you’re 10: Before you start walking, work out where you’re standing. Some people need four weeks. Some need eight. Answering twelve honest questions tells you which.

“Four weeks” is not a fact about the CNPA; it is a fact about a particular starting point. The exam is knowledge-based and multiple-choice — six domains, twenty-seven competencies, no cluster, no terminal — so what you are building is a mental map, not muscle memory. How long that takes depends almost entirely on how much of the map you already carry. Score yourself before you plan.

Two published numbers set the shape of every drill on this page. The Linux Foundation’s Multiple Choice Exam FAQ gives the CNPA 120 minutes — it is the one named exception to the 90 minutes the other multiple-choice exams get — and sets the pass mark for multiple-choice exams at 75%. It does not state a question count — for the CNPA or for any exam — so the sixty questions our papers run to is a study convention of this site. Spread the published 120 minutes across that convention and you get two minutes a question, not ninety seconds, which is a materially different rhythm: you have room to eliminate properly rather than to skim. Practise at two minutes and target comfortably above 75%. (Exam details are revised from time to time — re-check the FAQ and the official CNPA page on the day you register.)

Twelve statements — one point each

Give yourself a point for each statement you could defend out loud, right now, to a sceptical colleague. Not “I’ve heard of it” — explain it, in a sentence, without looking.

• ① Kubernetes floor
• I can read a Deployment and a Service manifest and say what each field does
• I can explain what a controller is and why Kubernetes is level-triggered, not event-triggered
• I know what a namespace, an RBAC Role and an admission webhook each do
• ② Platform vocabulary
• I can define a golden path and say how it differs from a mandate
• I can explain platform as a product and who the customer is
• I can name the planes of a reference platform architecture from memory
• ③ Delivery & APIs
• I can state the four OpenGitOps principles and why “apply from CI” fails two of them
• I can explain what a CRD buys you over a template, and what an operator adds
• I can describe the difference between CI and CD without hand-waving
• ④ Watching & measuring
• I can separate metrics, logs, traces and events and say when each is the right tool
• I can name the four DORA metrics and what each one is trying to reveal
• I can explain what a policy engine does at admission time, and why that beats a wiki page

The arithmetic — allocate hours by weight, not by domain

☺ Like you’re 10: Six boxes, but they are not the same size. Pour your hours into them in the same shape as the marks: the big box gets the most.

Here is the whole method in one formula. Decide a total domain-study budget — the hours you will spend reading and explaining, not counting mocks and review. Then:

hours for a domain = total domain-study hours × that domain’s weight. Nothing else. No “this one feels hard so I’ll double it,” no “I like observability so I’ll start there.” The blueprint already told you the answer; your only decision is the total.

This plan uses 40 hours of domain study plus 10 hours of practice, mocks and review — a 50-hour budget over four weeks, about 12.5 hours a week, or roughly 1 hour 45 minutes a day. That is a real commitment but not an unreasonable one for a working engineer. Applying the formula to 40 hours:

Read the last column, because it is the entire argument of this page. An even split underfunds Core Fundamentals by 7.7 hours — more than half of what that domain actually needs — and overfunds the two 8% domains by 3.5 hours each. You would spend a full working day too long on Measuring, which can only ever win you eight marks, and a full working day too little on the domain that decides more than a third of the paper.

Points per hour — why weighting is the only fair split

Divide it the other way and the elegance shows. At 40 hours across 100 weighted points you are buying 0.4 hours per exam point — 24 minutes a point. Because every domain is funded in proportion to its weight, every domain returns exactly 2.5 points per hour. That constant is the whole reason to do it this way: you have made every study hour worth the same, so there is no hour you should have spent somewhere else. An even split breaks that constant badly — an hour on Core Fundamentals would be worth 5.4 points while an hour on Measuring would be worth 1.2.

Do the arithmetic for your budget

Forty hours may be wrong for you. Fine — change the total, keep the shape. This script does the split and prints the same comparison for any budget you hand it:

python3 - 40 <<'PY'
import sys

budget = float(sys.argv[1])          # total DOMAIN-STUDY hours (mocks/review are separate)
domains = [
    ("Core Fundamentals",                     36),
    ("Observability, Security, Conformance",  20),
    ("Continuous Delivery",                   16),
    ("Platform APIs & Provisioning",           12),
    ("IDPs & Developer Experience",             8),
    ("Measuring your Platform",                 8),
]
even = budget / len(domains)
print(f"{'domain':38}{'wt':>5}{'by weight':>12}{'even':>9}{'delta':>9}")
for name, w in domains:
    hrs = budget * w / 100
    print(f"{name:38}{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 exam point  ·  {100/budget:.2f} points per hour")
PY

Run it with python3 - 24 if you only have three weeks of evenings, or python3 - 60 for the six-week Lane B pace. The shape never changes, and neither does the constant points-per-hour return — which is exactly why the method survives a shrinking calendar.

The domain map — weight, hours, pages, practice

☺ Like you’re 10: One row per part of the test. It tells you how long to spend, which pages to read, and which questions to answer afterwards.

This is the plan’s reference table. Everything after it is just a calendar wrapped around these six rows. The middle column is what you read to pass; the CNPA hub has a second mapping into the deeper CNPE lessons if you want to properly understand. The last column is what you do after reading — because reading is not studying until you have been asked a question you could get wrong.

Two structural facts from the blueprint shape how you use this table. First, Core Fundamentals and Observability/Security together are 56% — a clean majority of the paper from two rows. Second, GitOps appears in three domains: as “Continuous Delivery and GitOps” inside Core Fundamentals, as “GitOps Basics and Workflows” and “GitOps for Application Environments” in the delivery domain, and as the “Kubernetes Reconciliation Loop” in the APIs domain. Reading the GitOps page once properly pays out in three places — treat it as the single highest-leverage 90 minutes in the plan.

Week 1 — a cold diagnostic, then Core Fundamentals

☺ Like you’re 10: First, take a practice test before you’ve revised anything — that sounds mad, but it shows you exactly where the holes are. Then spend the rest of the week on the biggest part of the exam.

Week 1 is 12.5 hours: 2.5 on the diagnostic and its write-up — the full 120 minutes of paper plus a 30-minute write-up — and 10.0 on Core Fundamentals. That leaves 4.4 hours of Core Fundamentals deliberately unspent, banked for a week-4 revisit — spacing beats cramming, and the biggest domain is the one that most deserves a second pass.

Day 1 — sit a paper cold, before you revise anything

This feels wrong and it is the most valuable two hours of the month. Sit the CNPA mock exam end to end, timed at the real 120 minutes, with no notes and no tabs, before you have read a single domain page. You will score badly. That is the point: the score is not a grade, it is a map. A cold diagnostic tells you three things a warm one cannot — which domains are already fine, which are empty, and which ones you thought were fine and are not. That third category is where exams are lost.

Then spend thirty minutes writing it up. Per domain: score, and one line naming the pattern in what you missed. Do not correct anything yet, and do not re-read the questions. You want the diagnostic preserved intact — the “four sittings” section below explains why spending a paper on day 1 is exactly right and spending a second one in week 2 is not.

Days 2–7 — the 36% domain

Ten hours on Core Fundamentals, which is seven competencies: declarative resource management, DevOps practices in platform engineering, application environments and infrastructure concepts, platform architecture and capabilities, platform engineering goals/objectives/approaches, continuous integration fundamentals, and continuous delivery and GitOps. Roughly 85 minutes each, in that order, with the domain page as your spine and the deeper pages as the elaboration.

End every session the same way, because retrieval is what moves knowledge: close everything, take a blank sheet, and write one paragraph explaining the competency you just covered as if to Foxy. Then open the page and mark what came out thin. The thin bits are your week-4 revisit list.

kind create cluster --name cnpa
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd rollout status deploy/argocd-server --timeout=300s

# once an Application is syncing with selfHeal:true, break it on purpose:
kubectl -n demo scale deploy/web --replicas=7
# watch the reconciler put it back
kubectl -n demo get deploy/web -w

Weeks 2 & 3 — the middle four domains

☺ Like you’re 10: Two more weeks, two domains each. Read, explain it out loud, then answer questions on it while it’s still fresh.

Both weeks run to 12.5 hours: 11.2 of domain study and 1.3 of drilling. The pairing is deliberate — each week couples a bigger domain with a smaller one, so you always finish a week having completed something.

Week 2 — Continuous Delivery (16%) + Platform APIs (12%)

6.4 hours on Continuous Delivery & Platform Engineering: CI pipelines overview, the CI/CD relationship, GitOps basics and workflows, GitOps for application environments, and incident response in platform engineering. Then 4.8 hours on Platform APIs & Provisioning Infrastructure: the Kubernetes reconciliation loop, CRDs as self-service APIs, infrastructure provisioning with Kubernetes, and the operator pattern.

These two belong together because they share a spine. The reconciliation loop that makes GitOps work is the controller loop that makes CRDs and operators work; it is one idea wearing two hats. Study them in the same week and you learn it once instead of twice.

Finish the week by sitting all sixteen questions of the Continuous Delivery & Platform APIs bank — one bank, both of this week’s domains — plus one non-negotiable exercise: draw the reconciliation loop from memory — desired state, actual state, observe, diff, act, repeat — and label where drift enters and where self-heal corrects it. If you cannot draw it unprompted, you have not finished week 2, whatever the clock says.

Week 3 — Observability, Security & Conformance (20%) + IDPs & DevEx (8%)

8.0 hours on the 20% domain: observability fundamentals (traces, metrics, logs and events), secure service communication, policy engines for platform governance, Kubernetes security essentials, and security in CI/CD pipelines. Then 3.2 hours on IDPs & Developer Experience: simplified access to platform capabilities, API-driven service catalogs, developer portals for platform adoption, and AI/ML in platform automation.

Two traps live in this week. The first is treating “observability” as “we have Prometheus” — the exam wants the distinctions: what a metric can answer that a log cannot, why a trace exists at all, and how an event differs from both. The second is skimming AI/ML in platform automation because older cloud-native syllabi never mentioned it. The CNPA curriculum names it explicitly. Read the page.

Close week 3 with all sixteen questions of the Observability, Security & Conformance bank and the six 🦆 DevEx questions in the IDPs, DevEx & Measuring bank — leave that bank’s six 🐿️ Measuring questions alone until week 4 — then write one blank-sheet paragraph on each of the four signals.

Week 4 — the final seven days, day by day

☺ Like you’re 10: The last week isn’t for learning new things. It’s for finding the last few holes, filling them, and arriving rested.

12.5 hours, and only 3.2 of them are new material. The rest is the highest-value activity left available to you: turning near-misses into certainties.

Shift the day names to fit your own exam date; the sequence is what matters. The two rules that must survive any reshuffle: the full mock lands four days before the exam (early enough to act on, late enough to be representative), and the last full day contains no new material at all.

Four sittings, spent carefully — using the mocks without burning them

☺ Like you’re 10: Practice tests are like a bag of sweets — once you’ve eaten one, it’s gone. If you do the same test twice in a week you’re just remembering the answers, not knowing them. Space them out.

A practice paper is a consumable measuring instrument. The first time you sit it, it measures your knowledge. The second time — if it is soon enough that you remember the questions — it measures your memory of that paper, which is worth nothing and, worse, flatters you into thinking you are ready. This is the single most common way candidates mis-time a certification: they re-sit until the score looks good and mistake recall of a paper for command of a syllabus.

So spend your sittings like money, and know how much money there is. This site gives you two CNPA-shaped question sources. First, four full sixty-question mock papers (Set 1, Set 2, Set 3, Set 4), all on the same domain split so their scores are comparable — 240 questions in total. Second, four domain-scoped banks, 68 questions between them: Core Fundamentals (24), Observability, Security & Conformance (16), Continuous Delivery & Platform APIs (16) and IDPs, DevEx & Measuring (12). The practice-questions hub is not itself a bank — it is the technique page that teaches you how to work them, and it is worth an hour on its own.

That is 308 question instances — and fewer distinct propositions than that, because the papers deliberately overlap. They have to: Core Fundamentals alone is 36% of the blueprint, twenty-two questions on every paper, eighty-eight across the four, and “what a platform is, declarative versus imperative, golden paths, reconciliation” does not contain eighty-eight separate ideas. The repeats are reworded and days apart, which makes them spaced retrieval practice rather than padding — for a knowledge-based exam that is how durable recall gets built. But it does mean the corpus is smaller than 308 suggests, so plan the spend before the first one — four sittings, each with a different job:

Score two numbers, every sitting

Older versions of this plan told you to answer only questions you had never seen and skip the rest. That instruction cannot be followed, and it was never true that the papers and banks were disjoint — they overlap deliberately on the high-weight core, because Core Fundamentals is 36% of a six-domain blueprint and four papers cannot find eighty-eight separate ideas in it. So do the opposite: sit every paper and every bank complete, start to finish, and record two numbers instead of one.

1. Your raw score. The whole paper, marked normally. This is the number you compare across sittings and against the 75% pass mark.
2. Your recognised score. Before you check the answer, tick any question whose idea you have met on an earlier sitting — same proposition, different wording. Mark that subset separately.

The second number is the one that predicts exam day. A recognised question answered instantly and correctly is knowledge that has consolidated across a gap of days, which is exactly what the exam will ask for. A recognised question you get wrong is the single highest-value item in your entire revision: you have now met that idea at least twice and it has still not stuck, so your first score on it flattered you. Send it straight to the mistake log, ahead of everything else in the queue, and write the rule properly.

Hesitation counts too. If a familiar proposition takes you thirty seconds, log it as amber — it is not yet automatic, and under a 120-minute clock the slow ones cost you the questions you never reach.

The three rules that keep a paper honest

One: never re-sit a paper you can remember. The practical test is simple — read the first three questions. If you can recall the answer before reading the options, the paper is spent for measurement purposes. Use it for revision instead (which is a fine second life) and get your verdict from questions you have not seen.

Two: twenty-one days minimum between re-sits of the same paper. Three weeks is long enough for question-level recall to fade while concept-level knowledge stays. That is why Sitting A is on day 1 and Sitting D on day 24 — the gap is engineered, not incidental. If your calendar compresses to three weeks, do not compress the gap; move Sitting D to the last available day and accept less repair time.

Three: a re-sit only counts if the conditions match. Same clock, same closed-book rule, same one-pass discipline. A “90%” earned with a glossary tab open is not a 90%. Remember that the associate-tier exams are closed book — unlike the performance-based CNPE, CKA and CKS, where you may consult the official Kubernetes documentation. There is no tab to fall back on, so do not practise with one.

Schedule the four sittings the moment you start, and put them in a calendar rather than in your intentions:

python3 - <<'PY'
import datetime

start = datetime.date.today()
plan = [
    ( 0, "Sitting A  - full mock, COLD, timed 120 min, no notes"),
    ( 7, "Core bank  - cnpa-practice-core.html          (24 q, over 3 sessions)"),
    (14, "Sitting B  - cnpa-practice-delivery.html      (16 q, delivery + APIs)"),
    (21, "Sitting C  - cnpa-practice-observability-security.html (16 q)"),
    (21, "           + cnpa-practice-idp-measuring.html (DevEx chip, 6 of 12)"),
    (23, "           + cnpa-practice-idp-measuring.html (Measuring chip, 6 of 12)"),
    (24, "Sitting D  - full mock re-sit, 120 min, closed book  (>=21d after A)"),
    (27, "Gate check - blank sheet: 6 domains, weights, 27 competencies"),
    (28, "Day before - light recall only, logistics, early night"),
]
for offset, what in plan:
    d = start + datetime.timedelta(days=offset)
    print(f"{d:%a %d %b}   day {offset:2d}   {what}")
PY

The mistake log — turning a wrong answer into a rule

☺ Like you’re 10: Every question you get wrong is a free lesson — but only if you write down what the lesson was. Otherwise you’ll get it wrong again next week.

Here is the uncomfortable truth about practice questions: the score is nearly worthless and the wrong answers are nearly priceless. A candidate who sits four papers and never writes anything down will make the same three mistakes in all four. The mistake log is the mechanism that stops that, and it is the highest-return habit on this entire page.

The log itself

Two files. One row per wrong answer, one rule per pattern. Keep it in plain text so it is greppable and diffable:

mkdir -p ~/cnpa-prep
cd ~/cnpa-prep

printf '%s\n' 'date,sitting,domain,stem_gist,i_answered,correct,why_i_missed,rule' > mistakes.csv
: > rules.md

printf '%s\n' \
  '2026-07-22,A,delivery,"CI job runs kubectl apply on merge — is it GitOps?",yes,no,"confused automation with reconciliation",R1' \
  >> mistakes.csv

cat >> rules.md <<'MD'
## R1 — pushed apply is not GitOps
When a question describes CI running `kubectl apply` on merge, the answer is
**not GitOps**: it satisfies *declarative* and *versioned* but fails *pulled
automatically* and *continuously reconciled*. Drift between merges goes
uncorrected. Trigger words: "pipeline applies", "on merge", "CI credentials".
Distractor that fooled me: "it's automated, so it must be GitOps."
MD

grep -c '' mistakes.csv

Converting a wrong answer into a rule

A raw wrong answer is a data point; a rule is reusable. The conversion has four parts, and a rule is not finished until all four are written:

Part 4 is the one everyone skips and the one that actually earns marks. Multiple-choice exams are won by eliminating, and the answer that nearly caught you once will be dressed up differently and sent back. Naming why it is attractive-but-wrong inoculates you against the whole family of that distractor, not just the instance.

Finally, tag each rule with its domain and count them. If seven of your twelve rules are Core Fundamentals, that is not bad luck — it is the 36% domain telling you where the remaining marks live. Re-read that domain page, not the syllabus.

When you are ready — the objective gates

☺ Like you’re 10: “I feel ready” isn’t a measurement. Here are five things you can actually check, like a pre-flight list.

Confidence is a terrible readiness signal — it peaks early, before you know enough to know what you do not know, and it dips exactly when you are becoming competent. Replace it with gates. All five must pass on day 27; any that fails tells you precisely what the remaining days are for.

Gates you should ignore

Three signals feel like readiness and are not. “I’ve read everything” — reading is input, not evidence; the gates measure output. “My last practice score was great” — on questions you had seen before, which measures memory. And “I’m still finding things I don’t know” — you will be, forever; a syllabus is not a finite list of facts, and waiting for that feeling to stop is how a four-week plan becomes a four-month one. Gates one to five are sufficient. Book the exam.

The day before, and the sitting itself

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

Everything on day 28 is designed around one finding that holds across every kind of exam: on the last day, new material costs you more than it gains. It displaces consolidated knowledge, it manufactures anxiety about a topic you will probably not be asked, and it eats the sleep that does more for recall than any revision session could. So the day-before protocol is deliberately small.

The day-before checklist

• ① Logistics — do these first, while there is still time to fix them
• Run the system check from the exam provider on the actual machine you will use
• Confirm your government-issued photo ID and that the name matches your registration exactly
• Re-read the current candidate handbook on the official page — proctoring rules, permitted items, room requirements
• Clear the room: desk empty, second screen unplugged, phone out, door closed and lockable
• Check the exam start time in your own timezone, and set two alarms
• Test webcam, microphone and network on the same machine, in the same room, at the same time of day
• ② Light recall — 45 minutes, no more
• Read rules.md top to bottom, once, slowly
• Blank-sheet the six domains and weights one final time (3 minutes)
• One pass of the flashcards or the glossary — recognition, not learning
• ③ Stop
• No new pages. No new practice questions. No new tools. Nothing you have not seen before.
• Eat properly, get outside for twenty minutes, sleep eight hours

In the sitting

Four habits that convert knowledge into marks on a multiple-choice paper. Answer everything — there is no benefit to a blank where a considered guess costs nothing. Eliminate before you select: strike the two obviously wrong options first, which turns a 25% guess into a 50% one and often reveals the answer outright. Flag and move rather than grinding — at 120 minutes across sixty questions your budget is two minutes each, so a question you sit on for six costs you two questions elsewhere; mark it, move, come back with a fresher head. And read the stem for its qualifier — words like best, first, most likely and except are doing real work, and most “trick questions” are simply qualifiers that were read too fast. The practice-questions hub drills all four as technique, which is why it is worth reading before you spend a single bank.

Afterwards, whatever the result: write the last entries in your mistake log while the paper is fresh. If you passed, those notes are the starting point for the CNPE — same territory, higher gear, and the lab track is where it starts. If you did not, you now own the most accurate gap list you will ever have, and the plan above re-runs in half the time.

Two companions to this page. How to study for these exams goes deeper on the technique — spacing, retrieval, interleaving and why re-reading feels productive and isn’t. The Kubernetes baseline is the floor everything here stands on, and is where Lane C should start. When you have passed, the certifications overview maps where to go next.