Know It Cold — the facts you must recognise instantly
The CNPE has a Know It Cold page full of YAML, because the CNPE is performance-based and half its manifests come from memory. The CNPA needs a completely different page, because it is knowledge-based, multiple-choice, and fully closed-book — there is no cluster to kubectl explain your way out of a forgotten field, and no Quick Reference box waiting to rescue you. Every fact on this page either sits in your head on exam day or it doesn't exist for you. This is not the broad reference — that job belongs to the concept reference — this is the short list of numbers, exact names, and paired distinctions that get blurred under a two-minute-a-question clock, with nothing external to jog your memory.
Imagine two different tests. One lets you bring a big recipe book but asks you to actually cook — that's the CNPE. The other takes the book away entirely and just asks you questions about cooking — "how many degrees for bread?", "what's the difference between simmering and boiling?" — and you either know it or you don't. This page is flashcards for the second kind of test: short, exact, and built to be checked without opening anything else.
Per the Linux Foundation's own Certification Resources Allowed page: "Candidates are NOT PERMITTED to access tools, resources or external sites when taking the Linux Foundation Multiple Choice … Exams." No kubernetes.io, no vendor docs, no notes, nothing. That single sentence is the entire reason this page exists in this shape — there is no "recovery move" for the CNPA the way kubectl explain rescues a forgotten CNPE field. What you carry into the room is what you have. The CNPA docs map covers the rules and the (non-existent) allowlist in full; the CNPA triage page covers what to do when a question stem tries to confuse you regardless.
If you only remember six things
☺ Like you’re 10: If you read nothing else on this page before you walk in, read this box.
- 120 minutes, 75% to pass, fully closed-book. No question count is published — do not lean on one you saw somewhere.
- The domain weights are 36 / 20 / 16 / 12 / 8 / 8, in that order: Core Fundamentals, Observability/Security/Conformance, Continuous Delivery, Platform APIs & Provisioning, IDPs & DevEx, Measuring. They sum to 100.
- DORA is four metrics measuring a delivery system, not a person: deployment frequency, lead time for changes, change failure rate, time to restore service (recent reports: failed-deployment recovery time).
- OpenTelemetry's established signals are traces, metrics and logs. Profiles is a real, active fourth signal — in public alpha, targeting general availability later in 2026 — but treat "OTel has three signals" as already dated and "OTel has four stable signals" as premature.
- CNCF maturity is Sandbox → Incubating → Graduated, and graduation certifies governance and adoption evidence (multi-org maintainers, a completed security review, documented adopters) — not that the project is technically "the best."
- A golden path is chosen; a mandate is enforced. That one distinction, or a close cousin of it, resurfaces in more question stems than any other single idea on this page.
Exam mechanics — the numbers you cannot afford to blur
☺ Like you’re 10: Before you learn anything about platforms, learn the shape of the test itself — how long, how many marks, what you're allowed to bring.
These come from the Linux Foundation's own pages, not from folklore. Two of them are the exact numbers other multiple-choice exams don't share.
The five facts, and the wrong number each one invites
| Fact | Value | The trap |
|---|---|---|
| Duration | 120 minutes | The Multiple Choice Exam FAQ names the CNPA as the one exception to the 90 minutes every other multiple-choice Linux Foundation exam gets. Don't default to 90. |
| Passing score | 75% or above | Same as other multiple-choice exams — but the CNPE's 64% is a completely different bar for a completely different exam format. Don't swap them. |
| Question count | Not published | A figure has circulated online for this exam. It does not appear on the official CNPA training page. State "not published," not a number. |
| Resources allowed | None — fully closed-book | Not "kubernetes.io only" (that's the CNPE's allowlist). The CNPA's own resources-allowed page says no tools, resources, or external sites at all. |
| Format | Online, remotely proctored, multiple-choice | No terminal, no cluster — nothing to kubectl explain. |
CNPA vs CNPE — don't cross the wires
CNPA: 120 minutes, 75% to pass, multiple-choice, knowledge-based, zero external resources. CNPE: 2 hours, 64% to pass, performance-based hands-on tasks (15–20 of them), with kubernetes.io/docs, kubernetes.io/blog, and task-linked Quick Reference pages permitted. Same family of certifications, opposite exam philosophies — a question that describes one and asks you to name its pass mark or its allowed resources is testing exactly this distinction.
The six domain weights — recognise them cold
☺ Like you’re 10: Six boxes, six sizes. Know which is the biggest and which two are the smallest without counting on your fingers.
Verify the arithmetic yourself, because a memorised wrong number is worse than no number: 36 + 20 + 16 + 12 + 8 + 8 = 100. Every domain page and the study plan are built on this exact split.
The six rows, in curriculum order
| # | Domain | Weight | Page |
|---|---|---|---|
| 1 | Platform Engineering Core Fundamentals | 36% | CNPA · Core Fundamentals |
| 2 | Platform Observability, Security & Conformance | 20% | CNPA · Observability, Security & Conformance |
| 3 | Continuous Delivery & Platform Engineering | 16% | CNPA · Continuous Delivery |
| 4 | Platform APIs & Provisioning Infrastructure | 12% | CNPA · Platform APIs |
| 5 | IDPs & Developer Experience | 8% | CNPA · IDPs & DevEx |
| 6 | Measuring your Platform | 8% | CNPA · Measuring |
| Total | 100% |
Two structural facts worth carrying in alongside the numbers themselves. First, domains 1 and 2 alone are 56% — a clean majority of the paper from two rows, which is exactly why Core Fundamentals gets more study hours than the other five combined in a weight-proportional plan. Second, the two 8% domains are still 16% together — do not let "smallest" slide into "skippable." A question that gives you a weight and asks you to name the domain, or gives you a domain and asks for its weight, is testing this table directly and nothing else.
A memory hook for the order
The weights fall in strict descending order as the curriculum lists the domains: 36, 20, 16, 12, 8, 8. If you can recite that six-number sequence in under three seconds, you already know the shape of the paper before you've read a single question.
DORA's four metrics — and the trap that catches almost everyone
☺ Like you’re 10: Four numbers that grade a delivery system — like a school's average test score, not any one student's.
DORA — DevOps Research and Assessment — publishes exactly four metrics, popularised by Accelerate and continued today by Google Cloud's annual State of DevOps research. They come in two pairs: two speed metrics and two stability metrics, deliberately opposed so nobody can look good by sacrificing one for the other.
The four keys, exactly
| Metric | What it measures | What it does not measure |
|---|---|---|
| Deployment frequency | How often the organisation successfully releases to production | Whether any single deploy was good — forty empty commits a day scores "elite" and means nothing |
| Lead time for changes | Time from a commit landing to that code running successfully in production | A team's internal notion of "cycle time" — DORA's clock starts at the commit, which folds review and CI queueing into the number; a narrower merge-to-prod slice is a different, smaller measurement |
| Change failure rate | The proportion of deployments that cause a failure in production | Severity or blast radius — a rate says nothing about how bad the worst failure was |
| Time to restore service | How long it takes to recover from a production failure | Root cause, or whether the same failure recurs — recovery speed and failure prevention are different disciplines |
The trap: system, not individual
Every one of the four keys is computed from timestamped events emitted by the delivery system itself — Argo CD sync events, CI pipeline events, deployment records — aggregated by team or by service. The moment a question implies attributing a DORA number to an individual engineer, that answer is wrong on its face: these are outcomes of a system — the pipeline, the golden path, the platform — not a performance review input. Attaching any of the four to compensation or to an individual's scorecard is the textbook way to trigger Goodhart's law: the measure stops meaning anything the moment it becomes someone's personal target.
One naming nuance worth carrying in cold: recent DORA reports refine the fourth key to failed-deployment recovery time, to make explicit that it concerns recovery from a bad change rather than any incident. Older material — and a lot of tooling — still says time to restore service, or loosely MTTR. Recognise all three names as the same metric. And DORA is silent on things that matter just as much: the inner developer loop, cost, security posture, and how the work actually felt — that gap is what DevEx and SPACE exist to fill.
OpenTelemetry's signal set — and exactly where "profiles" stands
☺ Like you’re 10: Three ways of watching an app that everyone agrees on, and a fourth way that's still being built in public.
OpenTelemetry's own documentation names traces, metrics, and logs as its established, stable signals — a request's path through your system, a measurement captured at runtime, and a recorded event, respectively. OpenTelemetry's own signals page actually lists a fourth entry right alongside them under "currently supports" — Baggage — but its job is different in kind: the same page describes it as "contextual information that is passed between signals," not telemetry data captured about your system the way a trace, a metric or a log is. A question testing this distinction is checking whether you noticed that difference in function, not whether you can recite the docs' bullet list.
Where "profiles" stands right now
The genuinely new fourth signal is profiles — continuous code-level profiling ("a recording of resource usage at the code level"), unifying under the same OTLP wire protocol as the other three. As of 2026 this has moved from proposal to public alpha, with OpenTelemetry's own project blog targeting general availability later in the year. Precision matters here in both directions: stating flatly that "OpenTelemetry has three signals" is already behind where the project's own documentation stands, and stating that profiles is a fourth stable, GA signal overclaims where it currently sits. The honest, exam-safe sentence is: three established signals, plus profiles as an actively-developed fourth, not yet generally available.
If a question asks you to name OpenTelemetry's signals and offers "traces, metrics, logs" as one option and "traces, metrics, logs, and events" or "…and baggage" as a tempting alternative, the safe, well-established answer is the first. If a question specifically asks about the emerging or newest signal, the answer is profiles — and its correct characterisation right now is "alpha," not "shipped."
CNCF project maturity — Sandbox, Incubating, Graduated
☺ Like you’re 10: Three steps on a ladder — brand new experiment, actually used by some people, and grown-up and trusted by lots of people — and climbing it means passing checks, not just being popular.
Every CNCF project sits at exactly one of three maturity levels, and the ladder only goes up:
The three levels
| Level | What it means |
|---|---|
| Sandbox | Experimental — not yet widely tested in production, on the bleeding edge of the technology |
| Incubating | Used successfully in production by a meaningful number of users, with a healthy pool of contributors |
| Graduated | Considered stable, widely adopted, and production-ready, with a large and diverse contributor base |
What graduation actually certifies
The trap is in the word certifies. Graduation is not a taste judgement that a project is "the best tool for the job" — it is a specific, checked bar: documented adoption by at least three independent production adopters, project maintainers drawn from at least two separate organisations (so no single vendor controls direction), a completed third-party security review with tracked findings, an OpenSSF Best Practices badge, and clear, vendor-neutral governance documentation. A Sandbox project can be technically excellent and still be Sandbox because none of that evidence has been assembled yet; a Graduated project can be clunky in places and still be Graduated because the governance and adoption bar is about trust and continuity, not elegance.
"Graduated" is a statement about governance, adoption evidence and security process — not a ranking of which project is technically superior, and not a guarantee that a project is bug-free or feature-complete. Do not pick an answer that equates graduation with "the CNCF's official recommended choice"; the CNCF hosts multiple graduated projects that directly compete with each other (Argo and Flux both graduated; Prometheus and OpenTelemetry both graduated).
Sharp distinctions that blur under pressure
☺ Like you’re 10: These are the pairs of words that sound almost the same but mean genuinely different things — and the exam loves to swap one for the other in a wrong answer.
Say each of these out loud, unprompted, before you rely on it in the room.
Seven pairs, one line each
| Pair | The one-line distinction |
|---|---|
| Declarative vs imperative | Declarative states the desired end state for a controller to reach and maintain; imperative issues a sequence of steps that happen once. A script full of kubectl create commands is imperative no matter what file format it's stored in — "written in YAML" is not what makes something declarative. |
| Golden path vs mandate | A golden path persuades by being the easiest route and can be left; a mandate forbids alternatives. What genuinely must be universal is enforced by policy — a guardrail — regardless of which path a team took, not by making the path the only door. |
| Capability vs interface | A capability is the useful thing the platform does for you — "give me a database," "ship my app." An interface is the door you use to ask for it — portal, CLI, or API. One capability is routinely offered through several interfaces at once. |
| SLI vs SLO vs SLA | An SLI is the measured number (e.g. the fraction of fast, successful requests). An SLO is your internal target for that number over a window. An SLA is the same promise made externally to customers, with consequences — often money — attached if you miss it, and is typically looser than the internal SLO guarding it. |
| Deploy vs release | Deploy puts a new version on the cluster; release exposes its behaviour to users. Feature flags, canaries and blue/green all exist to widen the gap between those two moments, which is exactly what makes a bad change cheap to undo. |
| Lead time vs cycle time | DORA's lead time for changes runs commit → production, a specific and precisely defined window. "Cycle time" has no single industry-agreed definition — teams use it loosely for whatever narrower slice they're tracking, which is exactly why the DORA-literate answer uses DORA's own phrase instead. |
| Platform engineering vs product engineering | A platform team's customer is internal — other engineers, served through golden paths and self-service APIs. A product engineering team's customer is external — the paying user of the software being shipped. The platform is still built and measured like a product; its market is just inside the company. |
Why this table earns its place
Multiple-choice questions rarely test whether you've heard of a term — nearly every wrong option here is a true statement attached to the wrong word. The fix is never re-reading; it's saying each pair as two short sentences, out loud, until neither one can be swapped for the other without sounding obviously wrong.
Drill it — the closed-book equivalent of a blank page
☺ Like you’re 10: The CNPE drill is "write the YAML with nothing open." This drill is "say the fact with nothing open" — same idea, no keyboard required.
There is no cluster to fall back on here, so the only honest rehearsal is retrieval without a screen. Close this page. Answer every item below out loud, from memory, before you open anything to check.
The sixty-second recall check
Recite, without looking: the six domain weights in order, and that they sum to 100. The CNPA's duration, pass mark, and resource policy — all three, exactly. The four DORA metrics, which two are "speed" and which two are "stability," and the one thing none of them measures about a person. OpenTelemetry's three established signals, plus the name and current status of the fourth. The three CNCF maturity levels in order, and two concrete things graduation actually requires. Then pick any three rows from the distinctions table above and say each one as two contrasting sentences. If any of those seven recitations made you pause and think rather than simply say, that item is not yet cold — it goes on today's flashcard stack in the flashcards deck, not tomorrow's.
Run this drill at the start of every study session, not just the last one. A fact that comes back instantly today and again in three days is consolidated; a fact you have to reconstruct is still costing you the two minutes per question you don't have to spare. The study plan's spaced mock sittings are the large-scale version of this same discipline — this page is the version you can run in the shower.
Remy: Quick — CNPA pass mark.
Gizmo: Sixty-four percent! Wait — no — that's not right, is it? 🤑
Professor Owl: That's the CNPE's number, Gizmo, and the two exams do not share a single mechanic worth borrowing from each other. CNPA is seventy-five percent, in a hundred and twenty minutes, and you get nothing — no docs, no notes, no tab.
Foxy: And if I said OpenTelemetry only has three signals?
Mira: Traces, metrics and logs are the settled three — but say it like that's the whole and final story and you're a year behind. Profiles is real, it's in alpha, and it's aiming for general availability this year. Not shipped. Not nothing either.
Timmy: And "Graduated" doesn't mean "the CNCF picked a favourite." It means the governance paperwork, the two-organisation maintainer rule, and the security review are all done. Argo and Flux are both graduated. They compete with each other.
Dot: Honestly the one that got me was DORA. I kept reading "deployment frequency" as "how fast is Dot," and it's not about me at all — it's about the pipeline.
Remy: Which is rule one of this whole page: DORA grades the system. Say it again, faster this time.
That is the whole crib sheet: exam mechanics, six weights that add to a hundred, DORA's four keys and its one trap, OpenTelemetry's real signal count, CNCF's ladder, and seven distinctions that blur under a clock. For the breadth this page deliberately leaves out, go to the CNPA concept reference. For what you're allowed to bring into the room — which, per this page, is nothing — see the CNPA docs map. For what to do when a question stem is actively trying to mislead you, see the CNPA triage page. For the calendar that turns all of this into a passing score, see the CNPA study plan, and for the domain that carries more than a third of the paper on its own, start at CNPA · Core Fundamentals.
1. Recite the six CNPA domain weights in order and confirm they sum to 100. 2. State the CNPA's duration, pass mark, and resource policy — all three, precisely. 3. Name all four DORA metrics and the one thing none of them can tell you about an individual. 4. What are OpenTelemetry's three established signals, and what is the current, precisely-hedged status of the fourth? 5. Name the three CNCF maturity levels in order, and two concrete things "Graduated" actually requires. 6. In one sentence each: golden path vs mandate, and deploy vs release.
Check your answers
- 36, 20, 16, 12, 8, 8 — Core Fundamentals, Observability/Security/Conformance, Continuous Delivery, Platform APIs & Provisioning, IDPs & DevEx, Measuring. They sum to 100.
- 120 minutes; 75% or above to pass; and fully closed-book — no tools, resources, or external sites of any kind, per the Linux Foundation's own Resources Allowed page.
- Deployment frequency, lead time for changes, change failure rate, time to restore service (recent reports: failed-deployment recovery time). None of the four measures an individual — all four are computed from delivery-system events and describe a team or system, not a person.
- Traces, metrics, and logs are established. The fourth, profiles, is real and active but currently in public alpha, targeting general availability later in 2026 — not yet a stable, shipped signal.
- Sandbox → Incubating → Graduated. Graduated requires, among other things, documented adoption by independent production users, maintainers from at least two separate organisations, and a completed third-party security review with an OpenSSF Best Practices badge — a governance and trust bar, not a claim of technical superiority.
- A golden path is the easiest route and can be left; a mandate forbids alternatives. A deploy puts new code on the cluster; a release exposes its behaviour to users — the gap between them is what makes a bad change cheap to undo.