KCNA: Kubernetes and Cloud Native Architecture

The Kubernetes and Cloud Native Associate (KCNA) certification verifies foundational understanding of Kubernetes and its surrounding ecosystem. The Linux Foundation and CNCF describe a 90-minute, online-proctored multiple-choice exam that covers Kubernetes fundamentals, container orchestration, application delivery and cloud-native architecture. The current published domain weights are 44% Kubernetes fundamentals, 28% orchestration, 16% application delivery and 12% cloud-native architecture. KCNA is not the hands-on administrator examination: it asks candidates to explain how components fit together and why particular mechanisms exist. A capable learner should reason about a workload from its container image through scheduling, networking, storage, rollout and observability.

Explain why Kubernetes separates desired and observed state

Kubernetes lets operators declare a desired condition for workloads instead of manually keeping individual processes alive on particular servers. An API object expresses intent, a controller observes actual state, and reconciliation tries to close the difference. This model explains Deployments and ReplicaSets more effectively than memorizing object names. A Deployment can specify a desired replica count and rollout strategy; a ReplicaSet maintains the requested number of matching Pods. Pods remain ephemeral units that may be replaced as nodes or containers fail. The application should tolerate that replacement through service discovery and appropriate persistence.

Understand the boundary between a container image, a container runtime, a Pod and a node. An image packages executable content and dependencies, while the Pod is the scheduling unit that contains one or more containers sharing certain resources. A node contributes compute and networking capacity; the cluster control plane coordinates scheduling and reconciliation. The Pods, Deployments, ReplicaSets and Services article deepens the relationship among objects that a beginner might otherwise confuse. If one replica crashes, explain why the controller creates a replacement and how a stable Service can continue to direct traffic to healthy Pods.

Understand scheduling and resource constraints

Kubernetes scheduling considers resource requests, placement rules, node conditions, taints and tolerations, and other constraints. A Pod being Pending is not proof of a broken container image; it may never have been assigned to a node. Conversely, a Scheduled Pod that repeatedly crashes presents a different investigation involving application startup, secrets, probes or runtime state. Resource limits can protect neighboring workloads but may also terminate a memory-hungry container. Engineers must understand the difference between requests used for placement decisions and runtime limits governing consumption.

A useful scenario is a cluster with three worker nodes and a new workload that remains Pending. Inspect the Pod's declared CPU and memory requests and compare available allocatable capacity. Check selectors and taints before adding nodes automatically. If the workload schedules but fails readiness checks, adding more replicas may produce many broken Pods instead of one working application. The foundational skill is narrowing the failure stage: was the Pod never scheduled, was the image unavailable, did startup fail or is the application not yet ready to serve traffic?

Connect Services, networking and workload identity

Pod IP addresses can change as workloads are rescheduled. Services offer a stable abstraction for reaching a selected set of Pods, while ingress or gateway mechanisms provide ways to expose services beyond the cluster under controlled policies. A Service does not necessarily create a public endpoint, and a container's port is not equivalent to authorization to reach it. Understand endpoint selection, DNS-based service discovery and common sources of connectivity failure such as mislabeled Pods, unavailable endpoints and restrictive network policies.

Cluster networking also depends on a container network interface implementation, node routes and underlying infrastructure. A network policy can restrict communication between Pods, but support and enforcement depend on the deployed networking components. When a frontend cannot reach a database, first verify that both are healthy, then inspect Service selectors, endpoint presence, DNS and allowed traffic flows. A successful ping between nodes does not prove application routing or policy correctness. Cloud-native design requires connecting Kubernetes abstractions to real forwarding behavior rather than assuming every network feature operates automatically.

Match workload patterns to storage and rollout requirements

Stateless workloads can often be replaced freely; stateful workloads require an explicit plan for persistence, identity and recovery. PersistentVolume and PersistentVolumeClaim objects distinguish a workload's requested storage from the underlying volume supply. StorageClasses and drivers determine provisioning behavior, but an application still needs data-consistency and backup strategy. A volume remaining mounted does not guarantee the database is recoverable after a bad write or regional outage. Understand what Kubernetes manages and which responsibilities remain with storage and application teams.

Deployment rollouts aim to introduce new versions without unnecessary interruption. Readiness and liveness probes address different needs: readiness governs whether a Pod should receive traffic, while liveness detects situations requiring restart. Poor probe settings can cause a cascading outage or allow unhealthy endpoints to remain active. Study rolling updates and rollback, then connect them to practical monitoring. The persistent volume claim topic is a natural extension when evaluating why a stateful service cannot simply be treated as disposable compute.

Identify cloud-native delivery and observability practices

Cloud-native application delivery includes build pipelines, container registries, declarative manifests, configuration management and staged deployment. GitOps uses version-controlled desired state and reconciliation to keep an environment aligned with a reviewed source of truth. It can improve traceability, but it does not remove the need to validate manifests or protect credentials. A mistaken configuration committed to a repository can be applied consistently across every cluster, so policy, testing and review remain essential. A GitOps for Kubernetes delivery discussion is useful where the learning objective moves from individual objects to team-scale change management.

Observability involves metrics, logs and traces, each answering a different question. Metrics reveal changes in traffic, latency or resource use; logs record events; traces show operations across services. An application may have healthy Pods while producing slow responses because an external database is saturated. Cloud-native observability should therefore correlate infrastructure and application evidence. The cloud-native observability fundamentals material clarifies why a green cluster status is not enough to establish a good user experience.

Work through an application outage without guessing

A retail application experiences errors during a routine deployment. The new Pods are running, but customers receive intermittent failures. Investigate the Deployment rollout state, the readiness of new endpoints, Service selectors and ingress or gateway routing. Compare the new version's logs and resource behavior to the previous revision. If the application starts before its dependent database connection is ready, a poor readiness probe may expose it to traffic prematurely. If memory limits are too low, containers may restart under realistic load even though development tests passed.

Do not immediately increase the replica count or disable probes. First identify the failure mode. A service with no healthy endpoints differs from one whose endpoints exist but return application-level errors. Examine DNS, authorization, network policy and persistent storage only when the evidence points to those dependencies. Roll back the release if the business impact and uncertainty warrant it, then perform a controlled comparison. KCNA preparation improves when every Kubernetes concept is used to explain this chain of decisions rather than presented as a detached vocabulary item.

Interpret a rollout failure through controllers and evidence

A team deploys a stateless API into Kubernetes and reports that the Deployment is healthy because its desired replica count is three. Yet only one instance serves requests and users see periodic errors. Start by separating resource intent from observed state: how many Pods are scheduled, ready, available and actually selected by the Service? Examine Deployment conditions and Pod events instead of equating a running container with a working application. A readiness probe can deliberately keep an instance out of service while startup is incomplete, which is correct behavior unless the probe itself is wrong.

Suppose two Pods have insufficient memory requests or were placed on nodes with incompatible taints. Increasing the Deployment replica number may not solve the scheduling constraint. Inspect available node capacity, resource requests, tolerations and any affinity restrictions. If the Service has no suitable endpoints, test its selector and label consistency. If endpoints exist but only certain clients fail, check DNS discovery, network policy and ingress paths separately. The aim is to locate the layer that violates the desired state, not to restart unrelated control-plane components.

The incident may also involve a rollout strategy. A rolling update with aggressive availability settings can attempt to bring up new Pods faster than the cluster can schedule them. Validate image availability, registry authorization and the relationship between readiness probes and minimum available replicas. A failed image pull is different from an application that starts but cannot authenticate to its backend. Both may appear in an operations dashboard as reduced service capacity, but they have different fixes.

After recovery, use the same reasoning to design safeguards. Confirm that application developers set meaningful requests and probes, platform operators enforce reasonable quotas, and the delivery workflow includes a staged rollout and rollback signal. Observability should correlate deployments with error rates, not simply show whether a container exists. A KCNA candidate is not expected to administer every advanced Kubernetes feature, but should understand what controllers, networking, scheduling and deployment automation contribute to the user's experience.

Build a reliable foundation before deeper certifications

Learn to read a simple Pod, Deployment, Service and ConfigMap manifest, then describe their relationships without needing a production cluster. Use a small local lab to practice an image pull failure, a Pending Pod, a missing Service endpoint and a rollout rollback. Review the official domains, since domain weights indicate what the assessment expects. The adjacent KCSA cloud-native security examination focuses more closely on trust boundaries and protective controls; KCNA establishes the architecture needed to understand those protections. The purpose is not memorizing commands but explaining why Kubernetes maintains service through changing workloads and infrastructure.