Cloud native is the default infrastructure stack. KCNA proves you understand it.

In 2026, Kubernetes is not a niche technology. It is the default deployment platform for containerised workloads across every major cloud provider, most mid-size technology companies, and a growing share of enterprise IT organisations. The CNCF’s annual survey consistently shows Kubernetes usage exceeding 80% among cloud native practitioners — and usage is only the floor. The real signal is that cloud native tooling has expanded far beyond Kubernetes itself into a broad ecosystem of observability platforms (Prometheus, Grafana, OpenTelemetry), service mesh implementations (Istio, Cilium), GitOps delivery tools (ArgoCD, Flux), and policy engines (OPA, Kyverno). Understanding this ecosystem, not just the Kubernetes API, is what KCNA validates.

The gap between IT professionals who have hands-on cloud experience and those who understand the cloud native ecosystem as a coherent architecture is wide. Many candidates can run kubectl get pods but cannot explain the role of the container runtime interface, the difference between a DaemonSet and a StatefulSet, or why GitOps solves configuration drift. KCNA tests exactly that layer: conceptual depth across the full cloud native stack, not just Kubernetes cluster operations. This makes it genuinely useful as a pre-CKA credential — candidates who sit the KCNA first arrive at the CKA lab with a mental model of what they are administering, rather than learning architecture and operations simultaneously.

The Linux Foundation positioned KCNA deliberately at the “Associate” tier following the pattern of AWS, Azure, and GCP entry-level credentials: lower cost, no prerequisites, multiple-choice format, broad conceptual coverage. For hiring managers, KCNA on a résumé signals that a candidate has formally validated cloud native awareness — a baseline that many job descriptions now list alongside or in place of the older AWS Cloud Practitioner requirement for cloud-adjacent roles.

The five KCNA domains

Domain 1 — Kubernetes Fundamentals (~46%)

The largest domain covers the Kubernetes architecture and core API objects. Nearly half the exam tests whether candidates understand how Kubernetes works at a conceptual level — not how to administer a cluster at a command-line depth, but how the components interact and why.

  • Control plane components: the API server is the single entry point for all cluster operations; etcd is the distributed key-value store that holds cluster state; the scheduler assigns pods to nodes based on resource requirements and constraints; the controller manager runs control loops that reconcile desired state with actual state. KCNA tests the role of each component, not its configuration syntax.
  • Node components: kubelet is the node agent that ensures containers described in pod specs are running; kube-proxy maintains network rules for service routing; the container runtime (containerd in the current standard stack, following the deprecation of Docker as a direct runtime in Kubernetes 1.24) executes and manages container processes. The Container Runtime Interface (CRI) decouples Kubernetes from specific runtimes — KCNA tests this abstraction.
  • Workload resources: Pod (the smallest deployable unit, wrapping one or more containers sharing network and storage), Deployment (manages ReplicaSets for stateless applications with rolling update strategy), StatefulSet (ordered, stable pod identities for stateful applications like databases), DaemonSet (runs one pod per node for infrastructure concerns like logging agents and CNI plugins), Job and CronJob (batch workloads). KCNA tests when each workload type is appropriate, not how to write their YAML manifests.
  • Service types and networking basics: ClusterIP (internal cluster communication), NodePort (exposes a service on a static port on each node), LoadBalancer (provisions a cloud load balancer), Ingress (HTTP/HTTPS routing rules managed by an ingress controller). The KCNA exam tests the conceptual purpose of each service type and the role of DNS within a cluster (CoreDNS provides svc.cluster.local resolution).
  • Storage abstractions: PersistentVolume (PV) and PersistentVolumeClaim (PVC) decouple storage provisioning from pod configuration. StorageClass enables dynamic provisioning. KCNA tests the binding lifecycle — how a PVC requests storage and how a PV is either statically provisioned or dynamically created by a provisioner — not the underlying storage driver configuration.
  • ConfigMaps and Secrets: ConfigMaps inject non-sensitive configuration into pods as environment variables or volume mounts; Secrets store sensitive data with base64 encoding (important KCNA point: base64 is encoding, not encryption — Secrets at rest require additional encryption configuration to be secure). KCNA tests the distinction and the appropriate use of each.

Domain 2 — Container Orchestration (~22%)

This domain places Kubernetes in the broader context of container orchestration — why container orchestration exists, what problems it solves, and how Kubernetes compares to alternatives. It also covers the container fundamentals that underpin Kubernetes workloads.

  • Container fundamentals: containers package an application and its dependencies into an isolated unit using Linux namespaces (process, network, mount, UTS, IPC) and control groups (cgroups) for resource limits. Images are built in layers using a Dockerfile; the OCI (Open Container Initiative) image and runtime specifications ensure interoperability across registries and runtimes. KCNA tests the conceptual model of containers, not Dockerfile authoring.
  • Why orchestration: running a single container manually scales to a handful of services. Orchestration solves scheduling (which node has available resources?), health management (restart failed containers), service discovery (how do containers find each other?), rolling updates, and autoscaling — the operational concerns that become unmanageable at scale without a platform. KCNA tests this problem-solution framing.
  • Kubernetes vs alternatives: Docker Swarm, Nomad, and Mesos were credible orchestration alternatives in 2018–2020. By 2026, Kubernetes has effectively won the orchestration category for containerised workloads. KCNA acknowledges this history and positions Kubernetes as the CNCF’s graduated project that achieved this dominance through its extensible architecture (CRI, CNI, CSI interfaces) rather than any single feature advantage.
  • Cloud provider managed Kubernetes: EKS (AWS), AKS (Azure), GKE (GCP), and DOKS (DigitalOcean) manage the control plane as a service. KCNA tests the shared responsibility model: the cloud provider manages control plane availability and upgrades; the cluster operator manages worker node configuration, workload deployment, and security policies. The managed control plane simplifies operations but does not eliminate the need to understand Kubernetes fundamentals.
  • Autoscaling mechanisms: the Horizontal Pod Autoscaler (HPA) scales pod replica counts based on observed CPU or custom metrics; the Vertical Pod Autoscaler (VPA) adjusts resource requests for individual pods; the Cluster Autoscaler adds or removes nodes based on pending pod scheduling demand. KCNA tests which mechanism addresses which scaling problem.

Domain 3 — Cloud Native Architecture (~16%)

Cloud native architecture is the design philosophy that makes applications operationally efficient on Kubernetes and cloud infrastructure. This domain tests architectural patterns and CNCF ecosystem projects at a conceptual level.

  • The twelve-factor application model: the Twelve-Factor App methodology (originally from Heroku) aligns directly with Kubernetes operational assumptions — stateless processes, externalized configuration, declarative logging, and ephemeral build/release/run phases. KCNA tests these factors in the context of cloud native deployment, particularly the separation of build and run stages (immutable images) and the expectation that processes can be started and stopped without data loss.
  • Microservices vs monolith: cloud native architecture favours decomposing applications into independently deployable services, each with its own data store and deployment lifecycle. KCNA tests the trade-offs: microservices enable independent scaling and deployment but introduce network latency, distributed transaction complexity, and operational overhead. Neither architecture is universally superior — KCNA tests the architectural considerations that inform the choice.
  • Service mesh concepts: a service mesh injects a sidecar proxy (Envoy is the dominant proxy) into each pod to handle service-to-service communication: mutual TLS, traffic shaping, retries, circuit breaking, and observability. Istio and Cilium (which uses eBPF rather than sidecar proxies) are the leading implementations. KCNA tests the problem a service mesh solves (operational concerns extracted from application code into the infrastructure layer) rather than mesh configuration.
  • Serverless on Kubernetes: Knative provides serverless capabilities on top of Kubernetes: scale-to-zero, event-driven invocation, and simplified service deployment. KCNA tests the conceptual model — serverless does not mean no infrastructure, it means the developer does not manage infrastructure directly. Knative on Kubernetes occupies the space between raw Kubernetes deployments and fully managed FaaS (AWS Lambda, Azure Functions).
  • Open standards and interoperability: the CNCF’s ecosystem is built on open specifications that prevent lock-in. CRI (Container Runtime Interface), CNI (Container Network Interface), CSI (Container Storage Interface), and OCI (Open Container Initiative) standards mean that Kubernetes works with multiple runtime, network, and storage implementations. KCNA tests why these specifications matter and which layer of the stack each one addresses.

Domain 4 — Cloud Native Observability (~8%)

Observability is the ability to understand a system’s internal state from its external outputs. Cloud native observability covers the three pillars — metrics, logs, and traces — and the CNCF projects that implement each.

  • Metrics with Prometheus: Prometheus is the CNCF’s graduated metrics collection and alerting system. It scrapes HTTP endpoints that expose metrics in the Prometheus exposition format, stores them as time-series data, and evaluates alert rules. Grafana visualises Prometheus data. KCNA tests the pull-based scraping model (Prometheus pulls from targets, unlike push-based systems), the role of exporters (translate third-party metrics into the Prometheus format), and the Alertmanager routing pipeline.
  • Logging architecture: Kubernetes does not provide a cluster-wide logging solution — it provides per-container stdout/stderr via kubelet. Production logging typically uses a DaemonSet-deployed log collector (Fluentd or Fluent Bit) that ships logs to an aggregation platform (Elasticsearch/OpenSearch or Loki). KCNA tests the architectural pattern: why cluster-level logging requires an additional layer, and how node-level log collection DaemonSets work.
  • Distributed tracing with OpenTelemetry: distributed tracing follows a request across multiple services by propagating a trace context (trace ID, span ID) in HTTP headers. OpenTelemetry (the merger of OpenCensus and OpenTracing) is the CNCF standard for instrumenting applications to emit traces, metrics, and logs in a vendor-neutral format. KCNA tests the conceptual model of spans, traces, and the problem tracing solves: identifying latency contributors across service boundaries that metrics alone cannot pinpoint.
  • The role of observability in cloud native systems: traditional monitoring is testing for known failure modes (is the CPU above 80%?). Observability is the ability to ask arbitrary questions about system behaviour after an incident (why did the p99 latency spike for this specific user cohort?). KCNA tests this distinction and why cloud native systems — with their ephemeral pods, auto-scaling, and service mesh complexity — require observability rather than just monitoring.

Domain 5 — Cloud Native Application Delivery (~8%)

Application delivery in cloud native environments means automated, repeatable, auditable deployment pipelines. This domain tests GitOps principles and the CNCF delivery toolchain.

  • GitOps principles: GitOps uses a Git repository as the single source of truth for desired cluster state. A GitOps operator (ArgoCD or Flux) continuously reconciles actual cluster state with the state declared in Git, automatically applying differences. The four GitOps principles (declarative configuration, versioned and immutable state in Git, automated reconciliation, continuous reconciliation) are testable on the KCNA exam. The key operational benefit: Git provides a complete audit trail and rollback capability for every cluster change.
  • CI/CD pipeline architecture: Continuous Integration builds and tests code on every commit; Continuous Delivery automates the release process so every passing build can be deployed; Continuous Deployment goes further and automatically deploys every passing build to production. KCNA tests the conceptual distinctions. In Kubernetes environments, CI typically produces a new container image tag; CD updates the image reference in the Kubernetes manifests committed to the GitOps repository.
  • Helm for package management: Helm packages Kubernetes manifests into versioned, configurable charts. A chart is a collection of templates that are rendered with user-supplied values to produce Kubernetes manifests. Helm handles install, upgrade, and rollback of application deployments as atomic releases. KCNA tests Helm’s role in the delivery pipeline: standardising application packaging so the same chart can deploy to development, staging, and production with environment-specific values, rather than maintaining separate manifest copies per environment.
  • Container image management: immutable image tags (using content-addressed digests like sha256:abc123 rather than mutable tags like latest) are a GitOps requirement — the Git repository references a specific image digest, so the running state is deterministic and auditable. KCNA tests the principle of image immutability and why mutable tags undermine GitOps’ audit guarantees.

Exam format and what to expect

The KCNA uses a straightforward multiple-choice format: 60 questions in 90 minutes delivered through the PSI remote proctoring platform. One free retake is included in the $395 examination fee, and the retake window is 12 months from purchase. The passing score of 75% means candidates can miss up to 15 questions — a more forgiving threshold than the hands-on CKA and CKAD exams, which require 66% on practical lab tasks under time pressure.

The conceptual nature of the KCNA means the exam rewards breadth over depth. Candidates who have narrowly focused on Kubernetes operations without exploring the surrounding CNCF ecosystem often underperform on the Container Orchestration, Cloud Native Architecture, Observability, and Application Delivery domains, which together account for 54% of the exam. The candidate who has read broadly across the CNCF landscape — understanding what Prometheus, Istio, Helm, ArgoCD, OpenTelemetry, and Knative are and why they exist — is better positioned than one who has memorised kubectl commands.

The most common KCNA study mistake: treating it as a scaled-down CKA. The KCNA does not require hands-on cluster interaction. Questions ask “what problem does X solve” and “when would you use Y over Z” — not “write the YAML for a StatefulSet.” Candidates who over-invest in lab practice and under-invest in ecosystem conceptual breadth arrive at the exam surprised by Prometheus alerting, GitOps reconciliation, and OCI specification questions.

Where KCNA fits the cloud native certification ladder

The Linux Foundation offers four Kubernetes certifications at different depth levels, and understanding the ladder helps candidates sequence their investment correctly:

Study approach and timeline

Candidates with existing Linux and networking fundamentals typically require three to six weeks of part-time preparation for the KCNA, averaging eight to ten hours per week. The recommended preparation sequence: read the official Kubernetes documentation concepts section (not the reference section — the concepts section explains the why behind API objects); explore the CNCF landscape to understand which projects address which operational problems; practice with the free interactive Kubernetes playground environments to build familiarity with pod, service, and deployment objects; complete practice questions to identify knowledge gaps across the Observability and Application Delivery domains, which most study materials underemphasise relative to their exam weight.

Candidates without Linux or networking background should plan six to eight weeks and invest additional time in container fundamentals (how Linux namespaces and cgroups create container isolation), TCP/IP networking (Kubernetes networking builds on these primitives), and YAML syntax (every Kubernetes API object is expressed in YAML). The KCNA is achievable for motivated candidates without a formal computer science background, but the foundational concepts take longer to absorb without prior context.

Why it matters for cert candidates

KCNA is the most direct entry point into the CNCF certification ecosystem. As platform engineering roles proliferate, hiring managers at companies running Kubernetes look for KCNA as a signal that a candidate has validated cloud native knowledge beyond marketing awareness. The $395 cost includes a retake, making it one of the more accessible professional certifications to attempt. For candidates targeting SRE, DevOps, or platform engineering roles, KCNA + CKA is now the minimum expected credentialling pair — the same way AWS Cloud Practitioner + Solutions Architect was the entry bar for cloud roles four years ago. The official Linux Foundation KCNA page contains the authoritative exam domains, candidate handbook, and registration link.

Practice KCNA concepts and Kubernetes fundamentals with expert-level questions on CertQuests.

Browse Kubernetes Certifications →