KCNA

KCNA Exam Details

Domain Weight Breakdown

About the KCNA Certification

The Kubernetes and Cloud Native Associate (KCNA) is a pre-professional certification from the Linux Foundation and CNCF designed to demonstrate foundational knowledge of Kubernetes and the broader cloud native ecosystem. This is a knowledge-based exam (no hands-on labs) that serves as the ideal entry point into the Kubernetes certification path before tackling performance-based exams like the CKA, CKAD, or CKS. The KCNA validates that a candidate understands core Kubernetes concepts, cloud native architecture patterns, container orchestration principles, and the CNCF landscape of projects.

The exam is heavily weighted toward Kubernetes Fundamentals (46%) so candidates must have a solid understanding of the Kubernetes API, resource types, architecture, and basic operations. Container Orchestration (22%) is the second largest domain covering scheduling, scaling, and service discovery. The remaining domains cover architecture, observability, and application delivery patterns.

Exam Tips

The KCNA is a multiple-choice exam with no hands-on component, so focus on understanding concepts rather than memorizing commands. Kubernetes Fundamentals alone accounts for 46% of the exam, so master the core architecture, API resources, and how components interact. Study the CNCF landscape to understand which projects solve which problems. Pay attention to the differences between similar concepts like Deployments vs StatefulSets, ConfigMaps vs Secrets, and Services vs Ingress. Review the CNCF project maturity levels (sandbox, incubating, graduated).

Kubernetes Architecture

Core Kubernetes Resources

Kubernetes API & Resource Model

Every Kubernetes resource is managed through a RESTful API. Resources are organized into API groups (e.g., apps, batch, networking.k8s.io) and API versions (v1, v1beta1). The resource manifest structure follows a standard format with apiVersion, kind, metadata, and spec fields. Labels are key-value pairs attached to resources for identification and grouping. Selectors use labels to filter and target resources. Annotations store non-identifying metadata such as build information or tool configuration.

The Kubernetes API processes requests through authentication (who are you?), authorization (what can you do?), and admission control (is this request valid and should it be modified?) before persisting to etcd. Custom Resource Definitions (CRDs) extend the API by allowing users to define their own resource types, which is the foundation of the Kubernetes operator pattern.

RBAC (Role-Based Access Control)

RBAC verbs include: get, list, watch, create, update, patch, delete. ServiceAccounts provide identity for processes running in pods and are automatically mounted as projected volumes.

Kubernetes Networking Basics

Kubernetes networking follows three fundamental rules: (1) all pods can communicate with all other pods without NAT, (2) all nodes can communicate with all pods without NAT, and (3) the IP that a pod sees itself as is the same IP that others see it as. Services provide stable endpoints for pod access. ClusterIP exposes internally, NodePort exposes on each node\'s IP at a static port, LoadBalancer provisions an external load balancer, and ExternalName maps to a DNS CNAME. Ingress provides HTTP/HTTPS routing to services based on host and path rules.

Exam tip: Understand the relationship between pods, services, and endpoints. A Service selects pods via labels, and an Endpoints resource is automatically created mapping the Service to pod IPs. CoreDNS resolves service names to ClusterIPs in the format: service-name.namespace.svc.cluster.local.

Container Fundamentals

Containers are lightweight, isolated processes that package an application with its dependencies into a single runnable unit. Unlike virtual machines which virtualize hardware, containers share the host OS kernel and use Linux namespaces (PID, NET, MNT, UTS, IPC, USER) for isolation and cgroups for resource limits (CPU, memory). The OCI (Open Container Initiative) defines industry standards for container image format (OCI Image Spec) and container runtime (OCI Runtime Spec).

Container Runtimes

The Container Runtime Interface (CRI) is the plugin interface between kubelet and the container runtime. Kubernetes removed built-in Docker support (dockershim) in v1.24; containerd and CRI-O are the supported runtimes. Docker images still work because they are OCI-compliant.

Pod Scheduling & Placement

Taint effects: NoSchedule prevents new pods, PreferNoSchedule is a soft version, NoExecute evicts existing pods without matching tolerations.

Scaling Strategies

The HPA requires the Metrics Server to be installed for CPU and memory metrics. For custom metrics, a metrics adapter (Prometheus Adapter, KEDA) is needed. The HPA checks metrics every 15 seconds by default and has a stabilization window to prevent flapping.

Deployment Strategies

Exam tip: Know that Kubernetes natively supports Rolling Update and Recreate strategies. Blue/Green and Canary deployments require additional tooling like Argo Rollouts, Flagger, or Istio traffic management.

Cloud Native Definition & Principles

The Cloud Native Computing Foundation (CNCF) defines cloud native technologies as those that empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Cloud native approaches include containers, service meshes, microservices, immutable infrastructure, and declarative APIs. These techniques enable loosely coupled systems that are resilient, manageable, and observable.

The Twelve-Factor App Methodology

CNCF Project Maturity Levels

Microservices vs Monolith Architecture

Communication patterns between microservices include synchronous (REST APIs, gRPC) and asynchronous (message queues like RabbitMQ, Kafka, NATS). Asynchronous communication provides better resilience and decoupling but adds complexity.

Serverless & FaaS in Cloud Native

Serverless abstracts infrastructure management entirely, letting developers focus on code. In the Kubernetes ecosystem, Knative (CNCF incubating) provides serverless capabilities with scale-to-zero, event-driven functions, and traffic splitting. Knative consists of Serving (auto-scaling HTTP workloads) and Eventing (event routing and delivery). Other CNCF serverless projects include OpenFunction and Nuclio. Cloud provider serverless offerings include AWS Lambda, Google Cloud Functions, and Azure Functions.

Exam tip: The KCNA tests conceptual understanding of cloud native patterns. Know the differences between IaaS, PaaS, CaaS (Containers as a Service), and FaaS. Understand where Kubernetes fits (CaaS) and how serverless platforms like Knative build on top of Kubernetes.

Three Pillars of Observability

Observability goes beyond monitoring. While monitoring tells you when something is wrong, observability helps you understand why. A fully observable system lets you ask arbitrary questions about its behavior using metrics, logs, and traces without deploying new instrumentation.

Prometheus Overview

Prometheus is the CNCF graduated monitoring system and the de facto standard for Kubernetes metrics. It uses a pull-based model, scraping metrics from HTTP endpoints at configured intervals. Data is stored in a local time-series database. PromQL is the powerful query language for querying, aggregating, and alerting on metric data.

OpenTelemetry (OTel)

OpenTelemetry is the CNCF incubating project that provides a single set of APIs, SDKs, and tools for generating, collecting, and exporting telemetry data (metrics, logs, traces). It is vendor-neutral and provides auto-instrumentation for many languages and frameworks. The OpenTelemetry Collector receives, processes, and exports telemetry to any backend (Prometheus, Jaeger, Loki, cloud services).

Logging in Cloud Native Environments

Cloud native applications should write logs to stdout/stderr (Factor XI of 12-Factor App). The container runtime captures these streams and writes them to log files on the node at /var/log/containers/. A log collector DaemonSet (Fluent Bit, Fluentd) tails these files and ships them to a centralized backend.

Distributed Tracing

In microservices architectures, a single user request may traverse many services. Distributed tracing follows the complete request path by propagating a trace context (trace ID + span IDs) across service boundaries. Each service creates a span representing its portion of the work. The collection of all spans for a request forms a trace. This allows developers to pinpoint latency, errors, and bottlenecks across the distributed system.

Exam tip: Remember the relationship between the three pillars: metrics tell you something is wrong (high error rate), logs explain what happened (error messages), and traces show where it happened (which service in the chain). OpenTelemetry unifies all three under a single framework.

Cost Management & FinOps

Cloud native observability also includes understanding resource utilization for cost optimization. Tools like Kubecost and OpenCost (CNCF sandbox) provide real-time cost monitoring for Kubernetes workloads. Key practices include setting resource requests and limits on all containers, using ResourceQuotas and LimitRanges per namespace, monitoring actual vs requested resource usage, right-sizing workloads based on VPA recommendations, and leveraging spot/preemptible instances for fault-tolerant workloads.

CI/CD Pipeline Fundamentals

Continuous Integration and Continuous Delivery/Deployment (CI/CD) automate the process of building, testing, and deploying applications. In cloud native environments, CI/CD pipelines typically produce container images that are deployed to Kubernetes clusters.

GitOps Principles

GitOps is an operational paradigm where Git is the single source of truth for declarative infrastructure and applications. Changes are made through pull requests, and controllers running in the cluster continuously reconcile actual state with the desired state in Git. The four core principles of GitOps are:

Helm Package Manager

Helm is the CNCF graduated package manager for Kubernetes. It packages Kubernetes manifests into charts (reusable templates) that can be versioned, shared, and installed with configurable values. Helm simplifies deployment of complex applications by managing dependencies, providing templating, and supporting release lifecycle (install, upgrade, rollback, uninstall).

Kustomize

Kustomize is a Kubernetes-native configuration management tool built into kubectl (kubectl apply -k). Unlike Helm, Kustomize uses a template-free approach: it takes existing YAML manifests and applies overlays (patches) without modifying the originals. This makes it ideal for managing environment-specific variations (dev/staging/prod) of the same base manifests.

Supply Chain Security

Securing the software supply chain is critical in cloud native environments. Key practices include image signing to verify provenance, vulnerability scanning of container images, using minimal base images (distroless, Alpine), enforcing image pull policies, and implementing admission controllers to validate image signatures.

Exam tip: Understand the complete application delivery lifecycle: code commit triggers CI pipeline, builds container image, scans for vulnerabilities, signs the image, pushes to registry, then either pushes deployment to cluster (traditional CI/CD) or updates Git repo for GitOps controller to pull. Know the benefits of GitOps over traditional push-based deployment.