CNPA Certified Cloud Native Platform Engineering Associate Exam Topics and Questions

This is the largest block on the exam and the one that sets the conceptual vocabulary for everything that follows. If your mental model of what a platform team actually does is fuzzy, this topic will punish you across every other domain too. Expect questions that test whether you understand the reasoning behind platform decisions, not just the mechanics. The spread across delivery practices, architecture, and infrastructure means you cannot afford gaps anywhere in this topic.

– How platforms are designed and why

Platform Architecture and Capabilities and Platform Engineering Goals, Objectives, and Approaches sit at the heart of this topic. You need to know what a platform is trying to achieve for its internal users: reducing cognitive load, enabling self-service, and creating paved roads that development teams can follow without needing to understand every underlying detail. The exam tests whether you can distinguish between platform capabilities (what the platform exposes) and platform architecture (how it is structured to deliver those capabilities). Questions frequently turn on the reasoning behind a design decision rather than the decision itself, so be clear on the tradeoffs that platform teams make between standardisation and flexibility. The Goals and Objectives sub-topic means you should also understand the difference between a platform team acting as a product team versus acting as a shared-services function, because that distinction shapes how work is prioritised and measured.

– Declarative management and application environments

Declarative Resource Management means describing desired state and letting the system reconcile toward it. The exam will test your understanding of why declarative approaches are preferred over imperative ones in platform contexts, not just that they are preferred. Application Environments and Infrastructure Concepts covers the logical separation of environments (development, staging, production) and how infrastructure is abstracted to support them. You need to understand how environment configuration is managed, how infrastructure is represented as code, and how those representations interact with the delivery pipeline. Where candidates lose marks here is treating these as separate concerns: on the exam, environment configuration and infrastructure definition are tightly coupled, and items often ask you to reason about what happens when they diverge.

– Delivery practices: CI, CD, and GitOps

Continuous Integration Fundamentals, Continuous Delivery and GitOps, and DevOps Practices in Platform Engineering cover the delivery mechanics that platform engineers enable for development teams. CI here is about what the platform provides: the pipeline infrastructure, the feedback loops, the gates that enforce quality. GitOps is the practice of using Git as the source of truth for both application and infrastructure state, with automated reconciliation pulling desired state into the cluster. DevOps Practices in the platform context means understanding how platform teams apply DevOps thinking internally, not just how they enable it for others. The exam distinguishes between a platform team that builds delivery tooling and a development team that uses it, so keep that perspective clear. Candidates who conflate GitOps with generic CD pipelines tend to pick the wrong option when the two approaches are contrasted.

How Platform Engineering Core Fundamentals is tested

At 36% of the exam, this topic will appear more than any other. Items rarely ask for a definition. Instead, they present a scenario, a team decision, or a configuration choice and ask you to identify what is consistent with platform engineering principles. The demand is conceptual reasoning, not recall. You will be asked to evaluate approaches against goals: does this design serve self-service? Does this pipeline structure support the separation of concerns that GitOps requires? Where candidates lose marks is in picking the option that sounds operationally sensible in a general DevOps context rather than the option that reflects platform engineering specifically. The GitOps and declarative management sub-topics are particularly prone to this trap, because candidates with strong general Kubernetes or CI/CD backgrounds apply the wrong frame. Items reward the candidate who can apply the platform-team perspective consistently, even when a more familiar DevOps answer is available as a distractor.

After the foundational layer, the exam turns to the operational and security disciplines that keep a platform trustworthy at runtime. This topic groups three distinct concerns: knowing what is happening inside your platform, controlling what is allowed to happen, and enforcing that control consistently. The breadth is the challenge. You need enough depth in observability tooling, Kubernetes security primitives, and policy enforcement to answer scenario-based questions across all three areas without confusing them.

– Seeing what your platform is doing

Observability Fundamentals covers traces, metrics, logs, and events as four distinct signal types. The exam expects you to know not just what each one is but when each one is the right tool. Traces follow a request across service boundaries. Metrics give you aggregate numeric state over time. Logs capture discrete events with context. Events, in the cloud-native sense, often refer to structured notifications from system components. Where candidates lose marks is treating these as interchangeable or ranking them in a fixed hierarchy. The exam will present a scenario where one signal type is clearly more appropriate than another, and the item rewards the candidate who can match signal type to diagnostic need. Knowing that a distributed latency problem is a trace problem, not a log problem, is the kind of judgment being tested.

– Securing communication and workloads

Secure Service Communication and Kubernetes Security Essentials cover the mechanisms that protect workloads and the traffic between them. Service mesh approaches to mutual TLS, workload identity, and traffic policy sit under secure communication. Kubernetes Security Essentials covers the primitives: RBAC, network policies, pod security standards, and secrets management. The exam tests whether you can reason about which control addresses which threat. A question about preventing a compromised pod from accessing other services is a network policy question, not an RBAC question. Candidates who apply the wrong primitive to a given threat model consistently lose marks here. Security in CI/CD Pipelines extends this into the delivery process: image signing, supply chain controls, and the principle that security gates belong in the pipeline, not only at runtime.

– Governing the platform with policy

Policy Engines for Platform Governance covers tools like OPA and Kyverno that let platform teams encode rules and enforce them automatically across the cluster. The key distinction the exam draws is between admission control (blocking non-compliant resources before they are created) and runtime policy (detecting or correcting violations after the fact). You need to understand where in the Kubernetes request lifecycle a policy engine operates and what kinds of rules are expressible. The exam also connects policy engines to the conformance theme: a policy engine is how a platform team makes its standards machine-enforceable rather than documentation-only. Items in this group reward candidates who understand the operational placement of policy controls, not just the existence of the tools.

How Platform Observability, Security, and Conformance is tested

At 20% of the exam, this topic produces a meaningful number of items, and the spread across three distinct sub-domains means you cannot specialise. Items tend to be scenario-driven: a platform team needs to detect anomalous behaviour, or a workload is failing to communicate, or a non-compliant resource keeps appearing in the cluster. The item asks what the team should do or which tool is appropriate. The reward goes to candidates who match the right mechanism to the stated problem. The most common trap is applying a security control that would work in principle but is not the most direct answer given the scenario's constraints. For observability items, candidates who treat all signal types as equivalent tend to pick the wrong option when the scenario contains a clear diagnostic signal. For policy items, the distinction between preventing a violation and detecting one after the fact is frequently the pivot point. Broad, even coverage of all five sub-topics is the only safe strategy.

The previous topic covered security and observability as operational disciplines. This one zooms in on the delivery pipeline itself and on what happens when delivery breaks down. At 16%, it carries enough weight to shift your overall score meaningfully. The overlap with Topic 1's CI and GitOps content is intentional: this topic goes deeper into pipeline structure, GitOps workflows, and the incident response discipline that platform engineers own when delivery systems fail.

– Pipeline structure and the CI/CD relationship

Continuous Integration Pipelines Overview and CI/CD Relationship Fundamentals together test whether you understand how the two halves of a delivery pipeline connect and where the platform team's responsibility begins and ends. CI is about validating a change: build, test, and produce an artifact. CD takes that artifact and moves it toward production. The exam distinguishes between these stages because the platform team's role differs at each one: CI infrastructure is typically owned by the platform, while CD often involves handoffs to deployment tooling or GitOps controllers. Items in this area reward candidates who can identify where a failure belongs in the pipeline and which team or system is responsible for it. Candidates who treat CI/CD as a single undifferentiated concept tend to pick options that misplace responsibility.

– GitOps in practice

GitOps Basics and Workflows and GitOps for Application Environments cover how GitOps operates as a delivery mechanism rather than just a philosophy. The exam expects you to understand the pull-based reconciliation model, the role of the Git repository as the source of truth, and how environment-specific configuration is managed across branches or directories. GitOps for Application Environments specifically tests how GitOps patterns apply when you have multiple environments with different promotion gates. The key exam trap here is conflating a push-based CD pipeline with a GitOps workflow: they can produce similar outcomes, but the control model is different, and items will test that distinction. Knowing that a GitOps controller detects drift and reconciles toward the Git state, rather than waiting for a pipeline trigger, is the kind of operational detail that separates correct from incorrect options.

– Incident response in delivery systems

Incident Response in Platform Engineering covers what a platform team does when something in the delivery or runtime system breaks. This sub-topic is often underweighted by candidates who focus on the delivery mechanics and assume incident response is a generic operations topic. On this exam, it is specifically about how platform engineers handle incidents that affect the platform itself or the pipelines it supports. The exam tests the sequence of response actions, the distinction between mitigation (stopping the bleeding) and remediation (fixing the cause), and the role of postmortems in preventing recurrence. Items reward candidates who apply a structured response model rather than reaching for the most technically sophisticated fix first. Blameless postmortem culture and the feedback loop from incidents back into platform improvement are also within scope.

How Continuous Delivery & Platform Engineering is tested

This topic's items tend to be more procedural than the foundational topic's conceptual ones. You will be asked to sequence pipeline stages, identify where a GitOps workflow diverges from a push-based pipeline, or decide what a platform team should do first in a described incident. The 16% weight means you will see enough items to establish a clear pattern of strength or weakness. The GitOps sub-topics are the most likely to generate distractor options that are technically valid in a general CD context but wrong in a GitOps-specific one. Incident response items reward the candidate who follows the structured response sequence rather than the one who applies the most technically sophisticated fix. Pipeline items often hinge on responsibility: which team owns which stage, and which system is authoritative for which state. Candidates who have strong general DevOps knowledge but have not studied the platform engineering perspective on delivery tend to misread these responsibility questions.

Delivery pipelines depend on the infrastructure layer beneath them, and this topic covers how that layer is exposed and managed through Kubernetes-native APIs. At 12%, it is narrower in scope than the previous topics but technically dense. The sub-topics cluster tightly around Kubernetes extension mechanisms: custom resources, operators, and the reconciliation loop. If you have not worked directly with Kubernetes API extensions, this is the topic where abstract knowledge will cost you the most.

– The Kubernetes extension model

Custom Resource Definitions and the Kubernetes Operator Pattern are the two mechanisms the exam expects you to understand as a pair. CRDs extend the Kubernetes API to represent platform-specific resources: a database, a tenant environment, a deployment pipeline configuration. Operators encode the operational logic for managing those custom resources, using the same reconciliation model that Kubernetes uses for its built-in objects. The exam tests whether you understand why this extension model is preferred over external scripts or manual provisioning in a platform context. Items reward candidates who can identify which component is responsible for which part of the lifecycle: the CRD defines the schema, the operator acts on instances of that schema. Candidates who conflate the two or treat operators as simply enhanced Helm charts tend to pick options that misplace the control logic.

– Reconciliation and infrastructure provisioning

The Kubernetes Reconciliation Loop and Infrastructure Provisioning with Kubernetes are the operational mechanics that make the extension model work. The reconciliation loop is the control plane pattern: a controller watches for the difference between desired state (what the resource spec says) and actual state (what exists in the cluster or the underlying infrastructure), then acts to close that gap. Infrastructure Provisioning with Kubernetes extends this into the infrastructure layer: using Kubernetes controllers to provision cloud resources, networking, or storage, so that the same declarative model used for application workloads applies to the infrastructure supporting them. The exam tests whether you understand the implications of eventual consistency in this model: the system will converge, but not instantly, and items often ask about the behaviour of the system during the reconciliation window.

How Platform APIs and Provisioning Infrastructure is tested

Items in this topic are technically specific. You will be asked to reason about what happens at each stage of the Kubernetes API extension lifecycle: resource creation, controller detection, reconciliation, and status reporting. The operator pattern items frequently present a scenario where a custom resource has been created but the expected infrastructure has not appeared, and the item asks where in the operator lifecycle the failure is most likely to have occurred. Items reward candidates who understand the reconciliation loop as an ongoing process rather than a one-time event. The CRD sub-topic generates items that test schema and validation concepts: what the API server enforces at admission time versus what the operator enforces at reconciliation time. Candidates who treat Kubernetes operators as black boxes and cannot reason about their internal control flow will find these items disproportionately difficult. The 12% weight means a weak performance here has a measurable effect on your total score.

The API and provisioning layer exists to serve developers, and this topic covers how that service is made accessible. Internal Developer Platforms bring together the capabilities built in earlier topics and present them through interfaces that development teams can use without deep platform expertise. At 8%, this topic is not the exam's heaviest, but it connects the technical platform work to the user experience rationale that underpins platform engineering as a discipline.

– Making platform capabilities accessible

Simplified Access to Platform Capabilities and Developer Portals for Platform Adoption cover the interface layer between the platform and its users. An IDP succeeds when developers can provision environments, trigger pipelines, and inspect service status without filing tickets or reading infrastructure documentation. The exam tests whether you understand what makes a portal effective from an adoption standpoint: discoverability of capabilities, clarity of the self-service workflow, and reduction of the steps required to go from intent to running workload. Developer Portals for Platform Adoption specifically addresses how the portal functions as the primary adoption mechanism: if developers do not use it, the platform's technical quality is irrelevant. Items in this area reward candidates who can evaluate a portal design decision against the adoption goal rather than against a technical correctness criterion.

– Catalogs, automation, and AI in the platform

API-Driven Service Catalogs and AI/ML in Platform Automation cover the programmatic and intelligent layers of an IDP. A service catalog exposes platform capabilities as API-addressable resources, allowing tooling, scripts, and other systems to interact with the platform the same way a developer using a portal would. The exam tests whether you understand the relationship between the catalog and the portal: the catalog is the machine interface, the portal is the human interface, and they should expose the same underlying capabilities. AI/ML in Platform Automation is the most forward-looking sub-topic on the exam. It covers how machine learning and intelligent automation are applied to platform tasks: anomaly detection, automated remediation suggestions, or intelligent routing of developer requests. Items here are likely to test conceptual understanding of where AI fits in the platform automation loop rather than specific tool implementations.

How IDPs and Developer Experience is tested

At 8%, this topic generates fewer items than the foundational or observability topics, but those items tend to test judgment about platform design from a user perspective rather than technical correctness. The most common item type presents a scenario where a platform team has built a capability and asks what would most improve developer adoption or reduce friction. Items reward candidates who prioritise the developer experience outcome over the technically elegant solution. The AI/ML sub-topic is the least predictable area: items are likely to focus on the appropriate placement of intelligent automation in a platform workflow rather than on any specific algorithm or framework. Service catalog items often hinge on the API-driven nature of the catalog and what that enables for downstream tooling. Candidates who focus only on the technical platform capabilities and neglect the adoption and experience angle tend to underperform on this topic relative to its weight.

Building a platform is only half the work. Knowing whether it is actually delivering value to the engineering organisation is the other half, and this topic covers the measurement discipline that answers that question. Alongside IDPs and Developer Experience, it carries 8% of the exam. The sub-topics are tightly focused: platform efficiency and team productivity on one side, and DORA metrics as the industry-standard measurement framework on the other. The exam tests whether you can connect measurement to platform decisions, not just name the metrics.

How Measuring your Platform is tested

Items in this topic are more interpretive than technical. You will be given a scenario describing a platform team's situation and asked which metric or measurement approach is most relevant, or what a given metric result implies about platform health. DORA metrics items reward candidates who know what each metric measures and what it does not measure. Deployment frequency, lead time for changes, change failure rate, and mean time to restore are each sensitive to different parts of the delivery system, and items often test whether a candidate can identify which metric is affected by a described change to the platform. Platform efficiency items tend to focus on team-level productivity signals rather than system-level performance metrics. The trap is reaching for a technical monitoring metric when the item is asking about an engineering effectiveness metric. Candidates who have studied DORA in a general DevOps context should verify they understand how the metrics apply specifically to platform team initiatives, because that framing shifts which metric is most relevant in several scenario types.