Platform Engineering
The discipline of building the internal platform other teams ship on. Golden paths and self-service, control planes and guardrails, platform APIs and the metrics that prove it worked — remembered with spaced repetition.
- flashcards
- 104
- flashcards
- per day
- ~10 min
- per day
- level
- Intermediate
- level
- modules
- 6
- modules
What is platform engineering?
Platform engineering is the practice of building an internal platform as a product: a set of capabilities — ship a change, provision a database, get an alert — that product teams consume by themselves, instead of filing tickets and waiting. The framing borrowed from Team Topologies is the useful one: a platform team exists to reduce the cognitive load its customers carry, and its customers are other engineers who can walk away if the thing is not good.
That product framing has teeth. A golden path is a supported, opinionated route through the toolchain that teams may leave — taking the maintenance, on-call and compliance work with them — which makes adoption honest feedback rather than a mandate. Governance follows the same logic: guardrails rather than gates, with policy engines, workload identity and signed artifacts making the safe path the default one instead of adding a review board in front of every release.
Underneath sit the mechanics this track goes into: control planes and the reconciliation loop that makes declared state converge, multi-tenancy and environment isolation, GitOps delivery with the pull model, CRDs and Crossplane compositions as the platform’s own API surface, and developer portals such as Backstage with its software catalog and scaffolder. It closes on measurement — the current DORA metrics, adoption signals and developer-experience research — because a platform nobody uses is a cost centre with good intentions.
Studying for the certification? The modules follow the six Cloud Native Platform Engineering Associate domains and their weighting, so platform fundamentals is the largest module, exactly as it is on the paper.
6 modules, seed to bloom
Each module is a set of flashcards — 104 in total. Answer, review, and watch your knowledge grow from seed to full bloom.
Platform Engineering Foundations
Goals, team topologies, golden paths and declarative resource management
18 cardsPlatform Architecture & Environments
Control planes, application environments, multi-tenancy and abstraction boundaries
17 cardsPlatform Observability, Security & Conformance
Tenant telemetry, workload identity, policy guardrails and supply-chain controls
20 cardsContinuous Delivery & GitOps for Platforms
Shared pipelines, the pull model, promotion, rollback and platform incident response
16 cardsPlatform APIs & Provisioning Infrastructure
Reconciliation, CRDs as platform APIs, the operator pattern and Crossplane compositions
15 cardsIDPs, Developer Experience & Measuring the Platform
Developer portals, the Backstage catalog, DORA metrics and adoption signals
18 cardsSample questions
A taste of the real flashcards. Pick an answer, then reveal the explanation.
What is a golden path, and what distinguishes it from a mandated standard?
- AA supported, opinionated route through the toolchain — teams may leave it, but lose the support that comes with it
- BA required route through the toolchain — teams are blocked at admission if they deploy anything outside it
- CA reference architecture document — teams copy it manually and the platform verifies compliance quarterly
- DA migration plan with deadlines — teams are moved onto it in waves until every service has been converted
What is the relationship between an internal developer platform and a developer portal?
- AThe portal is one interface onto the platform — the platform is the capabilities behind it, also reachable by API and CLI
- BThe portal is the platform's control plane — the capabilities are implemented as plugins inside the portal itself
- CThe portal replaces the platform for small teams — a catalogue alone is sufficient until scale demands more
- DThe portal is the platform's billing layer — capabilities are metered through it and charged back to each team
How does Crossplane's model differ from a Terraform pipeline for provisioning cloud infrastructure?
- ADesired state lives in the cluster's API and is reconciled continuously — Terraform diffs configuration against stored state at run time
- BDesired state lives in a state file that must be locked — Terraform instead keeps its desired state inside the cluster
- CDesired state is written in HCL and converted to objects — Terraform instead uses YAML manifests for its resources
- DDesired state covers Kubernetes objects only — Terraform is the sole option for provisioning cloud resources
What is the denominator of DORA's change fail rate?
- AAll deployments in the period — the numerator is those that needed immediate remediation such as a rollback or hotfix
- BAll production incidents in the period — the numerator is those that a deployment turned out to have caused
- CAll commits merged in the period — the numerator is those that had to be reverted from the main branch
- DAll change requests raised in the period — the numerator is those that a review board decided to reject
Learn it once, keep it for good
Answer a question
Each card is one practical concept with multiple options. Pick what you think is right.
Get the full answer
See the correct option plus a clear explanation, and a link to deeper docs when one is available.
Review at the right time
A spaced-repetition engine (SM-2 or FSRS) resurfaces each card just before you would forget it.
Why platform engineering is worth your time
The role most infra jobs are becoming
Most organisations now run an internal platform, and the work has a name, a body of practice and its own interview questions.
Judgement, not just tooling
Knowing when not to build a capability, and what belongs outside the platform, is what separates a platform from a pile of shared tools.
The vocabulary that makes reviews shorter
Golden paths, guardrails, cognitive load and platform-as-a-product turn recurring arguments into decisions your team can name.
Measurement you can defend
DORA metrics, adoption signals and developer-experience data show whether the platform helped — and where it quietly did not.
Common questions
How is this different from the DevOps and GitOps tracks? +
Those tracks teach the tools — pipelines, Argo CD, Terraform. This one is about productising them for other teams: what to abstract, what to leave exposed, how to govern without gating, and how to tell whether anyone benefited. It reuses concepts from those decks but always from the platform team’s side of the boundary.
Do I need Kubernetes experience first? +
Some helps. The track assumes you know what a Pod and a Deployment are, then builds on that with control planes, CRDs, admission policy and multi-tenancy. If Kubernetes is new, start with the Kubernetes track and come back.
Will this prepare me for the CNPA exam? +
It follows the six published Cloud Native Platform Engineering Associate domains and their weighting, so platform fundamentals is the biggest module and the IDP and measurement domains are the smallest, as on the paper. It is a recall companion rather than a course — pair it with the official curriculum. Verify the current domains and price on the Linux Foundation page before you book.
Does it cover Backstage? +
At concept level: the software catalog and its entity kinds, catalog-info.yaml, software templates and TechDocs, and what Backstage deliberately does not give you. The Certified Backstage Associate exam goes much deeper into TypeScript, React and plugin development than this track does.
Is it free? +
Yes, completely free. No registration or credit card is required, and all your progress is stored locally in your browser.
Ready to build the platform?
Plant your first seed today. Ten minutes a day on golden paths, platform APIs and the metrics behind them beats another argument about which tool to standardise on.