The CNPA (Certified Cloud Native Platform Engineering Associate) is the CNCF's entry-level certification for platform engineering. It is a multiple-choice exam that tests whether you understand how to build and run an internal developer platform on Kubernetes: GitOps, declarative APIs, policy and security, developer portals, observability, and the metrics that tell you whether the platform works. This guide breaks down the official CNPA curriculum domain by domain, shows where to spend your study time, and gives an honest take on whether to sit it.
If you are new to the discipline itself, read our platform engineering and internal developer portals guide first. This post assumes you know what an IDP is and focuses on the exam.
CNPA Exam Domains and Weights
The CNPA curriculum has six domains, and one of them carries more than a third of the exam. The weights below come straight from the CNCF's published CNPA curriculum.
| Domain | Weight |
|---|---|
| Platform Engineering Core Fundamentals | 36% |
| Platform Observability, Security, and Conformance | 20% |
| Continuous Delivery and Platform Engineering | 16% |
| Platform APIs and Provisioning Infrastructure | 12% |
| IDPs and Developer Experience | 8% |
| Measuring Your Platform | 8% |
Two domains, Core Fundamentals and Observability/Security, account for 56% of your score. If you only have a few evenings, spend them there.
Exam logistics are less settled than the curriculum. The Linux Foundation's CNPA page is the source of truth for price, duration, retake policy, and validity. As I write this, it lists the exam at $250 with one free retake, an online proctored format, and a 120-minute window. Third-party prep sites disagree with each other on duration, question count, and validity, and several are dump sellers, so I would not trust any of them over the official page.
Domain 1: Platform Engineering Core Fundamentals (36%)
This domain tests whether you can explain what a platform is, what it is for, and which practices it rests on. The curriculum lists declarative resource management, DevOps practices, application environments, platform architecture and capabilities, platform goals and approaches, CI fundamentals, and continuous delivery with GitOps.
Concepts to be able to explain without notes:
- Declarative vs imperative. You describe desired state and a controller converges on it. This idea underlies GitOps, Kubernetes, and Crossplane-style provisioning, so it shows up in several domains.
- Platform as a product. The platform team has users (developers), a roadmap, and adoption it must earn. A mandate is not a strategy.
- Golden paths. Opinionated, supported routes to production that make the right way the easy way. They are optional by design.
- Capabilities vs tools. A platform exposes capabilities such as "provision a database" or "deploy a service". The tool behind each capability can change without developers noticing.
- CI vs CD vs GitOps. CI builds and tests, CD promotes artifacts, and GitOps makes Git the source of truth with an in-cluster agent reconciling to it.
If GitOps is the weak spot, work through our ArgoCD GitOps tutorial end to end. Having actually watched a drifted resource heal itself makes the exam questions on reconciliation and pull-based delivery trivial.
Domain 2: Platform Observability, Security, and Conformance (20%)
This is where candidates with only CI/CD backgrounds lose points. The curriculum covers observability fundamentals (traces, metrics, logs, and events), secure service communication, policy engines for governance, Kubernetes security essentials, and security in CI/CD pipelines.
What I would make sure you can answer:
- Which signal answers which question: metrics for "is something wrong", traces for "where", logs for "why", events for "what changed".
- Why service-to-service traffic uses mTLS, and what a service mesh gives you versus doing it in application code.
- What a policy engine does (admission-time validation or mutation) and how that differs from a runtime security tool. Kyverno and OPA Gatekeeper are the usual examples.
- Kubernetes security basics: RBAC, network policies, Pod Security Standards, and secrets handling.
- Where scanning, signing, and policy checks belong in a pipeline.
A small Kyverno policy is worth reading once so "policy as code" is concrete:
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-team-label
spec:
validationFailureAction: Enforce
rules:
- name: check-team-label
match:
any:
- resources:
kinds: ["Deployment"]
validate:
message: "Deployments must carry a 'team' label."
pattern:
metadata:
labels:
team: "?*"
If you want to go deeper on the cluster side of this domain, our Kubernetes production best practices guide covers RBAC, network policies, and pod security in a form that maps well to the exam.
Domain 3: Continuous Delivery and Platform Engineering (16%)
Expect questions on CI pipeline structure, the relationship between CI and CD, GitOps workflows, GitOps for application environments, and incident response in a platform context.
The part people underestimate is incident response. The platform team owns the paved road, so when a golden-path template ships a bad default, the blast radius is every team using it. Be ready to reason about rollback via Git revert, progressive delivery, and how platform teams communicate changes to their users.
Domain 4: Platform APIs and Provisioning Infrastructure (12%)
This domain covers the Kubernetes reconciliation loop, APIs for self-service platforms using CRDs, infrastructure provisioning with Kubernetes, and the operator pattern for integration.
The mental model is: a developer submits a small, high-level resource, and a controller turns it into real infrastructure. In my own platform work this is the pattern that finally let us retire ticket queues for databases and buckets. The developer-facing object looks like this (illustrative, not tied to one tool):
apiVersion: platform.example.com/v1alpha1
kind: PostgresDatabase
metadata:
name: orders-db
namespace: team-orders
spec:
size: small
version: "16"
You do not need to write a controller for the exam. You do need to know what a CRD is, what a controller's reconcile loop does (observe, compare, act, repeat), and why the operator pattern suits stateful or externally managed resources.
Domain 5: IDPs and Developer Experience (8%)
The curriculum covers simplified access to platform capabilities, API-driven service catalogs, developer portals for adoption, and AI/ML in platform automation. This is a small domain, but the questions are close to free points if you have read about Backstage-style portals: a software catalog, scaffolding templates, and plugin-based integrations. The AI/ML bullet is new territory for most study guides, so expect conceptual questions about automation assistance in platform workflows rather than specific products.
Domain 6: Measuring Your Platform (8%)
Platform efficiency, team productivity, and DORA metrics. Know the four DORA delivery metrics: deployment frequency, lead time for changes, change failure rate, and time to restore service. Know why they measure outcomes of the software delivery system rather than individual output, and why a platform team should track adoption and developer satisfaction alongside them.
My opinion: do not skip this domain because it is only 8%. It is the easiest 8% on the exam, and it is also the part of platform engineering most teams skip in real life.
A 4-Week CNPA Study Plan
This assumes you already run Kubernetes and a CI/CD pipeline and can spend 5 to 7 hours a week. Add two weeks if you are new to Kubernetes, or sit the CKAD first.
| Week | Focus | Hands-on |
|---|---|---|
| 1 | Domain 1: declarative management, platform architecture, GitOps basics | Deploy an app with ArgoCD and break it on purpose |
| 2 | Domain 2: observability signals, mTLS, policy engines, K8s security | Install Kyverno and enforce the label policy above |
| 3 | Domains 3 and 4: delivery pipelines, CRDs, controllers, operators | Write a CRD and inspect an existing operator's reconcile behavior |
| 4 | Domains 5 and 6, then timed practice questions | Review DORA definitions, take mock exams, re-read the curriculum |
Re-read the official curriculum on day 1 and again in week 4. Every question on the exam maps to a bullet in it.
Is the CNPA Worth It?
It is worth taking if you are moving toward a platform engineering role, or already doing platform work without a credential to show for it. It gives you a vendor-neutral way to prove you know the vocabulary and patterns, and the study process fills gaps (policy engines, measurement) that day-to-day work often leaves.
It is not worth much on its own. An associate-level multiple-choice exam does not prove you can operate a platform, and a hiring manager will weigh a working IDP project or a platform migration you led far above it. I would pair it with a visible project, and I would treat it as a stepping stone to the hands-on Kubernetes certifications. This comparison of CKA, CKAD, and CKS helps you decide what comes next.
Practice Platform Engineering Hands-On With CloudaQube
The fastest way to retain GitOps, policy-as-code, and Kubernetes API concepts is to run them. CloudaQube's hands-on labs give you real environments to practice declarative delivery, cluster security, and observability without building a lab from scratch. Browse the DevOps course catalog and work through the topics that map to your weakest CNPA domains.
