Measuring your Platform

Every other CNPA domain teaches you to build something. This one — the last 8% — asks the colder question: how do you know it worked? A platform consumes real headcount and real cloud spend, and the only defensible answer is a number that existed before you started and moved afterwards. The curriculum names two competencies: Platform Efficiency and Team Productivity, and DORA Metrics for Platform Initiatives. Because CNPA is knowledge-based and multiple-choice, what you owe it is not a dashboard but crisp statements — what each metric means, what it cannot see, and which of two tempting options is the vanity one.

Why measurement is a domain of its own

☺ Like you’re 10: If you can’t say what got better, you can’t say the thing you built was worth building.

A platform is unusual: it produces almost nothing a customer ever sees. Its output is other teams’ output, arriving faster and more safely. That indirection is why platform teams get defunded — at budget review the product teams point at features and revenue, and the platform team points at… clusters. The CNCF Platform Engineering Maturity Model makes measurement a core aspect for exactly this reason: a team that cannot say whether it is helping will eventually be flown into a wall by someone holding a spreadsheet.

It is also the smallest slice of the blueprint. The six CNPA domains — Platform Engineering Core Fundamentals 36%, Platform Observability, Security, and Conformance 20%, Continuous Delivery & Platform Engineering 16%, Platform APIs and Provisioning Infrastructure 12%, IDPs and Developer Experience 8%, and Measuring your Platform 8% — sum to 100%, and this one spends its 8% on just two competencies. That is the best points-per-page ratio on the paper. Skipping it because it has no manifests to memorise is a common and expensive mistake.

Output, outcome and vanity

The most testable idea here is the difference between three kinds of number. An output metric counts what the platform team did. An outcome metric counts what changed for the platform’s users. A vanity metric is an output metric wearing a suit — a number that reliably rises, looks good on a slide, and would keep rising even if the platform were useless.

Leading and lagging indicators

The second distinction is when a number moves. A lagging indicator confirms an outcome after the fact — change failure rate last quarter, incident count, retention. A leading indicator predicts it early — adoption trend, onboarding time, survey sentiment, ticket-queue size. You steer by leading indicators because they buy time to react, and prove impact with lagging ones because those are what funding rests on. A programme with only lagging metrics tells you the platform failed, long after you could have fixed it.

Platform Efficiency and Team Productivity

☺ Like you’re 10: “Efficiency” means two things here — cheaper machines and less wasted human time. Platforms are supposed to fix both.

This competency joins two ideas most organisations measure with different tools and different teams. Efficiency usually means resource efficiency: are we paying for compute we do not use? Productivity means human efficiency: are engineers spending the day on work only they can do? A platform is one of the few investments that plausibly moves both — and the exam point is that you must not sacrifice one to flatter the other.

Cognitive load — what a platform actually removes

The clearest theory of why platforms improve productivity comes from Team Topologies: a team has a finite budget of cognitive load, and everything it must hold in its head competes for it. Load splits three ways — intrinsic (the inherent difficulty of the domain), extraneous (accidental complexity of the environment: which flag configures the ingress controller, how to get a certificate, why CI is out of disk) and germane (learning the business problem). A platform exists to shrink the extraneous slice so the other two can grow. Shorter onboarding, fewer tickets and higher adoption are all downstream of that.

Toil, and the ticket queue as an instrument

Google’s SRE literature supplies the other half of the vocabulary. Toil is operational work that is manual, repetitive, automatable, tactical, devoid of enduring value — and, the defining property, grows linearly with the size of the service. Work done once and reused is engineering, not toil; the SRE guidance is to cap toil at roughly half a team’s time so there is always capacity to automate it away.

For a platform team the ticket queue is the cheapest toil instrument you own, and it is already instrumented. Count requests by category: “create a namespace,” “give me a database,” “add me to this repo.” Each recurring category is a self-service capability you have not built yet, and its count is the business case. When the category vanishes after you ship the capability, that disappearance is the measurement.

Adoption — the headline number

If you get exactly one platform metric, take adoption: the share of teams, or of production services, actually using the paved road. It is superb because it is voluntary — nobody adopts a platform slower than what they had. A rising curve is developers voting with their repositories; a flat one is the product telling you something true. Good variants: services registered in the catalog with a real owner, new services created from a template, deployments flowing through the supported delivery path. The distractor to spot: adoption that has been mandated measures nothing — if your platform is the only route to production, 100% adoption is a tautology, and you have a golden cage rather than a golden path (Anti-Patterns).

Resource efficiency: utilisation, waste and unit cost

☺ Like you’re 10: You pay for the seat you booked on the bus, not the seat you sat in. Most cloud waste is empty booked seats.

The resource half of efficiency has a signature failure CNPA can test directly: the cloud bill cannot tell you who spent the money. An invoice reports instance-hours, but one Kubernetes node runs pods from six teams. Turning node-hours into per-team numbers is cost allocation, and the CNCF project for it is OpenCost, which joins per-pod resource metrics (usually scraped via Prometheus) to real billing rates and re-aggregates by namespace, label, team or business unit.

The requests-versus-usage gap

Kubernetes schedules on requests, not usage. A pod requesting 2 CPUs and using 0.2 has reserved capacity nobody else may schedule into, so you pay for all 2. That gap is the largest single source of Kubernetes waste, and why “efficiency” on a cluster dashboard usually means usage ÷ requests. Node cost splits three ways, and the three words are worth a mark: allocated cost is attributable to a specific pod; idle cost is capacity neither requested nor used; shared or overhead cost is cluster-wide infrastructure (control plane, DaemonSets, ingress) that no tenant owns and must be redistributed by an agreed rule. Closing the gap is right-sizing plus consolidation — see FinOps and Scaling & Scheduling.

# Cost allocation with the kubectl-cost plugin (reads OpenCost / Kubecost).
# "efficiency" here is usage ÷ requests — the gap you are trying to close.
kubectl cost namespace --window 7d --show-efficiency

# NAMESPACE     CPU      MEMORY   TOTAL     EFFICIENCY
# checkout      $84.10   $31.55   $115.65   0.21     <-- requests ~5x usage
# search        $61.40   $44.90   $106.30   0.68
# __idle__      $73.20   $28.40   $101.60   --       <-- unbooked node capacity

# The same idea straight from Prometheus, no cost tool required:
#   sum(rate(container_cpu_usage_seconds_total{container!=""}[7d]))
#     / sum(kube_pod_container_resource_requests{resource="cpu"})

Showback, chargeback and unit economics

Once cost is allocated there are two ways to report it. Showback tells each team what they spend without moving money; chargeback bills it to their budget. Start with showback: it changes behaviour with little political friction and lets you find allocation gaps — unlabelled resources, disputed shared costs — before anyone’s budget depends on the arithmetic. Neither is the headline number, though. That is unit cost: spend divided by something the business recognises — per customer, per thousand requests, per order. Total spend is a vanity metric; unit economics distinguishes healthy growth from runaway inefficiency, and makes measurement legible outside engineering.

Team productivity without weaponising the numbers

☺ Like you’re 10: One number can always be cheated. Several numbers, including “how does it feel?”, are much harder to cheat.

Productivity measurement has a bad history in software, and the frameworks that survived are the ones that refused to produce a single score.

SPACE — productivity is multi-dimensional

The SPACE framework exists to kill the “one metric to rule them all” instinct. Its five dimensions are Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. Its instruction is not “measure all five” but “pick metrics from several dimensions, including at least one perceptual one” — any dimension measured alone gets optimised at the others’ expense. Activity counts (commits, deploys, tickets closed) are the ones SPACE warns are most often mistaken for productivity.

DevEx — feedback loops, cognitive load, flow state

The DevEx framework narrows to the daily experience of the work and names three dimensions that map suspiciously well onto everything a platform does: feedback loops (how long until you learn whether a change is good), cognitive load (how much you must understand to make one) and flow state (how often you get uninterrupted stretches to think). Every golden path, preview environment and self-service API is an intervention on one of the three. The longer treatment, including the DX Core 4 scorecard unifying DORA, SPACE and DevEx, is on Developer Experience.

Surveys are data — and Goodhart is watching

Trusting only system telemetry is a trap the exam can test. Much developer friction never touches an instrumented system: a flaky local setup, a two-day wait for an environment, docs that lie, an approval in someone’s inbox. A consistent, anonymous developer survey is a legitimate and often leading instrument, because people feel friction long before delivery numbers move — so pair every system metric with a perceptual one, and be suspicious when they disagree. And remember Goodhart’s law: when a measure becomes a target it stops being a good measure. Demand higher deployment frequency and you get emptier deploys; demand a lower change failure rate and incidents quietly stop being recorded as change failures. The defences: measure teams not individuals, pair speed with stability, triangulate hard numbers with soft ones, and never attach a metric to compensation.

DORA Metrics for Platform Initiatives

☺ Like you’re 10: Four numbers in two pairs. Two say “how fast do you ship?” and two say “how often do you break it, and how fast do you fix it?”

DORA — DevOps Research and Assessment — is a long-running research programme popularised by Accelerate (Forsgren, Humble and Kim) and now published by Google Cloud as the annual State of DevOps report. Its lasting contribution is the four keys: delivery metrics that come in two pairs pulling in opposite directions, so nobody can look good by sacrificing one for the other.

The four keys, defined precisely

Two naming notes. Recent DORA reports refine the fourth key to failed-deployment recovery time, making clear it concerns recovery from a bad change rather than any incident; older material and much tooling still says time to restore service or loosely MTTR. Recognise all three as the same key. Later DORA research also explores a fifth measure usually labelled reliability — in practice an SLO-attainment view — which sits alongside the four rather than replacing any.

Why the pairing is the whole point

Read alone, each key is trivially gameable: deploy forty empty commits a day and frequency is elite; never deploy and change failure rate is zero. The four only work together, as two speed metrics constrained by two stability metrics. The central DORA finding is that these are not a trade-off in practice — the highest performers are fast and stable, because the same practices (small batches, automation, continuous delivery, fast feedback) improve both. That is why GitOps and progressive delivery are taught as reliability practices rather than speed hacks.

Performance cohorts

DORA’s reports cluster respondents into performance groups — commonly low, medium, high and, in most years, elite — with published ranges per key. The boundaries move year to year, so memorise the shape, not the numbers. Cohorts let a team locate itself and see the next band; the most valuable comparison is always against your own past, not a benchmark from a different industry with different regulatory constraints.

Instrumenting and using the four keys

☺ Like you’re 10: The numbers aren’t magic — they’re a tidy list of “this happened at this time,” counted up afterwards.

All four keys reduce to timestamped events, which is good news for a platform team: the platform is where those events already pass. If every production change flows through one delivery path, that path can emit a record of every deploy — and if it does not, no dashboard work will rescue the numbers.

The event record that produces all four

Capture one structured record per production deployment and every key falls out by arithmetic: frequency is a count, lead time is deploy minus commit, change failure rate is the failed fraction, recovery is restored minus detected. (The record below is shown as JSONC — the // notes are annotations for you, not part of the payload, because strict JSON has no comments.)

{
  "event": "deployment.finished",
  "service": "checkout",
  "team": "payments",
  "environment": "production",
  "on_golden_path": true,                       // lets you compare cohorts later
  "revision": "9f2c1ab",
  "first_commit_at": "2026-03-04T09:12:41Z",    // → lead time for changes
  "deployed_at":     "2026-03-04T11:47:02Z",
  "outcome": "failed",                          // → change failure rate
  "failure_detected_at": "2026-03-04T11:53:10Z",
  "restored_at":         "2026-03-04T12:06:35Z" // → recovery time
}

Two design notes carry exam weight. The event must be emitted by the delivery system, never typed in by humans — a hand-kept deployment spreadsheet rots exactly like a hand-kept service catalog; Argo CD and Flux emit sync events, CI systems emit pipeline events, and OpenTelemetry is a reasonable transport. And outcome needs an agreed, written definition of “failure” — a rollback, a hotfix inside some window, or a linked incident — because an undefined change failure rate is not a metric, it is a mood.

Deriving the numbers

With deploy events in Prometheus as counters, the keys become ordinary queries and Grafana renders them beside the reliability dashboards the platform already runs — turning delivery performance from a management report into operational telemetry.

# Deployment frequency — successful production deploys per day, by team
sum by (team) (
  increase(platform_deployments_total{environment="production",outcome="success"}[1d])
)

# Change failure rate — failed share of production deploys, 30-day window
sum(increase(platform_deployments_total{environment="production",outcome="failed"}[30d]))
  /
sum(increase(platform_deployments_total{environment="production"}[30d]))

You will not write PromQL on CNPA. It is a knowledge-based, multiple-choice exam — typing queries against a live cluster is what the performance-based, hands-on exams (CKA, CKAD, CKS and the CNPE) ask for instead; here the query language is vocabulary belonging to the observability domain. Carry away the architecture: events from the delivery path, aggregated as metrics, sliced by team and cohort. Ready-made implementations exist — Google’s open-source Four Keys project, Backstage plugins, DORA dashboards in CD tooling — and the point is that the keys are computed from delivery events, not measured by a special agent.

Baseline, cohort and trend

The competency is “DORA metrics for platform initiatives,” and that phrase does real work: the four keys are evidence about a specific investment — the new golden path, the self-service database — not a generic scoreboard. Three moves make the evidence honest. Baseline: record the keys per team, with dates, before the initiative ships. Segment: compute them separately for onboarded teams and teams not yet onboarded, so the second group acts as a control. Trend: read direction over months, since one bad quarter wrecks any stability metric in isolation.

What DORA cannot see

Expect a scenario where the four keys look excellent and something is still badly wrong. DORA measures the outer loop — commit to production — so it is silent on the inner loop: a fifteen-minute local build, a laptop that cannot run the stack, an hour lost each morning to environment setup. It is silent on cost (you can be elite and bankrupt), on security posture, on toil absorbed by a heroic on-call rotation, and on how any of it feels — the gap SPACE and DevEx surveys fill. Attribution is the last honesty check: teams reorganise, products change, people leave, so speak of the platform’s contribution rather than proof.

Maturity, and what you must state on exam day

☺ Like you’re 10: Grown-up platforms don’t just collect numbers — they change their plans because of them.

The CNCF Platform Engineering Maturity Model puts measurement on a trajectory from nothing, to anecdote, to consistent quantitative data, to measurement that drives the roadmap. Its other aspects — investment, adoption, interfaces and operations — are covered in Platform as a Product and Best Practices.

Measurement as a maturity dimension

For CNPA it is enough that measurement is a first-class maturity dimension and that the top level is defined by decisions changing in response to data — not by the size of the dashboard.

The statements to know cold

Name the two competencies in the curriculum’s words. Distinguish output, outcome and vanity metrics. Explain leading versus lagging and say which you steer by. Define cognitive load, its three kinds, and which one a platform reduces. Define toil, including that it scales linearly with the service. Say why adoption is the headline metric and why a mandate destroys it. Explain the requests-versus-usage gap; name allocated, idle and shared cost; contrast showback with chargeback; say why unit cost beats total spend. Name the four DORA keys, label each speed or stability, explain what the pairing prevents, and know the fourth is also called failed-deployment recovery time. Say where the data comes from — timestamped events from the delivery path. List what DORA cannot see. Finally: baseline first, compare cohorts, read the trend, never measure individuals.

This page deliberately publishes no exam logistics. Duration, question count, pass mark, price, retake and free-retake policy, certification validity and any prerequisites are set by the Linux Foundation, are revised without notice, and should be read from the official CNPA page rather than from any study site — including this one: training.linuxfoundation.org. What is safe to state is the kind of exam it is: CNPA is an associate-level, knowledge-based, multiple-choice, online-proctored exam — you answer questions, you do not operate a cluster. That is the opposite of the performance-based, hands-on exams (CKA, CKAD, CKS and the CNPE), and confusing the two is the most common planning error; the map is on Certifications, and the six-domain hub is CNPA. Primary sources for this page: dora.dev, the CNCF Platform Engineering Maturity Model and the OpenCost specification. Deeper here: FinOps, Developer Experience, Observability & Operations, Reliability & Incidents and OpenCost; every term above is defined in the Glossary.