The closest thing the CNPE has to a philosophy exam, and it is 13 pages. Read the CNCF Platforms white paper once end to end; what follows is the compression I would want the night before, plus the API-design half that domain 3 then implements five different ways.
nothing runningOrientation
This is the one reading session in the curriculum, and it belongs before the other five sections, because they all implement ideas named here. Keep it short: 45 minutes, then go build something.
Vocabulary and judgement, not commands. A scenario describes a platform that violates one of the paper's attributes and asks what is wrong; or it hands you a request and asks which capability and which interface should serve it. The words below are the answer key: using the paper's own terms is what makes an answer score.
Definitions that get tested as vocabulary
A platform is an integrated collection of capabilities, defined and presented according to the needs of its users. The key move in that sentence is users: a platform is a product with internal customers, not an infrastructure inventory.
The attribute list, worth memorising
| Attribute | Violated when… |
|---|---|
| Platform as a product | no roadmap, no users consulted, success measured in tickets closed |
| Consistent user experience | every capability has its own bespoke interface and conventions |
| Documentation and onboarding | the platform is knowable only by asking a person in Slack |
| Self-service | a human approves each request; lead time measured in days |
| Reduced cognitive load | developers must understand the implementation to use the interface |
| Optional and composable | adoption is mandated, escape hatches are forbidden |
| Secure by default | the safe path is the harder path |
Four terms to be able to define cold
- Thinnest Viable Platform (TVP): the smallest layer that provides consistency and accelerates delivery, deliberately kept small. The paper's example of a minimal platform is a wiki page of provisioning links. The instinct to carry: platform teams build interfaces and experiences, and should not rebuild capabilities that managed providers or upstream projects already offer.
- Golden path: a templated composition of well-integrated code and capabilities for rapid project development, documentation included. Paved, not mandatory. This lab implements one literally: Backstage template → new Gitea repo → ApplicationSet picks it up → running workload (section 3.6).
- Self-service: a user requests a capability and receives it automatically, with no human in the loop, through a portal, API or CLI. Every tool in domain 3 is a different way to deliver that property.
- Capability: a thing the platform offers (build automation, observability, secrets, data services), distinct from the interface through which it is offered. Scenario questions often turn on that distinction.
Capability domains the paper enumerates
Web portals; APIs and CLIs; golden path templates; build and test automation; delivery and verification automation; development environments; observability; infrastructure services; data services; messaging; identity and secrets; security services; artifact storage. A "which capability is this" question is cheap to set, so skim the list until each one has an example attached.
The paper's model runs provisional (ad hoc, individual effort) → operational (a team owns it, usage is requested) → scalable (self-service, documented, versioned) → optimizing (measured, funded as a product, continuously improved). If a scenario describes tickets and a shared spreadsheet, it is operational at best, and the named next step is self-service with documentation.
What "API as contract" means when you design one
"Designing platform APIs" cashes out in domain 3 as five decisions. Hold examples/crossplane/xrd.yaml against this list; it is the lab's concrete instance of every point.
- Abstraction level. A developer asks for an
AppEnvironmentwith a team name and a quota, not for a Namespace plus a LimitRange plus two NetworkPolicies. Choose the noun your user already has in their head. Too thin and you have added a layer without removing work; too thick and every request needs an escape hatch you did not build. - Validate at admission. Enums, ranges, patterns, CEL rules with messages a human can act on. Mistakes should fail in the terminal within a second, not in a controller log an hour later.
- Report status. Conditions, phases and useful printer columns so consumers can self-diagnose. A platform API without a meaningful READY column is user-hostile, and the support burden lands on you.
- Version deliberately.
v1alpha1means you may break it; once someone depends on it, a new served version and a conversion story are the price of changing your mind (section 3.2). - Document in the schema. Field descriptions become
kubectl explainoutput. That is the docs your users will actually read, because it is the docs that is where they are.
Write the ten-line YAML your user will type before you write the schema. If those ten lines contain a field whose value the user must look up in your implementation, the abstraction is leaking. examples/crossplane/xr.yaml is exactly this exercise, done: a team name and two quota numbers.
Measuring a platform
| Category | Measures | Where the data lives |
|---|---|---|
| User satisfaction and productivity | surveys, adoption, time to first contribution | outside the cluster: ask people |
| Organizational efficiency | latency from request to fulfillment of a capability | timestamps on your own CRs (section 4.5) |
| Product delivery (DORA) | deployment frequency, lead time for changes, time to restore, change failure rate | the CD tool's metrics (section 4.5) |
Section 4.5 turns the bottom two rows into PromQL against Argo CD's metrics, which is the most exam-shaped thing you can do with this paper.
Anti-patterns worth naming
- The platform as a gate. Self-service in the docs, a ticket queue in practice.
- The leaky abstraction. The interface exposes the implementation, so every provider change breaks users.
- The mandated platform. Adoption enforced rather than earned; teams route around it and you learn nothing about why.
- The rebuilt wheel. A homegrown Postgres operator, a bespoke CI engine, a custom secrets store: effort spent below the line where your users care, at the cost of the interface work only you can do.
Exercises
Take the lab's tool list from make help and assign every layer to one or more of the paper's capability domains. Then mark which interfaces each capability is exposed through (portal, API, CLI) in this lab. Where the lab has no coverage (dev environments, messaging), say so; knowing the map has empty squares is part of knowing the map.
Write, exam style: why should a platform team not build its own Postgres operator?
Invent one platform API your own organisation would use: a cache, a queue, a scheduled job, an internal endpoint. Write the ten-line manifest a developer would type. Then list, underneath, every real Kubernetes object it must expand into, and every field you deliberately did not expose.
Self-check
Define a platform in the paper's own terms.
An integrated collection of capabilities, defined and presented according to the needs of its users. The emphasis on users and on presentation (interfaces) is what distinguishes a platform from a pile of infrastructure.
What is the Thinnest Viable Platform, and what does it imply about build-vs-adopt?
The smallest layer that provides consistency and accelerates delivery. It implies adopting existing capabilities wherever they exist and spending your effort on interfaces, integration and golden paths: the parts nobody can buy for your organisation.
A team can request a namespace through a form, and someone approves it within a day. Is that self-service?
No. The paper's definition requires fulfillment without a human in the loop. A form plus an approver is an interface over a ticket queue: operational maturity, not scalable. The fix is automated fulfillment with policy encoded in the API, and approval only where regulation demands it.
Name the DORA four and one platform-specific measure the paper adds.
Deployment frequency, lead time for changes, time to restore service, change failure rate. The paper adds measures like latency from request to fulfillment of a capability, time to first contribution, and adoption, all platform-specific because they measure the platform, not the applications on it.
Which platform attribute does a mandatory, non-composable platform violate, and why does it matter practically?
"Optional and composable". Practically: mandated platforms hide their own failures, because teams route around them quietly instead of filing the feedback that would improve them. Optionality is a feedback mechanism, not generosity.
Docs to know your way around
- tag-app-delivery.cncf.io/whitepapers/platforms/: the paper itself, plus its glossary (platform engineer vs platform product manager definitions have appeared in practice questions).
- dora.dev: the four keys, one page.
- Team Topologies: where "platform team" and "cognitive load" as terms of art come from; the paper leans on both.