Practice · IDPs, DevEx & Measuring

Twelve single-best-answer questions across the two smallest domains on the CNPA blueprint — IDPs and Developer Experience at 8% and Measuring your Platform at 8% — six questions each, every one chipped with the domain it belongs to. Together they are sixteen percent of the paper, roughly one mark in six, and they are the marks candidates most often leave on the table because both domains sound soft. They are not. Portal versus platform, paved road versus mandate, inner loop versus outer loop, lead time versus cycle time, adoption versus vanity — these are crisp, testable distinctions, and this bank is built almost entirely out of them. Answer cold, read the explanation whether you were right or wrong, and finish able to say why each of the other three options was written.

Sixteen percent, and the cheapest on the blueprint

☺ Like you’re 10: These two little topics are worth about one question in six, and they take an evening each to learn properly. That is the best deal on the whole test.

The six official domains are weighted 36 / 20 / 16 / 12 / 8 / 8, and this bank covers the two eights. Nobody passes the CNPA on the strength of them — Core Fundamentals at 36% decides that — but plenty of people fail by a couple of marks, and these are the two domains where a couple of marks are recoverable in a single sitting. Between them they hold six competencies: Simplified Access to Platform Capabilities, API-Driven Service Catalogs, Developer Portals for Platform Adoption and AI/ML in Platform Automation on the DevEx side; Platform Efficiency and Team Productivity and DORA Metrics for Platform Initiatives on the measuring side. That is a small, closed, entirely learnable surface.

Why candidates drop marks here

Three reasons, and all three are habits rather than knowledge gaps. First, familiarity: everyone has used a portal and everyone has heard of DORA, so the material reads as revision rather than study, and nothing sticks. Second, vocabulary drift — teams use “lead time”, “cycle time”, “MTTR” and “platform” loosely in daily speech, and the exam uses them precisely. Third, the softness illusion: because these domains talk about people and adoption, candidates expect woolly questions and are surprised by scenarios that turn on one word in the lead-in.

What the examiners are really testing here

☺ Like you’re 10: Not “what does this word mean?” but “here’s a story — which idea is it about, and what should you do?”

Associate-level multiple-choice items are written to separate people who half-know a topic from people who know it. The technique for doing that is almost always the same: take two neighbouring ideas that get used interchangeably in conversation, build a scenario that only one of them explains, and make the other one an option. If you can name the neighbouring pairs in advance, you can see the machinery through the wording.

The pairs this bank turns on

The four traps in this pair of domains

Every distractor in the bank below is drawn from one of four families, and naming the family is often faster than reasoning to the answer.

• True but not asked. A statement that is entirely correct and answers a different lead-in — control-plane uptime is a real metric, it is simply not evidence of adoption.
• The adjacent definition. The Lean sense of “lead time” (customer request → delivery) offered where DORA’s lead time for changes was asked for. Both real; only one is the key.
• The procedural fix. An option that adds process — an audit, a review cadence, a mandate, an approval — to a problem whose cause is structural. It sounds responsible and changes nothing.
• The rigorous-sounding patch. A statistical or governance tweak that leaves the actual defect intact: excluding small samples from a ranking that should never have existed.

The two loops — the picture behind half these questions

☺ Like you’re 10: There is a little fast circle you spin on your own laptop, and a bigger slow one that goes out to real users. The famous four numbers only watch the big one.

If you hold one diagram in your head for these two domains, hold this one. The inner loop is everything a developer repeats before the work is shared: edit, build, run the tests, click the thing, edit again. Dozens of iterations a day, measured in seconds and minutes, and the single largest determinant of whether the job feels good. The outer loop starts at the commit and ends with the change serving traffic: CI, review, merge, deploy, verify. All four DORA keys are measured on the outer loop.

Lead time, cycle time, and the words teams actually use

DORA defines lead time for changes as the time from code being committed to that code running successfully in production. Note where it starts: at the commit, which means review latency and CI queueing are inside the number. Many teams instead quote the merge-to-production slice and call it their lead time or their cycle time — a reasonable pipeline metric, but a much smaller window, and one that conveniently excludes the two days a pull request spent waiting for a second reviewer. There is no single agreed definition of “cycle time” across the industry, which is precisely why the curriculum uses DORA’s own phrase and why an exam question can safely turn on it.

How to work this bank

☺ Like you’re 10: Answer all twelve without looking anything up. Then read every explanation, even the ones you got right.

A bank is not a mock. The CNPA mock exam exists to measure you across all six weighted domains in one sitting; a bank exists to build one area, so the rules are different — you may take as long as you like on a question, and the explanation is the point rather than the score. What you must not do is look anything up mid-question, because then you are practising search rather than recall, and the real sitting is closed-book.

The protocol

1. Twelve questions, one pass, nothing open. No notes, no other tabs. Around two minutes a question is a sensible pace, which is the rhythm the real CNPA’s 120-minute allowance rewards, though nothing here is timed.
2. Commit to an answer every time, including the ones where you are down to a coin flip between two options. A guess you had to make is a diagnostic; a question you skipped is nothing.
3. Before you click, name the loser. Say which option is your second choice and why it is worse. If you cannot, you are recognising rather than reasoning.
4. Read every explanation. Each one says why the key is right and why the most tempting wrong option is wrong — which is the sentence that actually transfers to the exam.
5. Use the chips to re-sit one domain a couple of days later, not ten minutes later. Spaced retrieval is what makes it stick; immediate retakes measure short-term memory.

What the chips, the bar and reset do

The domain chips filter the bank to one of the two domains — useful for the second sitting, pointless for the first. The counter and bar track how far through you are and how many you have right. Shuffle / reset reshuffles both the question order and the four options within every question and starts a clean attempt, which is deliberate: remembering that “it was the third one” is not knowledge, and the real paper will not present these in this order or this wording anyway. Your answers are remembered in this browser only, so you can leave and come back — and reset clears them everywhere.

The bank — twelve questions

☺ Like you’re 10: Click an option. It turns green or red straight away and tells you why.

Six questions carry the 🦆 IDP & DevEx chip and six carry the 🐿️ Measuring chip, matching the two domains’ equal 8% weights. Click an option to lock it in: the correct answer is marked, your mistake is marked, and the explanation appears underneath.

Marking yourself: what each kind of miss means

☺ Like you’re 10: Your score isn’t the useful bit. Why you got each one wrong is the useful bit.

Twelve questions is too small a sample to be a verdict — one unlucky guess is eight percentage points. What it is large enough to do is sort your misses into kinds, and the kind tells you what to do next far better than the total does.

Then do the one thing almost nobody does. For every question you got wrong, write a single sentence saying why the option you chose was wrong — not why the right one was right. Defending the key is easy and teaches you very little; dismantling your own answer is what stops the same mistake recurring under pressure in three weeks’ time.

The distinctions these twelve questions turn on

☺ Like you’re 10: Here are the exact things the twelve questions were built out of. If you can say each one in a sentence, you have this pair of domains.

Two concrete artefacts anchor most of the abstractions above, and both are worth recognising on sight rather than writing from memory.

What “API-driven” looks like on disk

A service catalog is API-driven when its entries are ingested from files that live beside the code they describe, rather than typed into a UI once and left to rot. In Backstage that file is catalog-info.yaml at the root of the repository, and it changes in the same pull request as the code it documents:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: checkout
  description: Cart and checkout API
  annotations:
    github.com/project-slug: acme/checkout
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: group:payments          # ownership points at a Group or a User
  system: commerce
  dependsOn:
    - resource:default/checkout-db

Everything the catalog knows about checkout — its owner, its docs, its dependencies — is now reviewed, versioned and deleted with the service itself. That is the whole difference between an inventory and a rumour.

Where the four keys actually come from

All four DORA metrics reduce to timestamped events emitted by the delivery path, which is why a platform team is the natural place to instrument them: every production change already passes through one pipeline. Append one record per deployment and the numbers are arithmetic afterwards:

{"service":"checkout","env":"production","deployed_at":"2026-04-08T09:14:22Z",
 "commit_sha":"9f31c2e","committed_at":"2026-04-08T07:41:05Z",
 "lead_time_seconds":5597,"outcome":"success","restored_at":null}

# deployment frequency: production deploys per day over the file
jq -r 'select(.env=="production") | .deployed_at[0:10]' deploys.ndjson \
  | sort | uniq -c

# median lead time for changes, in minutes
jq -s '[.[] | select(.env=="production") | .lead_time_seconds] | sort
       | .[length/2 | floor] / 60' deploys.ndjson

# change failure rate as a percentage
jq -s '[.[] | select(.env=="production")] as $d
       | ([$d[] | select(.outcome=="failure")] | length) / ($d | length) * 100' deploys.ndjson

Note the median in the second command. Delivery and recovery times are long-tailed, so a mean is flattered by the bulk of quick changes and hides the two-day outliers — the same reason a quarterly MTTR reported as a mean deserves the suspicion one of the questions above asks of it.

The sentences to be able to say

• An IDP is the whole self-service system — capabilities, APIs, automation, guardrails and the team behind them. A portal is one interface onto it. The platform contains the portal, not the other way round.
• A golden path is chosen, not enforced; the escape hatch is what keeps it from becoming a golden cage and spawning a shadow platform nobody secures.
• Simplified access exposes what genuinely differs between teams and absorbs what should be identical everywhere. Every extra field on the form is a decision handed back to a developer who will guess.
• The inner loop is pre-commit and invisible to delivery metrics; the outer loop is commit to production and is where DORA measures.
• The four keys are deployment frequency and lead time for changes (speed) paired with change failure rate and time to restore service — recent reports say failed-deployment recovery time — (stability). The pairing is what stops either being gamed at the other’s expense.
• Adoption is the headline platform metric, because a platform nobody chooses is a failed product however well built. Measure it against a baseline recorded before the initiative.
• Vanity metrics have the platform team as their subject; outcome metrics have the developer or the business as theirs.
• DORA is defined for a team or delivery system, never an individual, and it cannot see the inner loop, cost, security posture, toil or how the work feels.

If you missed these, read this

☺ Like you’re 10: Every question here comes from one of a handful of pages. Go back to the page, not to a search engine.

Nothing in this bank is examined that is not taught on this site. Map your misses to the row that covers them and read that page end to end before re-sitting the chip.

Any term in an explanation you had to guess at belongs in the glossary; the handful of statements you should be able to produce without thinking are collected on know it cold. For pure vocabulary drilling, the flashcards; for a mixed, CNPE-flavoured warm-up, the self-check quiz. The AI/ML competency sits in this domain too and is not exercised by this bank — it has its own treatment on the domain page and a deep dive in Platforms for AI/ML, and it is worth ten minutes before the exam because it is new enough that many candidates skip it entirely.

Where this bank sits in the plan

☺ Like you’re 10: Do the banks while you’re learning. Save the full practice test for when you think you’re ready.

The CNPA study plan puts these two domains late — they are small, and they make far more sense once you already hold the core vocabulary of platforms and delivery. The sequence that works is: read the domain page, sit this bank cold, bucket every miss, reread only what the buckets point at, then re-sit by chip forty-eight hours later. Anything missed twice is a real content gap rather than a slip.

Only after that does the CNPA mock exam earn its place. It is the one instrument that reproduces the shape of the real paper — all six domains, weighted, in one uninterrupted sitting — and it is only informative while it is still unfamiliar, so do not burn it early. The other banks and the technique behind all of them live on the practice questions hub; the six-domain map, with the deeper CNPE lesson behind each one, is on the CNPA hub; sitting-day mechanics are in the exam guide and the exam-prep checklist.