Linux Foundation Intermediate

CNPA

Cloud Native Platform Administrator

The Cloud Native Platform Administrator (CNPA) certification validates the skills required to administer and operate cloud-native platforms built on Kubernetes and related CNCF technologies. This certification demonstrates the ability to manage production Kubernetes clusters, troubleshoot issues, and maintain platform reliability.

The exam covers five key domains: Kubernetes Cluster Administration (30%), Workload Management (25%), Networking (20%), Storage (15%), and Security and Access Control (10%). Candidates must demonstrate proficiency with cluster installation and configuration, node management, workload scheduling, troubleshooting deployments, configuring network policies and ingress, managing persistent volumes, implementing RBAC, and applying security best practices.

The CNPA exam consists of 60 multiple-choice questions administered online over 90 minutes, with a passing score of 75%. This certification is ideal for platform engineers, cluster administrators, DevOps engineers, and SREs responsible for managing Kubernetes infrastructure. The CNPA provides practical knowledge for day-to-day Kubernetes operations and complements other Kubernetes certifications.

Updated 2025 DevOps

Questions

Practice Tests

75%

Pass Score

Views

Total Attempts

Avg. Score

Pass Rate

Discussions

Practice Tests Flash Cards Exam Topics Cheat Sheet

€5.00

CNPA Practice Exam 1

Comprehensive 50-question practice exam covering Cloud Native Platform Administration including Kubernetes cluster administration, workload management, networking, storage, and security.

50 Q 90 minutes 70%

Test Drive

€5.00

CNPA Practice Exam 2

Intermediate 50-question practice exam covering cluster upgrades, HA control plane, resource quotas, StatefulSets, Ingress controllers, StorageClasses, NetworkPolicies, and pod security.

50 Q 90 minutes 70%

Test Drive

€5.00

CNPA Practice Exam 3

Advanced 50-question practice exam covering custom schedulers, priority and preemption, cluster autoscaler, advanced networking with Calico and Cilium, CSI drivers, volume snapshots, encryption at rest, audit policies, and OPA Gatekeeper.

50 Q 90 minutes 70%

Test Drive

€5.00

CNPA Practice Exam 4

Advanced 50-question practice exam covering certificate management, etcd compaction and defragmentation, control plane high availability with stacked and external etcd topologies, kubelet configuration, and container runtime configuration.

50 Q 90 minutes 70%

Test Drive

€5.00

CNPA Practice Exam 5

Advanced 50-question practice exam covering Gateway API, multi-cluster networking, service mesh technologies including Istio and Linkerd, eBPF networking with Cilium, and advanced Ingress configurations with path-based routing, TLS termination, and rate limiting.

50 Q 90 minutes 70%

Test Drive

€5.00

CNPA Practice Exam 6

Advanced 50-question practice exam covering CSI volume snapshots, volume cloning, storage capacity tracking, ReadWriteMany persistent volumes, encryption at rest with KMS providers, external secrets management, cert-manager for automated TLS certificates, and policy engines including OPA Gatekeeper and Kyverno.

50 Q 90 minutes 70%

Test Drive

Unlock All Content for CNPA

6 Practice Test(s) + Flash Cards — 3 months access

€39.99 €26.99 Save 30%

or included with Monthly subscription / Content Bundle

CNPA Cheat Sheet

Quick reference guide - 6 sections

Free Access

CNPA Exam Details

Detail	Value
Exam Code	CNPA
Full Name	Cloud Native Platform Administrator
Duration	120 minutes
Number of Questions	~60 performance-based tasks and multiple-choice
Passing Score	66%
Question Format	Performance-based (hands-on labs) and multiple choice
Exam Fee	$395 USD (includes one free retake)
Certification Level	Administrator (Professional)
Validity	3 years
Proctoring	Online proctored via PSI

Domain Weight Breakdown

Domain	Weight
1. Platform Architecture & Design	20%
2. Cluster Lifecycle Management	20%
3. Platform Networking	15%
4. Platform Security	20%
5. Observability & Troubleshooting	15%
6. Platform Storage & Data Management	10%

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

Component	Plane	Function
kube-apiserver	Control	Front-end for the Kubernetes API; all components communicate through it; handles REST operations and validation
etcd	Control	Distributed key-value store that persists all cluster state; must be backed up regularly for disaster recovery
kube-scheduler	Control	Assigns pods to nodes based on resource requests, taints/tolerations, affinity rules, and topology constraints
kube-controller-manager	Control	Runs reconciliation loops: Node, ReplicaSet, Deployment, Job, ServiceAccount controllers among others
cloud-controller-manager	Control	Manages cloud-provider-specific resources (load balancers, storage volumes, node lifecycle in cloud)
kubelet	Worker	Node agent; ensures containers described in PodSpecs are running and healthy on the node
kube-proxy	Worker	Network proxy maintaining iptables/IPVS rules for Service abstraction and load balancing
Container Runtime	Worker	Runs containers (containerd, CRI-O); communicates with kubelet via CRI (Container Runtime Interface)

Multi-Cluster Architecture Patterns

Pattern	Description	Use Case
Hub-and-Spoke	Central management cluster (hub) manages workload clusters (spokes)	Enterprise multi-team, multi-environment management
Federation	Multiple clusters share workload distribution and state via federation controllers	Geographic distribution, high availability across regions
Standalone	Independent clusters per environment or team with separate management	Isolation requirements, regulatory compliance
Virtual Clusters (vCluster)	Lightweight virtual clusters running inside a host cluster sharing resources	Dev/test environments, multi-tenancy with isolation

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

Tool	Type	Purpose
Terraform / OpenTofu	Declarative IaC	Provision infrastructure (VMs, networks, managed K8s clusters)
Crossplane	Kubernetes-native IaC	Provision cloud resources using Kubernetes CRDs and controllers
Cluster API	Cluster provisioner	Declaratively manage Kubernetes cluster lifecycle via K8s API
Ansible	Configuration management	Automate OS-level config, package installs, kubeadm bootstrap
Pulumi	Programmatic IaC	Infrastructure provisioning using general-purpose languages

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.

Tool	Approach	Key Features
ArgoCD	Pull-based	Web UI, multi-cluster support, Application CRD, SSO integration, RBAC
Flux	Pull-based	CNCF graduated, GitRepository/Kustomization CRDs, Helm support

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

Method	Description	Best For
kubeadm	Official Kubernetes tool for bootstrapping clusters; handles init, join, upgrade, and reset	Bare-metal, VMs, learning environments
Cluster API (CAPI)	Declarative cluster lifecycle management using Kubernetes CRDs from a management cluster	Production multi-cluster at scale
Managed Kubernetes (EKS/GKE/AKS)	Cloud provider manages control plane; you manage worker nodes or use managed node pools	Reduced operational overhead
k3s / k0s	Lightweight Kubernetes distributions packaged as single binaries	Edge computing, IoT, resource-constrained environments
Rancher / OpenShift	Enterprise Kubernetes platforms with UI, multi-cluster management, built-in security	Enterprise environments, compliance-driven orgs

kubeadm Cluster Operations

# Initialize a new control plane node

sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint=lb.example.com:6443

# Join a worker node

sudo kubeadm join lb.example.com:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

# Join additional control plane node

sudo kubeadm join lb.example.com:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash> --control-plane

# Generate a new join token

kubeadm token create --print-join-command

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.

# Step 1: Upgrade kubeadm on control plane

sudo apt-get update && sudo apt-get install -y kubeadm=1.29.0-1.1

# Step 2: Plan and apply the upgrade

sudo kubeadm upgrade plan

sudo kubeadm upgrade apply v1.29.0

# Step 3: Drain node, upgrade kubelet & kubectl, uncordon

kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

sudo apt-get install -y kubelet=1.29.0-1.1 kubectl=1.29.0-1.1

sudo systemctl daemon-reload && sudo systemctl restart kubelet

kubectl uncordon <node>

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.

# Create an etcd snapshot

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \

--endpoints=https://127.0.0.1:2379 \

--cacert=/etc/kubernetes/pki/etcd/ca.crt \

--cert=/etc/kubernetes/pki/etcd/server.crt \

--key=/etc/kubernetes/pki/etcd/server.key

# Verify the snapshot

ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-table

# Restore from snapshot

ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir=/var/lib/etcd-restored

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

Operation	Command	Description
Cordon	kubectl cordon <node>	Marks node as unschedulable; existing pods remain
Drain	kubectl drain <node> --ignore-daemonsets	Evicts pods and cordons node for maintenance
Uncordon	kubectl uncordon <node>	Returns node to schedulable state after maintenance
Taint	kubectl taint nodes <node> key=val:NoSchedule	Prevents pods without matching tolerations from scheduling
Label	kubectl label nodes <node> env=prod	Adds metadata for node selectors and affinity rules

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.

CNI Plugin	Overlay	Key Features
Calico	VXLAN or BGP (no overlay)	Network policies, BGP peering, eBPF dataplane, most popular
Cilium	VXLAN/Geneve or native routing	eBPF-based, L7 policies, service mesh, Hubble observability
Flannel	VXLAN	Simple L3 overlay, no native network policy support
Weave Net	VXLAN (encrypted optional)	Easy setup, built-in encryption, network policies
Multus	Meta-plugin	Attaches multiple network interfaces to pods (SR-IOV, MACVLAN)

Service Types & DNS

Service Type	Description	Use Case
ClusterIP	Virtual IP accessible only within the cluster (default)	Internal microservice communication
NodePort	Exposes service on a static port (30000-32767) on every node	Development, testing
LoadBalancer	Provisions external load balancer from cloud provider	Production external traffic on cloud
ExternalName	Maps service to a DNS CNAME record	External service aliasing
Headless (ClusterIP: None)	No ClusterIP; DNS returns pod IPs directly	StatefulSets, direct pod discovery

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

Ingress & Gateway API

Feature	Ingress	Gateway API
Status	Stable, widely adopted	GA (graduated), next generation
Protocol Support	HTTP/HTTPS	HTTP, HTTPS, TCP, UDP, gRPC, TLS
Role Separation	Single resource, one persona	GatewayClass/Gateway/Route split across infra and app teams
Traffic Splitting	Controller-specific annotations	Native weight-based routing in HTTPRoute
Header Matching	Annotation-dependent	Native header/query parameter matching

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.

Mesh	Data Plane	Key Features
Istio	Envoy sidecar or Ambient (ztunnel)	mTLS, traffic management, telemetry, authorization policies
Linkerd	linkerd2-proxy (Rust)	Lightweight, automatic mTLS, low resource overhead
Cilium Service Mesh	eBPF (sidecar-free)	Kernel-level networking, no sidecars, L7 visibility

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).

# Default deny all ingress in a namespace

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-ingress

spec:

podSelector: {}

policyTypes: [Ingress]

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

Security Layer	Mechanism	Description
Authentication	X.509 certs, OIDC tokens, ServiceAccounts	Verifying identity of users and workloads
Authorization	RBAC (Role/ClusterRole + Bindings)	Controlling what authenticated entities can do
Admission Control	Validating/Mutating webhooks, OPA/Gatekeeper, Kyverno	Enforcing policies on resource creation/modification
Pod Security	Pod Security Standards (Privileged/Baseline/Restricted)	Restricting pod security contexts at namespace level
Secrets Management	External Secrets Operator, Sealed Secrets, Vault	Secure storage and injection of sensitive data
Image Security	Image signing (Cosign/Sigstore), scanning (Trivy, Grype)	Verifying container image integrity and vulnerabilities
Runtime Security	Falco, Seccomp, AppArmor, SELinux	Detecting and preventing runtime anomalies

Observability Pillars

Pillar	Purpose	Tools
Metrics	Numeric time-series data measuring system behavior (CPU, memory, request rates, error rates)	Prometheus, Thanos, Cortex, Grafana Mimir
Logs	Timestamped text records of discrete events; structured (JSON) or unstructured	Fluentd, Fluent Bit, Grafana Loki, ELK Stack
Traces	End-to-end request paths across distributed services with timing and context	Jaeger, Zipkin, Tempo, OpenTelemetry

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.

Component	Function
Prometheus Server	Scrapes and stores metrics, evaluates alerting rules
Alertmanager	Receives alerts from Prometheus, handles dedup, grouping, routing, silencing
Grafana	Visualization dashboards; queries Prometheus via PromQL
Exporters	Expose metrics from third-party systems (node_exporter, kube-state-metrics)
ServiceMonitor / PodMonitor	CRDs for Prometheus Operator to auto-discover scrape targets

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.

Tool	Role	Key Feature
Fluent Bit	Log forwarder (DaemonSet)	Low memory footprint (~450KB), fast, C-based
Fluentd	Log aggregator	Rich plugin ecosystem (700+), Ruby-based
Grafana Loki	Log backend	Label-indexed (not full-text), cost-effective, LogQL
Elasticsearch	Log backend	Full-text search, powerful but resource-heavy

Troubleshooting Workflow

# Check pod status and events

kubectl get pods -n <namespace> -o wide

kubectl describe pod <pod-name> -n <namespace>

# View container logs

kubectl logs <pod-name> -n <namespace> --previous

kubectl logs <pod-name> -c <container> -n <namespace>

# Debug with ephemeral container

kubectl debug -it <pod-name> --image=busybox --target=<container>

# Check node conditions and events

kubectl describe node <node-name>

# Check component health

kubectl get componentstatuses

kubectl get events --sort-by='.lastTimestamp' -n <namespace>

Common Pod Failure States

Status	Cause	Resolution
ImagePullBackOff	Image not found, wrong tag, auth failure	Verify image name/tag; check imagePullSecrets
CrashLoopBackOff	Container starts and exits repeatedly	Check logs; verify command, entrypoint, configs
Pending	Insufficient resources, unmet scheduling constraints	Check node resources, taints, affinity, PVC binding
OOMKilled	Container exceeded memory limit	Increase memory limit or optimize application memory
CreateContainerConfigError	Missing ConfigMap, Secret, or env reference	Verify referenced ConfigMaps/Secrets exist
Init:Error / Init:CrashLoopBackOff	Init container failing	Check init container logs and dependencies

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.

Resource	Scope	Purpose
StorageClass	Cluster-wide	Defines provisioner, parameters, reclaim policy, volume binding mode
PersistentVolume (PV)	Cluster-wide	Represents actual storage resource (NFS, EBS, Ceph RBD, local)
PersistentVolumeClaim (PVC)	Namespaced	User request for storage; binds to a matching PV
VolumeSnapshot	Namespaced	Point-in-time copy of a volume for backup or cloning
VolumeSnapshotClass	Cluster-wide	Defines snapshot provisioner and parameters

Access Modes & Reclaim Policies

Access Mode	Abbreviation	Description
ReadWriteOnce	RWO	Volume mounted as read-write by a single node
ReadOnlyMany	ROX	Volume mounted as read-only by many nodes
ReadWriteMany	RWX	Volume mounted as read-write by many nodes (NFS, CephFS)
ReadWriteOncePod	RWOP	Volume mounted as read-write by a single pod (K8s 1.27+)

Reclaim Policy	Behavior
Retain	PV is kept after PVC deletion; admin must manually reclaim
Delete	PV and underlying storage are deleted when PVC is deleted (default for dynamic provisioning)
Recycle (deprecated)	Basic scrub (rm -rf) before making PV available again

CSI Drivers & Storage Providers

Provider	CSI Driver	Access Modes	Use Case
AWS EBS	ebs.csi.aws.com	RWO	Block storage for single-node workloads
AWS EFS	efs.csi.aws.com	RWX	Shared file storage across pods/nodes
Ceph RBD	rbd.csi.ceph.com	RWO	Block storage on Ceph clusters
CephFS	cephfs.csi.ceph.com	RWX	Shared filesystem on Ceph clusters
Longhorn	driver.longhorn.io	RWO, RWX	Cloud-native distributed block storage for K8s
Rook-Ceph	rook-ceph.csi	RWO, RWX	Kubernetes operator for Ceph storage orchestration
Local Path	rancher.io/local-path	RWO	Development and edge environments

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.

# StatefulSet pod DNS pattern

<pod-name>.<headless-svc>.<namespace>.svc.cluster.local

# Example: mysql-0.mysql-headless.default.svc.cluster.local

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.

Backup Tool	Method	Features
Velero	K8s resource backup + CSI snapshots or Restic/Kopia	Cluster migration, disaster recovery, scheduled backups
Kasten K10	Application-centric backup with policies	Enterprise data management, compliance, multi-cluster
Stash / KubeStash	Restic-based volume backup	Automated backups to S3/GCS/Azure, database-aware

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

Volume Type	Lifecycle	Use Case
emptyDir	Pod lifetime	Scratch space, cache, shared data between containers in a pod
configMap	Independent	Mount config files as volumes or inject as environment variables
secret	Independent	Sensitive data (passwords, tokens, TLS certs) mounted or injected
projected	Pod lifetime	Combines multiple sources (secrets, configMaps, downwardAPI, serviceAccountToken)
hostPath	Node lifetime	Access node filesystem (use cautiously, security risk)

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.

CNPA

Cloud Native Platform Administrator

CNPA Practice Exam 1

CNPA Practice Exam 2

CNPA Practice Exam 3

CNPA Practice Exam 4

CNPA Practice Exam 5

CNPA Practice Exam 6

Unlock All Content for CNPA

Preview (10 / 120)

Flash Cards

Available Languages

Exam Topics

CNPA Cheat Sheet

CNPA Exam Details

Domain Weight Breakdown

About the CNPA Certification

Exam Tips

Kubernetes Architecture Overview

Multi-Cluster Architecture Patterns

Infrastructure as Code (IaC) for Platforms

GitOps Principles & Tooling

Container Runtime Interface (CRI)

Cluster Bootstrap Methods

kubeadm Cluster Operations

Kubernetes Upgrade Process

etcd Backup & Restore

Node Lifecycle & Maintenance

High Availability (HA) Control Plane

Kubernetes Networking Model

Service Types & DNS

Ingress & Gateway API

Service Mesh Architecture

Network Policies

Platform Security Essentials

Observability Pillars

Prometheus Monitoring Stack

Log Aggregation Architecture

Troubleshooting Workflow

Common Pod Failure States

Kubernetes Storage Architecture

Access Modes & Reclaim Policies

CSI Drivers & Storage Providers

StatefulSets & Persistent Workloads

Volume Snapshots & Data Protection

Ephemeral Storage & ConfigMaps/Secrets