CNPE Study Guide: Cloud Native Platform Engineering

What CNPE validates

Certified Cloud Native Platform Engineer focuses on turning cloud native infrastructure into a dependable product for internal users. The official description emphasizes architecture, security, optimization, scalable self-service infrastructure, GitOps and delivery, platform APIs, operations, and policy. The exam is published as an online, proctored, performance-based assessment with 120 minutes in a Linux remote desktop. That format rewards the ability to inspect context, implement a requested outcome, diagnose failure, and verify the result.

The public domains are Platform Architecture and Infrastructure at 15%; GitOps and Continuous Delivery at 25%; Platform APIs and Self-Service Capabilities at 25%; Observability and Operations at 20%; and Security and Policy Enforcement at 15%. The largest domains reinforce the central platform-engineering loop: declare a safe developer capability, automate its lifecycle, deliver changes continuously, observe outcomes, and govern access and risk.

Do not reduce platform engineering to installing a portal or operating Kubernetes. A platform is a product with users, interfaces, support, reliability, security, cost, and evolution. Kubernetes may be the substrate, while Git, CI, OCI registries, controllers, templates, gateways, policy engines, observability systems, and external providers form the wider product.

A platform mental model

Use four layers. The foundation supplies compute, networking, DNS, storage, cluster services, identity, and failure boundaries. The delivery plane turns reviewed source into immutable artifacts and reconciles approved configuration. The capability plane exposes versioned APIs, templates, workflows, and documentation. The operations and governance plane measures outcomes, responds to incidents, controls authority, verifies artifacts, enforces policy, records audit evidence, and manages exceptions.

For every task, ask five questions: Who is the user? What contract do they consume? Which controller or workflow owns convergence? Which evidence proves success or failure? What happens during update, deletion, dependency outage, and recovery? This prevents a common mistake: demonstrating the happy path while leaving lifecycle and operations undefined.

Domain 1: platform architecture and infrastructure

Begin with outcomes and boundaries, not a shopping list. A platform should make common developer work fast and safe through paved paths. Those paths are opinionated defaults with support and documentation, not mandatory molds for every application. Define which workloads, tenants, regions, data classes, and lifecycle stages the platform serves. Write non-goals so the team does not absorb every infrastructure request.

Networking includes service discovery, north-south entry, east-west communication, DNS, egress, network policy, and authenticated application transport. Gateway API supports role-oriented ownership of shared gateways, listeners, and routes. NetworkPolicy limits supported network paths but does not encrypt or authenticate a peer. If service identity is required, combine connectivity policy with TLS or mTLS and plan certificate issuance, rotation, expiry, revocation, and bypass testing.

Storage design includes claim interfaces, StorageClasses, topology, access modes, expansion, snapshots, backup, restore, encryption, reclaim, and deletion. A self-service storage request must communicate when capacity is pending or restoration failed. Deleting a namespace does not necessarily erase retained volumes, snapshots, or provider backups. Test the entire lifecycle with synthetic data.

Compute and cost are reliability concerns. Requests influence scheduling; limits constrain runtime use; ResourceQuota constrains aggregate tenant consumption; autoscaling changes workload or infrastructure supply. None works in isolation. If HPA adds replicas that cannot schedule, inspect requests, quota, affinity, taints, topology, and node capacity. Keep failure headroom instead of optimizing utilization to 100%.

Multi-tenancy is a set of choices. Namespaces scope many resources but share a control plane and usually nodes. Higher-risk or regulated tenants may need dedicated nodes or clusters. Define trust, data, availability, noisy-neighbor, upgrade, and incident boundaries. Apply layered identity, RBAC, quotas, Pod security, network, storage, placement, and audit controls, and verify them with denied-path tests.

Domain 2: GitOps and continuous delivery

OpenGitOps describes systems whose desired state is declarative, versioned and immutable, pulled automatically, and continuously reconciled. GitOps is not merely keeping YAML in Git. A reconciler observes differences and converges live state. Manual emergency edits should be visible as drift; an organization must decide whether policy reverts them immediately or allows a controlled adoption workflow.

Separate application source, build output, and deployment configuration. CI should test reviewed source, build once, produce an immutable digest, and attach evidence such as an SBOM, vulnerability report, signature, and provenance. Environment promotion should update the desired digest rather than rebuild. A signature establishes integrity under an identity or key; authorization still requires the expected signer, issuer or trust root, subject digest, source, builder, and policy.

Reconciliation authority should be narrow. The controller often needs read-only access to desired-state repositories and write access only to approved cluster scopes. Do not reuse a human administrator identity. Protect bootstrap configuration and secrets because a disaster-recovery claim is incomplete unless the team can recreate trusted controllers, credentials, admission dependencies, external services, and data in a tested order.

Progressive delivery limits exposure. Canary delivery sends controlled traffic to a candidate and uses analysis to promote or abort. Blue-green delivery prepares a preview and switches active traffic. Both require health and service-level evidence, explicit behavior when metrics are absent or inconclusive, capacity for overlap, and tested rollback. Data changes may make binary rollback unsafe; use backward-compatible expand-and-contract migrations.

Domain 3: platform APIs and self-service

A platform API is a contract, not an implementation leak. A developer might request an environment with owner, tier, route, storage profile, and expiry rather than constructing a dozen low-level resources. A CRD can make that contract native to Kubernetes. Its schema should validate required values, ranges, enums, immutability, and compatibility. Status should expose observed generation and structured conditions such as Ready, Progressing, Degraded, and PolicyBlocked.

A controller repeatedly reconciles observed state toward desired state. It must be idempotent because events can be duplicated, coalesced, or retried and the process can restart. Child resources should use valid ownership where appropriate. External resources require durable identifiers and explicit deletion semantics. Finalizers can hold deletion until cleanup completes, but a finalizer without timeout, status, retry safety, and recovery guidance can deadlock objects forever.

Version APIs before broad adoption. Serve explicit versions, convert between them, choose a storage version, preserve compatible meaning, migrate objects, publish deprecation windows, and test older clients. Changing a field's meaning in place is operationally cheap today and expensive for every consumer tomorrow.

Self-service interfaces can be Backstage templates, portals, command-line tools, or direct APIs. A template can scaffold repositories and register components, but it is not a continuous reconciler. Never make the user interface the only validation or authorization boundary. Direct clients must receive the same schema, admission, RBAC, quota, and policy outcomes.

Measure the product. Time from accepted request to Ready, success and failure by bounded reason, pending age, abandonment, support contacts, and adoption reveal more than the number of resources created. Interview users and preserve an extension path. A golden path that blocks justified workloads drives shadow infrastructure rather than adoption.

Domain 4: observability and operations

Operate the platform through user-visible outcomes and internal convergence. A provisioning SLI can measure elapsed time from a valid accepted request to a current Ready condition. Delivery SLIs can cover successful promotion and rollback. Runtime SLOs can cover request success and latency. Infrastructure signals explain causes but should not replace outcome measures.

Instrument controllers with reconciliation duration and errors, retry count, queue depth, age of oldest work, dependency latency, API throttling, and observed-generation lag. Use structured logs with resource identity, generation, reason, and error class while excluding full secrets and large custom resources. Traces can connect a request across portal, API, controller, provider, and status update.

Alert on sustained impact or imminent exhaustion, not every low-level event. A single Pod restart during rollout is useful context, not necessarily a page. A runbook should state impact, owner, evidence queries, safe actions, stop conditions, escalation, rollback, and recovery validation. Track observability-pipeline health so missing or stale evidence does not appear green.

Delivery performance measures should be interpreted together. Faster lead time and higher deployment frequency are not successes if change failures rise or recovery becomes slower. Avoid volume metrics such as commit count as goals. For incidents, preserve a timeline from source revision and artifact digest through rollout, policy, metrics, logs, traces, events, and audit.

Disaster recovery includes more than Kubernetes objects. Test identity and key restoration, DNS, registry, external databases, storage and backups, controller ordering, admission dependencies, traffic switching, and complete user journeys. Record measured recovery objectives and gaps rather than claiming readiness from an untested document.

Domain 5: security and policy enforcement

RBAC grants should match actual controller and user responsibilities. Avoid routine cluster-admin, system:masters, wildcard permissions, and shared kubeconfigs. Test both permitted and denied paths. Remember transitive authority: creating workloads, bindings, tokens, certificates, or admission configuration can be more powerful than a direct read permission suggests.

Admission can enforce workload and artifact rules before persistence. Built-in Pod Security Admission addresses standardized workload hardening; validating policies and policy engines can express broader organization rules. Mutation precedes validation, so validate the final object. Webhooks add network, certificate, latency, availability, and upgrade risks. Set narrow matching, bounded timeouts, deliberate failure behavior, monitoring, redundancy, and an audited emergency path.

Supply-chain policy should bind one digest to expected source, builder, signer, provenance, SBOM, scan, and exception evidence. An SBOM inventories components. A scan reports known findings under a particular database and time. Provenance describes how an artifact was produced. A signature protects identity and integrity. None alone proves safe behavior.

Policy rollout should begin with tests, then audit, canary enforcement, monitoring, and expansion. Test valid, invalid, boundary, mutation, old-version, timeout, certificate, and outage cases. Exceptions need exact scope, owner, rationale, approval, compensating controls, expiry, and review trigger. A compliance report must distinguish pass, fail, exception, stale, unknown, provider-managed, and not applicable.

Performance-based preparation

Practice complete tasks rather than isolated commands. Read the requested outcome and verification criteria first. Confirm the cluster context, namespace, repository, and current object state. Inspect existing configuration before editing. Make the smallest change that satisfies the outcome, then validate positive and negative behavior. Preserve diagnostic evidence when a task fails, and avoid spending the entire session perfecting one low-value detail.

Build muscle memory around YAML navigation, Kubernetes discovery, logs, events, conditions, RBAC checks, rollout state, Git diffs, and documentation lookup. Exact tools available in the exam are defined by current official instructions; do not assume the lab environment matches a personal distribution. Practice with more than one implementation where the objective is conceptual, but learn the exam tool list directly from official documents.

Use a ten-week plan: two weeks architecture; two weeks GitOps and delivery; two weeks APIs and controllers; two weeks operations; and two weeks security plus timed integration. After every lab, record what failed, the evidence that exposed it, the safe recovery, and the cleanup. A command that happened to work once is weaker evidence than a repeatable workflow with verification.

Three portfolio projects

The self-service platform API project creates a versioned CRD, idempotent controller, portal template, routing, quotas, policy, status, SLOs, and lifecycle tests. The GitOps progressive-delivery project builds one digest, verifies evidence, promotes desired state, runs canary and blue-green analysis, and tests rollback and disaster recovery. The multi-tenant operations project combines architecture, secure connectivity, policy, telemetry, capacity, incident response, cost, and complete restoration.

Each project uses synthetic data and disposable resources. Include architecture decisions, trust boundaries, source and configuration, allowed and denied tests, failure injection, cost, evidence, limitations, cleanup, concise resume bullets, and interview narratives. Do not claim production scale or compliance from a lab.

Readiness checklist

• Explain why a platform is a product and name its users, contracts, support, and outcomes.
• Choose network, storage, compute, tenancy, topology, and cost controls for a scenario.
• Trace source to digest, desired state, reconciliation, admission, rollout, and recovery.
• Implement and explain CRD schema, status, conditions, reconciliation, ownership, finalizers, and versioning.
• Distinguish scaffolding, workflow automation, composition, and continuous reconciliation.
• Define platform SLIs and diagnose controllers, dependencies, policies, and telemetry pipelines.
• Apply least privilege, authenticated communication, artifact verification, admission, audit, and exception governance.
• Complete tasks under time limits and verify both successful and denied outcomes.

Continue learning

Official references

• Linux Foundation CNPE certification
• CNCF public curriculum repository
• CNCF Platforms White Paper
• OpenGitOps principles
• Kubernetes documentation
• Gateway API documentation
• Backstage Software Templates
• Crossplane Compositions
• Argo Rollouts documentation
• SLSA specification