Linux Foundation KCNA: What Matters Most

The KCNA exam is the Linux Foundation’s foundational Kubernetes and cloud-native certification. The current exam is an online, proctored multiple-choice assessment organized into four domains: Kubernetes Fundamentals (44%), Container Orchestration (28%), Cloud Native Application Delivery (16%), and Cloud Native Architecture (12%).

KCNA is intentionally broad rather than deeply administrative. The goal is to understand how Kubernetes and the wider cloud-native ecosystem fit together: containers, workloads, scheduling, networking, security, storage, application delivery, observability, community, and core architectural principles. Candidates should recognize how the pieces interact without turning preparation into a CKA-level operations course.

Kubernetes fundamentals carry almost half the exam

Start with cluster components, the control plane, worker nodes, Pods, Deployments, Services, namespaces, labels, desired state, and the declarative model. You should be able to explain what Kubernetes is trying to reconcile when a resource changes.

Create a local cluster or sandbox and deploy a simple application. Scale the Deployment, delete a Pod, and watch the controller restore desired state. This single exercise makes reconciliation more concrete than memorizing component definitions.

Administration at KCNA level means understanding basic resource and cluster concepts, not becoming an expert in every kubectl troubleshooting command.

Add ReplicaSets, rollout behavior, and basic configuration objects such as ConfigMaps and Secrets to the lab. You should understand which resource declares desired application state and which resources provide configuration or sensitive values to the Pods.

Use kubectl or the chosen interface to inspect state after a change, but keep commands secondary to the control-loop idea. KCNA is testing whether you understand Kubernetes behavior, not whether you can recall every command flag.

Add namespace scope to the exercise. Deploy similar resources in two namespaces and observe how names, configuration, access, and operational views are separated. Namespaces are not full security boundaries by themselves, but they are important organizational building blocks.

Practice the relationship between a Deployment and the ReplicaSet it manages. KCNA candidates should understand which object expresses the higher-level rollout intent and which object keeps the requested replica count running.

Scheduling is about matching workloads to resources

Understand why a Pod lands on one node rather than another and what resource requests, limits, labels, selectors, affinities, taints, or tolerations are intended to influence at a conceptual level.

Create a scenario where a workload remains Pending because no node satisfies its constraints. The important skill is recognizing that the scheduler is enforcing requirements rather than assuming the application itself is broken.

Capacity still matters. A cluster can have healthy nodes and insufficient usable resources for the workload requested.

Containerization is the foundation under Kubernetes

Know the purpose of images, registries, layers, container runtime concepts, immutability, environment configuration, and the difference between a container image and a running container.

The Linux+ XK0-006 exam is a useful adjacent boundary because Linux skills explain much of the host behavior beneath containers. KCNA candidates need container concepts without turning the plan into operating-system administration.

Practice building or pulling an image, starting a container, and observing what happens when configuration is missing. Kubernetes adds orchestration on top of that basic container behavior.

Networking questions test service connectivity concepts

Understand Pod networking, Services, cluster DNS, ingress or gateway concepts, network policy awareness, and how workloads communicate inside and outside the cluster.

A useful lab deploys two services and proves name-based communication, then breaks a selector or endpoint relationship. This teaches that a Service can exist while routing to no healthy Pods.

KCNA does not require deep CNI implementation knowledge, but you should recognize the purpose of the networking layers and where policy or discovery fits.

Create two Services with different exposure needs and compare cluster-internal access with external ingress. The exercise helps separate service discovery from internet exposure.

Add a simple NetworkPolicy conceptually or in a lab where supported. The goal is to understand that connectivity can be intentionally restricted even when Pods and Services are otherwise healthy.

Storage is about persistent state in an ephemeral platform

Pods can be replaced, but applications may still need durable data. Understand volumes, persistent volumes, claims, storage classes, and the conceptual separation between a workload lifecycle and storage lifecycle.

Deploy a stateful example and delete the Pod while preserving the data. The exercise demonstrates why persistent storage is managed separately from an individual container instance.

The exam is more likely to ask what a storage concept is for than to require advanced storage-driver administration.

Add StatefulSet awareness to the storage discussion so you can explain why some workloads need stable identities or ordered behavior in addition to persistent storage. KCNA does not require deep stateful-application administration, but recognizing the pattern is useful.

Compare ephemeral configuration, Secrets, and persistent application data. These resources have different lifecycles and should not be treated as interchangeable just because they can all be mounted into a Pod.

Security begins with identity, isolation, and least privilege

At foundational level, understand authentication and authorization concepts, service accounts, secrets, namespaces, network policy awareness, image security, and the general idea that cluster access should be scoped.

Do not treat Secrets as magical encryption. Think about how sensitive configuration is stored, mounted, accessed, and limited to workloads that need it.

Cloud-native security is layered: image supply chain, cluster access, workload identity, network boundaries, runtime behavior, and admission or policy controls can all contribute.

Include image provenance and admission concepts at a high level. A cluster can be well configured and still run a malicious or vulnerable image if the supply chain is uncontrolled.

Practice explaining the security boundary between Kubernetes RBAC, workload identity, network policy, and secrets. Each protects a different part of the system, and no single control replaces the others.

Application delivery connects Kubernetes to DevOps

KCNA includes application delivery and debugging because cloud-native systems are continuously changed. Understand CI/CD, GitOps concepts, declarative deployment, rollout, rollback, and how teams observe whether a new version is healthy.

Deploy a new image version and observe rollout state. Then use a bad image or configuration and roll back. The exact commands matter less than understanding that delivery is controlled state transition.

A deployment system should leave evidence about which version is active and whether the rollout met health expectations.

Add a declarative manifest to version control and change the image tag through a commit. This connects Kubernetes delivery to Git-based change history and makes rollback easier to reason about.

Practice the difference between a failed rollout and a healthy rollout with a broken application dependency. Kubernetes can report Pods ready while users still fail because the application cannot reach a database or API.

Observability belongs in cloud-native architecture

The current KCNA blueprint places observability under Cloud Native Architecture. Understand logs, metrics, traces, health signals, and why distributed systems need visibility across several services rather than one server log.

Create one failure and identify which signal would detect it fastest. A container restart, latency increase, and broken downstream dependency may require different evidence.

Observability is not a dashboard product category. It is the ability to understand system behavior well enough to diagnose and improve it.

Add readiness and liveness concepts to monitoring practice. A process can be running but not ready to receive traffic, and Kubernetes should be able to distinguish those states.

Use one distributed request across two services and decide which metric, log, or trace would reveal where latency increased. This makes observability more practical than memorizing the names of monitoring projects.

Learn the CNCF ecosystem without memorizing every project

KCNA expects awareness of cloud-native ecosystem principles and community. Focus on categories—runtime, networking, observability, service mesh, delivery, storage, security—and why open standards and community governance matter.

The KCNA certification is a foundation credential, so breadth matters more than memorizing dozens of CNCF project names. Know a few representative tools and the problem class each solves.

The Linux Foundation certification inventory can help you see later cloud-native paths. Finish KCNA able to explain Kubernetes and cloud-native architecture coherently before moving into deeper administration or security certifications.

Create a one-page ecosystem map with one representative project or concept in runtime, networking, observability, delivery, security, storage, and service mesh. Replace the example when necessary, but keep the category and problem stable.

This category-first approach is more durable because CNCF projects evolve. KCNA is intended to validate cloud-native literacy, not a frozen list of product names.

Finish with one architecture sketch that includes an application, ingress or gateway, service discovery, persistent storage, observability, CI/CD or GitOps, and a security control. Label the problem each layer solves.

If you can explain the sketch without naming a specific vendor implementation, you have reached the portable cloud-native understanding KCNA is designed to validate.

Use the current Linux Foundation domain weights for the final review so Kubernetes Fundamentals and Container Orchestration receive proportionate attention. Cloud-native breadth matters, but the exam clearly gives most of its weight to Kubernetes concepts and workload behavior.

Keep the final review centered on portable Kubernetes and cloud-native concepts rather than product trivia.

• Category: All Certifications Certifications