Skip to content

Cloud Native Platform Engineering Associate (CNPA) Fact Sheet

Exam Overview

Exam Code: CNPA Exam Name: Certified Cloud Native Platform Engineering Associate Level: Associate Duration: 120 minutes Format: Multiple choice and multiple select, online proctored Questions: 60 Passing Score: 75% Cost: USD 250 (includes one free retake) Valid For: 2 years Delivery: Online proctored through PSI Prerequisites: None; cloud native fundamentals assumed

Verify before booking. CNPA is one of the newer CNCF certifications and its curriculum is still settling. Confirm the current domain list, duration, and price on the official pages below.

📖 CNPA certification page - registration and curriculum 📖 Linux Foundation CNPA announcement - background and scope 📖 CNCF Platforms White Paper - the conceptual foundation this exam is built on 📖 CNCF Platform Engineering Maturity Model - the maturity framework

What kind of exam this is

CNPA is about building a platform as a product, not about operating Kubernetes. It assumes you know Kubernetes and asks whether you can design an internal platform on top of it: golden paths, self-service APIs, developer experience, conformance, and how you measure whether the platform is working.

Note the duration: 120 minutes, longer than the 90 minutes given to other CNCF associate exams, which reflects heavier scenario-style questions.

The CNCF Platforms White Paper is effectively the syllabus. Read it directly.

Why this exam is in this repo

The repo already has a platform engineer roadmap, but no certification anchored the role. CNPA is the vendor-neutral one, and it sits naturally above CKA, CGOA, and OTCA, which cover the layers a platform assembles.

Target Audience

  • Platform engineers and platform team leads
  • SREs moving into platform work
  • Engineering managers responsible for developer productivity
  • Architects designing internal developer platforms

Exam Domains

Domain 1: Platform Engineering Core Fundamentals (36%)

The largest domain by a wide margin.

Key Concepts: - What a platform is: a curated set of capabilities offered as a product to internal users - Platform as a product: users, value proposition, roadmap, feedback loops, and adoption as a voluntary outcome - Golden paths and paved roads: opinionated, supported routes that are easier than the alternatives - The difference between a platform and a set of tools - Cognitive load reduction as the central justification, drawing on Team Topologies - Platform team as an enabling and platform-shaped team - Interfaces and abstractions: what to hide, what to expose, and the cost of leaky abstractions - Self-service versus ticket-driven operations - Platform boundaries and the "thinnest viable platform" idea - The CNCF Platform Engineering Maturity Model: provisional, operational, scalable, optimizing, across attributes such as investment, adoption, interfaces, operations, and measurement - Anti-patterns: building without users, mandating adoption, rebuilding what a managed service provides, and platform teams that become a ticket queue

Domain 2: Platform Observability, Security, and Conformance (20%)

Key Concepts: - Observability of the platform itself, distinct from observability the platform offers to tenants - The three signals and OpenTelemetry as the standard collection layer - SLOs for platform capabilities and error budgets - Multi-tenancy models: namespace, cluster, and control plane isolation, and their trade-offs - Tenant isolation: RBAC, network policy, resource quotas, admission control, runtime isolation - Policy as code: OPA Gatekeeper and Kyverno for enforcing conformance - Supply chain security: image signing, provenance, SBOMs, admission verification - Secrets management patterns for a multi-tenant platform - Conformance: validating that workloads and clusters meet platform requirements - Compliance evidence generated by the platform rather than gathered by hand

Domain 3: Continuous Delivery and Platform Engineering (16%)

Key Concepts: - CI and CD boundaries in a platform context - GitOps as the delivery model, and where the platform owns it versus where tenants do - Progressive delivery as a platform capability - Environment provisioning and preview environments as a self-service capability - Release strategy, rollback, and the platform's role in both - Pipeline templates and reusable delivery workflows - Artifact management, registries, and promotion between environments

Domain 4: Platform APIs and Provisioning Infrastructure (12%)

Key Concepts: - The Kubernetes API as a platform API, and custom resources as the interface - Operators and controllers as the reconciliation mechanism for platform capabilities - Crossplane and control plane patterns for provisioning cloud infrastructure declaratively - Infrastructure as Code, and how it composes with a control plane approach - Composition and abstraction: presenting a simple claim that expands into complex infrastructure - API design for platform capabilities: versioning, deprecation, defaults, validation - Kubernetes Resource Model as a common interface

Domain 5: IDPs and Developer Experience (8%)

Key Concepts: - Internal Developer Platform versus Internal Developer Portal, and why the distinction matters - Backstage and portal patterns: service catalog, software templates, TechDocs, scaffolding - Developer onboarding and time to first deployment - Documentation as a platform feature - Feedback loops, support models, and treating developer complaints as product signal - Local development experience and its relationship to the platform

Domain 6: Measuring Your Platform (8%)

Key Concepts: - DORA metrics: deployment frequency, lead time for changes, change failure rate, time to restore service - SPACE framework dimensions for developer productivity - Adoption metrics and why voluntary adoption is the honest signal - Platform SLOs and reliability measurement - Cost measurement, showback, and chargeback - Developer satisfaction surveys and qualitative feedback - Distinguishing vanity metrics from actionable ones