CNPE study plan: what "platform engineer" means in the exam, the tools and a six-week plan

CNPE in numbers

The exam has 15-20 performance-based tasks in 120 minutes and a 64% pass mark, the lowest of the hands-on exams. The list price is $445 and the certification is valid for 2 years. Tasks are done on designated hosts reached by ssh from a base system, which must not be rebooted, and nested ssh is not supported.

What "platform engineer" means in this exam

The competencies describe a person who builds the paved road other teams use, not someone who deploys one application. The verbs are telling: implementing GitOps workflows, designing CRDs for platform services, implementing self-service provisioning, using policy engines for governance, measuring platform efficiency. A typical task is therefore about a capability for others: a namespace template with quotas and access, a GitOps application that keeps a directory in sync, an API that turns a short request into several resources, a policy that rejects what the platform does not allow.

• Think in tenants: quotas, limits, RBAC and network isolation per team.
• Think in reconciliation: a controller that keeps desired and actual state equal, whether Argo CD, Flux or an operator.
• Think in APIs: a CRD with a schema is the contract between the platform and its users.
• Think in guardrails: admission policies that block what is unsafe and report what is not compliant.

The tool list and how to handle unfamiliar tools

The curriculum prints 15 example tools: Argo, Crossplane, Flagger, Flux, Gatekeeper, Grafana, Istio, Jaeger, Kyverno, Linkerd, OPA, OpenCost, OpenTelemetry, Prometheus, Tekton. It also says candidates are expected to complete tasks with unfamiliar tools by relying on the help and documentation available in the exam, and that deep tool-specific knowledge is not tested unless a competency references it. Since only kubernetes.io and the task links are allowed, the practical skill is reading a tool quickly: its --help, its CRDs through kubectl explain, and the status conditions on its resources.

1. 1Install one tool from each category in a practice cluster: a GitOps controller, a policy engine, an infrastructure API, a metrics stack.
2. 2For each, find its CRDs with kubectl api-resources and read their fields with kubectl explain.
3. 3Make a change and find where the tool reports success or failure: a status condition, an event, a report resource.
4. 4Repeat with the second tool of the same category, so the pattern, not the brand, is what you learn.

GitOps and continuous delivery

This domain is 25%. It asks for GitOps workflows for both applications and infrastructure, CI/CD pipelines integrated with Kubernetes, and progressive delivery strategies such as blue/green or canary. Argo, Flux, Flagger and Tekton are the example tools in this area. Practise the loop end to end: a repository, a controller that syncs it, a change that rolls out, and a rollback.

• Point a GitOps controller at a path in a repository, with automated sync and pruning, and watch it correct a manual change.
• Fix a broken manifest in the repository so a stuck reconciliation becomes ready.
• Run a canary that shifts part of the traffic, pauses and then promotes.
• Write a small pipeline of two tasks and run it to success in the cluster.

Platform APIs, self-service and operators

Platform APIs and Self-Service Capabilities is also 25%. Its competencies are designing CRDs for platform services, self-service provisioning through platform APIs, operators for automation and integration, and automation frameworks. Crossplane is the example tool built for this, and a CRD you write yourself is the simplest form. Practise writing a CRD with a validated schema, then a composition or operator that turns one custom resource into several ordinary ones.

• Write a CRD with an OpenAPI schema, an enum field and a status subresource, and test that invalid objects are rejected.
• Define a composite resource and a composition that creates a ConfigMap or Namespace from a short claim.
• Deploy a provided operator, create its custom resource and verify the objects it reconciles.
• Generate per-team resources automatically when a namespace with a label appears.

Observability, security and policy

Observability and Operations (20%) covers monitoring, alerting, logging and tracing, efficiency metrics, and incident diagnosis; Prometheus, Grafana, OpenTelemetry, Jaeger and OpenCost are its example tools. Security and Policy Enforcement (15%) covers secure service-to-service traffic, RBAC, audit trails and compliance artefacts such as SBOMs, policy engines and admission controllers, and scanning in pipelines; Kyverno, OPA, Gatekeeper, Istio and Linkerd are its example tools.

• Scrape an application with a monitor resource and load an alerting rule; confirm both through the API.
• Configure a collector pipeline that receives telemetry and exports it.
• Diagnose a degraded Deployment: probes, resources, image pull errors, events.
• Enforce a policy that blocks a privileged Pod or an untrusted registry, and read the resulting report.
• Grant a CI ServiceAccount exactly the permissions it needs and test them with kubectl auth can-i.

A six-week CNPE plan

The plan assumes CKA-level kubectl skills and gives each domain a week in proportion to its weight. Use a practice cluster with enough memory for one or two platform tools at a time, and reset it between topics; running every tool at once is neither necessary nor how the curriculum is organised.

CNPE hands-on labs are in preview: the GoldenKube CLI runs its scenarios on your own machine, but it has no public release yet.

Building a practice platform at home

CNPE tasks assume a running platform, so the most useful practice environment is a small one you build yourself. A single local cluster is enough. Install a few tools from the curriculum list, one per domain, and use them together so that a change in Git becomes a running workload that is observed and checked by policy. Building it teaches the connections between the tools, which is what platform tasks tend to test.

Rebuild the stack from scratch at least once. The second build shows which steps you understand and which you only copied, and it is close to what a task asking you to set up or repair part of a platform feels like.