CNPA

CNPA Exam Details

Domain Weight Breakdown

About the CNPA Certification

The Cloud Native Platform Administrator (CNPA) certification validates that a candidate possesses the skills to administer, maintain, and operate cloud native platforms built on Kubernetes. This is a professional-level certification from the Linux Foundation that goes beyond basic Kubernetes administration to cover the entire platform stack including multi-cluster management, platform networking with service meshes, advanced security postures, and comprehensive observability. The CNPA targets platform engineers and administrators who are responsible for building and maintaining the internal developer platform (IDP) that application teams rely on.

Unlike the CKA which focuses on individual cluster administration, the CNPA emphasizes the holistic platform view: how to design, deploy, and operate a production-grade cloud native platform that spans multiple clusters, environments, and teams. Candidates should have strong hands-on experience with Kubernetes, container runtimes, CNI plugins, GitOps workflows, and infrastructure-as-code tooling before attempting this exam.

Exam Tips

The CNPA is a performance-based exam meaning you will work in real terminal environments. Practice kubectl commands extensively and know how to troubleshoot cluster issues from the command line. Time management is critical since you have 120 minutes for approximately 60 tasks. Focus on high-weight domains like Platform Architecture, Cluster Lifecycle, and Platform Security which together account for 60% of the exam. Use the Kubernetes documentation efficiently during the exam as it is an open-book test with access to official docs.

Kubernetes Architecture Overview

Multi-Cluster Architecture Patterns

Tools like Cluster API (CAPI), Rancher, and ArgoCD/Flux enable multi-cluster lifecycle management. Cluster API provides declarative, Kubernetes-style APIs for cluster creation, configuration, and management across infrastructure providers.

Infrastructure as Code (IaC) for Platforms

GitOps Principles & Tooling

GitOps is a paradigm where Git repositories serve as the single source of truth for declarative infrastructure and application definitions. Changes are made via pull requests, automatically reconciled by controllers running in the cluster. The four principles are: declarative configuration, version-controlled in Git, automatically applied, and continuously reconciled.

Exam tip: Understand the difference between push-based CI/CD (Jenkins pushing to cluster) and pull-based GitOps (controllers pulling desired state from Git). GitOps offers better auditability, drift detection, and self-healing capabilities.

Container Runtime Interface (CRI)

The CRI is the plugin interface that enables the kubelet to use different container runtimes without recompiling. After Docker shim removal in Kubernetes v1.24, the supported runtimes are containerd (most popular, CNCF graduated) and CRI-O (lightweight, OCI-compliant, popular in OpenShift). Both use runc as the low-level OCI runtime by default but can be swapped for sandboxed runtimes like gVisor (runsc) or Kata Containers for workload isolation. RuntimeClass resources allow specifying which runtime handler a pod should use.

Cluster Bootstrap Methods

kubeadm Cluster Operations

Kubernetes Upgrade Process

Kubernetes follows a minor version skew policy: kubelet can be at most one minor version behind the API server, and kubectl can be within one minor version (newer or older). Upgrades should be performed one minor version at a time (e.g., 1.28 to 1.29, not 1.28 to 1.30). Always upgrade control plane nodes first, then worker nodes.

etcd Backup & Restore

etcd stores all cluster state. Regular backups are essential for disaster recovery. The etcd snapshot mechanism creates a point-in-time backup of the entire key-value store. Always verify backup integrity before relying on it for recovery.

Exam tip: After restoring etcd, update the etcd static pod manifest to point to the new data directory. Remember the certificate file paths are found in the etcd pod manifest at /etc/kubernetes/manifests/etcd.yaml.

Node Lifecycle & Maintenance

Pod Disruption Budgets (PDBs) protect applications during voluntary disruptions like node drains. A PDB specifies minAvailable or maxUnavailable to ensure a minimum number of replicas stay running during maintenance operations. Always create PDBs for critical workloads before performing rolling upgrades.

High Availability (HA) Control Plane

A production HA cluster requires at least 3 control plane nodes (odd number for etcd quorum) behind a load balancer. The stacked etcd topology runs etcd on each control plane node, while the external etcd topology runs a separate etcd cluster. Stacked is simpler to set up; external provides better resilience. The load balancer distributes API server traffic and provides a stable endpoint for kubelet and kubectl connections.

Kubernetes Networking Model

Kubernetes imposes a flat networking model with three fundamental requirements: every pod gets its own unique IP address, pods on any node can communicate with all other pods on any node without NAT, and agents on a node can communicate with all pods on that node. The Container Network Interface (CNI) is the standard for network plugins that implement this model.

Service Types & DNS

CoreDNS provides cluster DNS. Service DNS format: <service>.<namespace>.svc.cluster.local. Pod DNS: <pod-ip-dashed>.<namespace>.pod.cluster.local.

Ingress & Gateway API

Popular Ingress controllers include NGINX Ingress Controller, Traefik, HAProxy, and Contour. The Gateway API is the recommended path forward with implementations from Istio, Cilium, Contour, and NGINX.

Service Mesh Architecture

A service mesh provides a dedicated infrastructure layer for service-to-service communication. It handles mutual TLS (mTLS), traffic management, observability, and policy enforcement transparently through sidecar proxies (data plane) managed by a control plane.

Network Policies

NetworkPolicy resources control pod-to-pod traffic at L3/L4. By default, all pods can communicate freely. Once a NetworkPolicy selects a pod, all traffic not explicitly allowed is denied. Policies are additive (union of all matching policies). The CNI plugin must support NetworkPolicies (Calico, Cilium, Weave do; Flannel does not).

Exam tip: Always start with a default-deny policy per namespace, then create allow policies for required communication paths. This follows the principle of least privilege for network access.

Platform Security Essentials

Observability Pillars

OpenTelemetry (OTel) is the CNCF standard for generating, collecting, and exporting telemetry data (metrics, logs, traces). It provides vendor-neutral SDKs, auto-instrumentation agents, and the OpenTelemetry Collector for unified telemetry pipelines.

Prometheus Monitoring Stack

Prometheus is the CNCF graduated monitoring system. It uses a pull-based model, scraping metrics from HTTP endpoints (/metrics) at configured intervals. Metrics are stored in a local time-series database (TSDB). PromQL is the query language for aggregating and alerting on metrics.

Log Aggregation Architecture

In Kubernetes, logs are typically collected using a DaemonSet pattern where a log agent (Fluent Bit, Fluentd) runs on every node and tails container log files from /var/log/containers/. Logs are then forwarded to a centralized backend like Loki, Elasticsearch, or a cloud logging service. Fluent Bit is the lightweight forwarder while Fluentd is the heavier aggregator with more plugin support.

Troubleshooting Workflow

Common Pod Failure States

Exam tip: When troubleshooting, always check events first with kubectl describe. Events reveal the sequence of actions and failures. For node-level issues, check kubelet logs with journalctl -u kubelet on the node.

Kubernetes Storage Architecture

Kubernetes abstracts storage through the Container Storage Interface (CSI), allowing any storage provider to integrate with the cluster. The storage flow involves PersistentVolumeClaims (PVCs) requesting storage, which bind to PersistentVolumes (PVs) provisioned either statically by admins or dynamically via StorageClasses. CSI drivers run as DaemonSets (node plugin) and Deployments (controller plugin) in the cluster.

Access Modes & Reclaim Policies

CSI Drivers & Storage Providers

StatefulSets & Persistent Workloads

StatefulSets manage stateful applications with stable network identities and persistent storage. Each pod gets a predictable name (<statefulset-name>-<ordinal>) and its own PVC via volumeClaimTemplates. Pods are created and deleted in order (0, 1, 2...) and scaling respects this ordering. The headless Service provides stable DNS entries for each pod.

Important: Deleting a StatefulSet does NOT delete the associated PVCs. This is intentional to prevent data loss. PVCs must be manually deleted if the data is no longer needed.

Volume Snapshots & Data Protection

Volume snapshots provide point-in-time copies of persistent volumes for backup, migration, and cloning purposes. The snapshot workflow involves creating a VolumeSnapshotClass (defines the CSI driver), then a VolumeSnapshot referencing the source PVC. To restore, create a new PVC with dataSource pointing to the VolumeSnapshot.

Exam tip: Understand the complete backup and restore workflow with Velero: install Velero, create a BackupStorageLocation, run velero backup create, and velero restore create. Know the difference between volume snapshots (CSI-native) and file-level backups (Restic/Kopia).

Ephemeral Storage & ConfigMaps/Secrets

For production secrets management, avoid storing sensitive values as plain Kubernetes Secrets (base64-encoded, not encrypted at rest by default). Use External Secrets Operator to sync secrets from Vault, AWS Secrets Manager, or Azure Key Vault. Enable encryption at rest for etcd to protect Secrets stored in the cluster state.