The current Kubernetes and Cloud Native Associate blueprint is easier to remember when its four domains are treated as one operating model rather than four study folders. Kubernetes Fundamentals accounts for 44% of the exam, Container Orchestration 28%, Cloud Native Application Delivery 16%, and Cloud Native Architecture 12%. Those weights describe a progression: understand the platform first, then how workloads are orchestrated, then how applications are delivered, and finally how the wider cloud-native ecosystem observes and supports them.<\/p>\n
The current KCNA<\/a> remains a beginner-level, online, proctored multiple-choice exam with no prerequisites. Linux Foundation gives candidates 90 minutes, a 12-month eligibility period, one retake, and a two-year certification validity period. The map below focuses on the relationships the exam expects rather than command memorization.<\/p>\n The 44% Fundamentals domain includes Kubernetes core concepts, administration, scheduling, and containerization. Start with the cluster as a control system: the control plane stores and reconciles desired state, while worker nodes run the containers that make up applications.<\/p>\n A Kubernetes cluster<\/a> makes more sense when every component is connected to a control loop. Users submit desired state, controllers compare it with observed state, the scheduler assigns work, and node-level components keep workloads running.<\/p>\n Containers package application code and dependencies into portable runtime units. Images are immutable artifacts; running containers are instances of those images. Kubernetes then groups one or more containers into pods, which become the smallest schedulable workload unit.<\/p>\n A containers-versus-virtual-machines<\/a> comparison helps clarify why containers share more of the host operating system while VMs include a fuller guest OS boundary. KCNA expects conceptual understanding of that difference rather than hypervisor administration.<\/p>\n A pod can disappear and be recreated, so production applications normally rely on controllers such as Deployments to maintain a desired replica count. Services then provide stable network access to changing pod sets.<\/p>\n This relationship is fundamental: pods are disposable, controllers maintain desired state, and Services decouple clients from ephemeral pod addresses. If you can explain that chain clearly, many basic Kubernetes questions become easier.<\/p>\n The scheduler considers whether nodes can satisfy workload requirements. CPU and memory requests, policies, labels, taints or other constraints can influence placement. KCNA does not require advanced scheduler tuning, but candidates should understand why a pod can remain Pending when no node can satisfy its needs.<\/p>\n Scheduling therefore links the abstract desired state with physical or virtual compute resources. The platform cannot create capacity that does not exist.<\/p>\n The 28% orchestration domain explains what a running application needs after basic scheduling. Networking allows pods and services to communicate. Storage preserves state beyond one pod’s lifetime. Security limits access and protects workloads. Troubleshooting identifies which layer is preventing the desired behavior.<\/p>\n A useful Kubernetes foundation<\/a> is to think in dependencies: container image \u2192 pod \u2192 controller \u2192 Service\/network \u2192 storage\/configuration \u2192 user-facing application.<\/p>\n Pods receive network identities, but those identities are not reliable long-term service endpoints because pods can be replaced. Services and cluster DNS provide stable discovery. Ingress or gateway-style components can expose services from outside the cluster.<\/p>\n When a cloud-native application is unreachable, the skills map should separate pod health, Service selection, DNS\/service discovery, network policy, and external ingress rather than treating \u201cnetworking\u201d as one opaque problem.<\/p>\n Container filesystems are typically tied to the container or pod lifecycle. Persistent storage concepts allow important data to survive replacement and rescheduling. PersistentVolume and claim-style abstractions separate the application’s storage request from the underlying implementation.<\/p>\n This is one of the clearest cloud-native ideas: workloads can be recreated while durable data continues independently.<\/p>\n The 16% Cloud Native Application Delivery domain covers application delivery and debugging. Declarative manifests describe desired resources, while package-management tools can organize larger groups of manifests. GitOps-style workflows extend that idea by keeping desired state under version control and reconciling the cluster automatically.<\/p>\n Helm<\/a> is a useful example of Kubernetes packaging. KCNA needs the purpose\u2014repeatable, parameterized application deployment\u2014more than advanced template authoring.<\/p>\n The current 12% Architecture domain includes observability, ecosystem and principles, and community\/collaboration. Observability combines metrics, logs, and traces so teams can understand dynamic systems whose individual pods may be short-lived.<\/p>\nKubernetes Fundamentals sits at the center of the map<\/h3>\n
Containers are the unit Kubernetes orchestrates<\/h3>\n
Pods, controllers, and Services form the basic workload path<\/h3>\n
Scheduling connects desired workloads with real node capacity<\/h3>\n
Container Orchestration adds networking, storage, security and troubleshooting<\/h3>\n
Networking is about stable communication despite ephemeral workloads<\/h3>\n
Storage separates application lifecycle from data lifecycle<\/h3>\n
Application Delivery connects manifests, packages and debugging<\/h3>\n
Cloud Native Architecture places observability in the wider ecosystem<\/h3>\n