Tools used in Platform Engineering · The Landscape

The Tool Landscape

The CNPE is deliberately tool-agnostic — it tests whether you can build a platform capability, not whether you can recite one vendor’s flags. But a known set of CNCF projects shows up again and again, and the official curriculum names fifteen of them by example. This page is Benny’s map of that landscape: a master table of the official fifteen, a picker that flips from a platform job to the tools that do it, the ecosystem projects you’ll still meet beyond the list, and a survival tactic for meeting a tool you’ve never seen — at the exam, where the project’s own docs are not available.

⚖ CNPA vs CNPE — This catalogue is the right map for CNPA prep too, not just CNPE. Both exams draw on the same tools and the same job groups below; the difference is entirely in how each one tests you. CNPE has you actually drive a tool on a live cluster, so the deep-dive pages — commands, YAML, gotchas — matter. CNPA is closed-book multiple-choice with no lab at all, so what carries over is the conceptual layer on this page: what job each tool does, which ★ tools the curricula name, and how the groups relate — recognition and recall, not hands-on fluency.

Every tool, in detail

☺ Like you’re 10: This page is the map of the whole toolbox. Each tool below also has its own full page — what it’s for, how it works, the exact YAML you write, the commands, and what usually goes wrong.

Below is the landscape view: why the exam is mostly tool-agnostic, the official fifteen, and a job-by-job picker. But each tool also has a dedicated deep-dive page — architecture, the resources you actually write, day-to-day commands, gotchas, and how it compares to its rivals. All 31 of them are listed twice on this page: first grouped by the job they do, which is how you should learn them, and then A–Z, which is how the sidebar lists them.

GitOps & delivery

Configuration & packaging

Platform APIs & self-service

Observability & cost

Security & policy

Networking & mesh

Scaling & resilience

A–Z · every tool, with its sidebar number

The same 31 tools in the order the sidebar lists them. Use this when you already know the name and just want the page — or when you have landed on a tool page from the sidebar and want to know, in one glance, whether it is on the curriculum (★) or wider ecosystem (◆) and which job group it belongs to above.

Count the stars in that table and you get 16 pages carrying 17 star marks across 15 curriculum entries — the Argo trio collapses to one entry, and OPA and Gatekeeper are two entries on one page. The remaining 15 pages are ◆: ecosystem tools that do jobs the exam absolutely tests, using tools it does not name.

Why the exam is (mostly) tool-agnostic

☺ Like you’re 10: The test cares that you can hang a shelf, not which brand of drill you used.

The CNPE is a performance-based exam: 120 minutes on a Linux remote desktop, driving a real terminal and real web UIs to do things — with only kubernetes.io/docs, kubernetes.io/blog, whatever a task’s Quick Reference box links, and locally installed docs to lean on. That format shapes everything about how you should study tools. The curriculum states you will not be tested on deep, tool-specific trivia unless a project is referenced in the competencies — so your job is to recognise each named tool on sight, know which platform job it does, and be fluent enough to drive it from memory and from what the cluster itself will tell you.

The curriculum lists fifteen projects as examples, with an explicit expectation that you’ll read the docs for any you don’t already know. Every one is a CNCF project, and every one slots cleanly into one of the five exam domains. Learn the mapping once and an unfamiliar logo becomes a familiar job.

The official fifteen — the exam’s named tools

☺ Like you’re 10: These fifteen are the only tools the exam names out loud. Learn what each one is for.

Every project in the table below is on the official exam tool list — the fifteen the CNPE curriculum names by example. Read it by row: what the tool does, then which domain it lives in. You don’t need to memorise their flags; you need to know, instantly, “that’s the GitOps one” or “that’s the tracing one.”

Pick a platform job → see its tools

☺ Like you’re 10: Choose a job from the dropdown and you’ll see just the tools for that job, with a one-line note and who on the Guild owns it.

Flip the picker below from one platform job to the next. Each panel lists the relevant tools — the official fifteen and the ecosystem tools that share that drawer — with a one-line “what it does” and the character who owns the work. Every panel links to its full lesson, because this page is the map; the lessons are the territory.

Beyond the official list — the ecosystem you’ll still meet

☺ Like you’re 10: There are extra tools that aren’t on the exam’s named list, but you’ll bump into them the moment you build a real platform.

The fifteen are the tools the curriculum names, but a working platform is never just fifteen tools. These projects are beyond the official list — you won’t be quizzed on their trivia by name, yet the competencies they serve (self-service portals, TLS, autoscaling, supply-chain security) are squarely on the exam. Recognise them, know the job each does, and you’ll read a task scenario faster.

Meeting a tool you’ve never seen — at exam time

☺ Like you’re 10: If a tool is new to you, don’t panic — open its instruction booklet, find the one page you need, and copy the example.

Because the exam is hands-on and the project’s own site is off-limits, the real skill isn’t memorising every tool — it’s making the cluster teach you one, fast. When a task drops you in front of an unfamiliar CRD or CLI, work this drill:

• Find the resource kind. kubectl api-resources | grep -i <keyword> and kubectl get crd show you what the tool installed. That tells you which API you’re steering.
• Ask the cluster to teach you the schema. kubectl explain <kind> --recursive prints every field and its type — often faster than reading prose docs.
• Copy an example that already exists, then adapt. The project’s quickstart page is not reachable in the exam — but the cluster is. kubectl get <kind> -A -o yaml on something the tool already created hands you a working manifest; the CLI’s own --help and anything the task’s Quick Reference box links fill the gaps.
• Verify, don’t assume. Apply it, then kubectl get / describe and read the status conditions and events. Reconcilers report their own health — let them tell you if it worked.

This is exactly how a working platform engineer meets a new operator on a Tuesday, and it’s exactly what the CNPE rewards. While you study, keep the glossary open for the vocabulary and the exam guide open for the logistics — build the habit now, because on the day your only references are the cluster, kubernetes.io and the task’s Quick Reference box.

Check your answers

1. Fifteen. You are not tested on deep tool-specific trivia unless a project is referenced in the competencies — you’re expected to recognise each tool and read its docs for anything unfamiliar.
2. GitOps engines: Argo (CD) and Flux. Progressive delivery: Argo Rollouts and Flagger.
3. Domain 4 — Observability & Operations (metrics, dashboards, instrumentation, and tracing respectively).
4. Any two of: Trivy (scanning), cosign/Sigstore (signing), Syft (SBOM). All are beyond the official fifteen but serve D5 supply-chain competencies.
5. kubectl explain <kind> --recursive (after finding it with kubectl get crd / kubectl api-resources) — let the cluster print the schema, then copy an object the tool already created with kubectl get <kind> -o yaml and adapt it. The project’s own quickstart page is not available in the exam.