The Kubernetes and Cloud Native Associate (KCNA) is the Linux Foundation and CNCF’s beginner-level, vendor-neutral certification for foundational Kubernetes and cloud-native knowledge. The current KCNA exam is an online, proctored, multiple-choice assessment with a 90-minute duration, one retake, 12-month exam eligibility and a two-year certification validity period. There are no exam prerequisites.
The current domain weights are Kubernetes Fundamentals at 44%, Container Orchestration at 28%, Cloud Native Application Delivery at 16%, and Cloud Native Architecture at 12%. Linux Foundation updated the competency structure so observability now sits under Cloud Native Architecture.
Kubernetes Fundamentals dominates the blueprint at 44%
This domain covers Kubernetes core concepts, administration, scheduling and containerization. Candidates should understand clusters, control plane and worker nodes, pods, deployments/workloads, services, namespaces, configuration and how basic scheduling places workloads onto nodes.
A Kubernetes foundation is more useful than memorizing command flags because KCNA is conceptual and multiple choice.
Containers are the workload unit beneath orchestration
KCNA expects candidates to understand why containers package applications differently from traditional virtual machines and how images become running workloads.
A containers-versus-VMs comparison can help clarify isolation, resource sharing, portability and deployment characteristics.
Cluster architecture connects components into one control system
The control plane maintains desired state and cluster decisions, while worker nodes run workloads. Controllers continually reconcile observed and desired state.
A Kubernetes cluster model should make pods, nodes, scheduling and services part of one system rather than separate terms.
Container Orchestration is 28%
The second domain covers networking, security, troubleshooting and storage. Candidates should understand how workloads communicate, how services expose applications, how persistent data is handled and how basic security controls limit access.
KCNA does not require CKA-level command-line administration, but operational concepts must be clear enough to choose the right component in a scenario.
Networking includes service discovery and workload connectivity
Pods receive network identities, services provide stable access to changing pod sets, DNS/service discovery helps workloads locate one another and ingress/gateway-style components can expose applications externally.
Networking questions should be solved by identifying which layer provides pod-to-pod, service, or external connectivity.
Security is foundational rather than specialist depth
KCNA security includes cloud-native principles, identity/authorization context, secrets/configuration awareness, workload isolation and secure supply-chain concepts at an introductory level.
A Kubernetes security overview is useful when it is kept at associate depth rather than turning preparation into KCSA/CKS material.
Storage distinguishes ephemeral from persistent workload state
Containers and pods can be replaced, so state that must survive requires persistent storage concepts. Candidates should understand volumes, persistent-volume ideas and why stateful workloads have different needs from stateless deployments.
The durable concept is decoupling application lifecycle from persistent data lifecycle.
Cloud Native Application Delivery is 16%
This domain covers application delivery and debugging. Candidates should understand declarative deployment, configuration, rolling change, package-management concepts and how teams debug cloud-native applications.
A Helm introduction can provide context for packaging and repeatable application delivery without requiring chart-authoring expertise.
Cloud Native Architecture is 12%
The final domain includes observability, cloud-native ecosystem and principles, plus cloud-native community and collaboration. Candidates should understand why metrics, logs and traces matter and how open-source CNCF projects fit around Kubernetes.
The Prometheus and Grafana ecosystem is a useful observability example because it connects metrics collection with visualization.
KCNA is a conceptual stepping stone
Linux Foundation positions KCNA as an associate credential for people advancing toward deeper Kubernetes or cloud-native roles. The certification page points candidates next toward KCSA for security or CKA for administration.
KCNA’s current exam structure was updated after Linux Foundation moved observability into Cloud Native Architecture while keeping the four-domain model. Candidates using older notes should check where topics now belong even when the underlying concepts have not changed.
The certification is deliberately vendor-neutral. Kubernetes may run on managed services from AWS, Azure or Google Cloud, on premises or elsewhere, but KCNA focuses on portable concepts: desired state, orchestration, services, storage, security, delivery and ecosystem.
Core Kubernetes objects should be studied relationally. Pods run containers, controllers such as Deployments maintain desired replica state, Services provide stable access and namespaces create logical scope. Learning each object as a separate definition hides the control-loop design of Kubernetes.
Scheduling should be understood as the system placing workloads on suitable nodes according to resource and policy constraints. KCNA does not require advanced scheduler configuration, but candidates should know why a pod can remain Pending when no node can satisfy its requirements.
Administration at KCNA level includes basic cluster and workload concepts, not CKA-style deep command execution. Candidates should recognize kubectl as the standard client and understand what common operations such as get, describe, logs or apply are intended to accomplish.
Container orchestration security should include least privilege, workload isolation, secrets awareness, image/supply-chain thinking and policy boundaries. Security is part of the platform design rather than a separate add-on after the application is deployed.
Storage topics should distinguish ephemeral pod filesystem from persistent data. PersistentVolume and claim-style concepts decouple the application’s storage request from the underlying storage implementation, which supports portability across environments.
Troubleshooting is conceptual: determine whether the issue is image/startup, scheduling, networking/service discovery, configuration, storage or application behavior. The first broken layer should drive the next inspection rather than restarting everything.
Application delivery includes declarative configuration and common cloud-native patterns such as GitOps and package management at an introductory level. Helm charts provide one example of packaging Kubernetes application resources for repeatable deployment.
Debugging should connect deployment state with application evidence. A pod can be Running while the service is still unusable because readiness, networking, configuration or the application itself is wrong. Cloud-native systems require layered health reasoning.
Observability means more than logs. Metrics describe numerical behavior, logs provide event/detail context and traces show request flow across distributed services. Cloud-native teams combine these signals to understand systems that are too dynamic for manual server-by-server inspection.
Cloud Native Architecture also covers ecosystem and principles: APIs, declarative automation, immutable infrastructure ideas, resilience, scalability, CNCF projects and open collaboration. The exam expects candidates to understand why Kubernetes sits inside a larger ecosystem rather than acting as the entire cloud-native stack.
Community and collaboration matter because Kubernetes and many surrounding tools are open-source projects governed by communities. Documentation, SIGs, CNCF projects and contribution practices are part of the ecosystem’s operating model even for people who are not code contributors.
For final preparation, keep KCNA conceptual. If study starts drifting into complex cluster repair, certificate rotation or low-level control-plane administration, you are moving toward CKA/CKS depth. The associate exam rewards a clear understanding of components and relationships.
Replica management is another fundamental idea. Deployments and similar controllers maintain a desired number of pod replicas, replacing failed pods when needed. This demonstrates Kubernetes reconciliation: the platform continuously compares desired and observed state rather than performing a one-time launch.
Configuration should be separated from container images. ConfigMaps and Secrets-style concepts allow runtime configuration or sensitive values to be supplied without baking every setting into the image. KCNA expects conceptual awareness of this decoupling even without deep YAML authoring.
Service discovery is a cloud-native reliability pattern because pods are ephemeral. Applications should depend on stable service identities rather than fixed pod IP addresses. This explains why Services and cluster DNS are central to Kubernetes networking.
Ingress or gateway concepts sit above Services when traffic needs to enter from outside the cluster. KCNA candidates should understand the layered path from external client to routing component to Service to pod, without needing advanced controller-specific configuration.
Scheduling also interacts with resources. Containers can request or limit CPU and memory, and the scheduler needs enough available capacity to place pods. A Pending workload can therefore reflect resource constraints rather than an image or networking problem.
Cloud-native observability often uses labels and metadata to group ephemeral workloads. When pods are recreated, stable identifiers such as workload, namespace and service become more useful than tracking one short-lived pod name.
GitOps belongs in the application-delivery conversation because teams can store desired configuration in Git and use automation to reconcile the cluster. The key KCNA concept is declarative, version-controlled delivery rather than the details of one GitOps product.
Service mesh is another ecosystem concept candidates may encounter. It can add traffic management, identity and observability between services, but it does not replace Kubernetes itself. KCNA should recognize the role without diving into product-specific configuration.
CNCF ecosystem awareness includes understanding that Kubernetes is surrounded by projects for networking, storage, observability, delivery, security and service connectivity. The associate-level skill is to recognize categories and principles, not memorize every CNCF project name.
For final review, recreate the 44/28/16/12 domain weights and one real example per competency. The large Kubernetes Fundamentals section deserves the most time, while Cloud Native Architecture should still receive enough attention for observability and ecosystem principles.
Namespaces are another foundational isolation concept. They organize resources and can provide scope for names, quotas and policy. KCNA candidates should understand why large clusters use logical grouping even though namespaces are not the same as strong security boundaries by themselves.
Readiness and liveness concepts belong to application delivery and troubleshooting because orchestration needs to know whether a container should receive traffic or be restarted. They help Kubernetes automate recovery while keeping unhealthy replicas out of service.
ConfigMaps and Secrets reinforce twelve-factor/cloud-native thinking: configuration should be externalized from immutable application images where practical. The exam expects conceptual awareness of how runtime configuration is injected.
Observability should also include alerting and dashboards as outcomes of metrics/log collection. The platform is dynamic enough that operators need service-level views instead of relying on manually checking individual nodes.
The current Linux Foundation certification page positions KCNA as beginner level. Final preparation should therefore prioritize relationships, terminology and architecture over advanced kubectl tricks. If you can explain why each component exists and where a failure belongs, you are at the right depth.
Within the broader Linux Foundation certification path, the strongest KCNA preparation is a clear cloud-native mental model: containers → Kubernetes control/worker architecture → networking/storage/security → application delivery → observability/ecosystem. The exam rewards understanding how those pieces fit more than command memorization.