KCNA Study Guide | CertGrid

Domain 1: Kubernetes Fundamentals

Key concepts you must know · 311 practice questions

A Pod is the smallest deployable unit in Kubernetes; Kubernetes manages Pods, not individual containers, and containers in a Pod share the same network namespace (IP) and can share storage volumes.
etcd is a distributed, highly available key-value store that holds all cluster state - every Deployment, Service, ConfigMap, Secret, and other object is persisted there.
The kube-apiserver is the front end of the control plane and the single entry point all users and components use to read and write cluster state.
The kube-scheduler watches for newly created Pods with no assigned node and selects a node based on resource requests, taints/tolerations, affinity, and other constraints.
The kube-controller-manager runs reconciliation control loops (e.g., the Deployment, ReplicaSet, and Node controllers) that drive actual state toward the declared desired state.
The kubelet is the per-node agent that reads PodSpecs from the API server and ensures the described containers are running and healthy on that node.
Kubernetes is declarative: you describe the desired state in manifests and controllers continuously reconcile the actual state to match it, rather than running imperative steps.
The Container Runtime Interface (CRI) is the standard API between the kubelet and the container runtime; compliant runtimes include containerd and CRI-O (Docker is no longer used directly).
A node is a worker machine (VM or physical) managed by the control plane that runs Pods via its kubelet, container runtime, and kube-proxy.
Namespaces provide a logical partition for grouping and isolating resources (and applying quotas/RBAC) within a single cluster; they do not isolate nodes.
A ReplicaSet (usually managed by a Deployment) ensures a specified number of identical Pod replicas are running at all times; a Deployment adds rollout and rollback on top.
ConfigMaps store non-confidential configuration data, while Secrets hold sensitive data that is only base64-encoded by default (not encrypted unless encryption-at-rest is enabled on etcd).
Labels are key/value metadata used to select and group objects (e.g., a Service's selector matches Pods by label); annotations hold non-identifying metadata.
The three health probes differ: a liveness probe restarts a stuck container, a readiness probe gates whether a Pod receives Service traffic, and a startup probe protects slow-starting containers until they are up.
Common kubectl commands: 'kubectl get/describe' to inspect resources, 'kubectl logs' to view container logs, 'kubectl apply -f' to create/update from manifests, and 'kubectl exec -it' to run commands inside a container.

Domain 2: Container Orchestration

Key concepts you must know · 198 practice questions

The Container Network Interface (CNI) is a CNCF spec defining a plugin interface for pod networking; the kubelet calls the CNI plugin to set up a Pod's network namespace and assign its IP.
The Container Storage Interface (CSI) is a gRPC-based standard letting third-party storage vendors integrate with Kubernetes (dynamic provisioning, attach, mount, delete) without changing core code.
A Service gives a stable network identity - a ClusterIP virtual IP and DNS name - and load-balances traffic across the Pods selected by its label selector (a plain key/value map under spec.selector).
kube-proxy runs on each node, watches Service and EndpointSlice changes, and programs iptables or IPVS rules to forward Service traffic to backing Pods.
Service types: ClusterIP (internal only, default), NodePort (exposes a port on every node), and LoadBalancer (provisions an external cloud load balancer); 'kubectl expose' creates a Service.
An Ingress defines host/path-based HTTP/HTTPS routing into cluster Services but does nothing without a running ingress controller (e.g., NGINX) to fulfill its rules.
NetworkPolicies are default-allow: all ingress and egress traffic is permitted until a policy selects a Pod; best practice is a default-deny policy plus explicit allow rules.
RBAC controls which users or ServiceAccounts can perform which verbs (get, list, create) on which resources; a Role/RoleBinding is namespaced while a ClusterRole/ClusterRoleBinding is cluster-wide.
Authentication, then authorization (RBAC), then admission control is the order every API request passes through before an object is persisted.
A PersistentVolume (PV) is a piece of cluster storage; a PersistentVolumeClaim (PVC) requests it, and a StorageClass enables dynamic provisioning so a PV is created on demand.
Access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) and reclaim policies (Retain vs Delete) govern how volumes are mounted and what happens to data when a claim is released.
Troubleshooting relies on 'kubectl describe' and events plus Pod states: ImagePullBackOff (bad image/credentials), CrashLoopBackOff (container keeps exiting), OOMKilled (over memory limit), and Pending (unschedulable).
A DaemonSet runs one Pod per node; a StatefulSet gives stable, ordered Pod identity and per-Pod storage for stateful workloads, unlike interchangeable Deployment Pods.
The cluster orchestrates automated scaling, rollouts, and self-healing (restarting or rescheduling failed Pods) to keep workloads at desired state.

Domain 3: Cloud Native Application Delivery

Key concepts you must know · 118 practice questions

Helm is the Kubernetes package manager; a chart bundles templated manifests with metadata and a default values file, and charts are versioned, installable, upgradable, and rollback-able.
Helm commands: 'helm install <name> ./chart' to install, 'helm upgrade --install <name> ./chart' to install-or-upgrade idempotently, and 'helm rollback <name> <revision>' to revert a release.
Kustomize is a template-free customization tool (built into kubectl) that uses a kustomization.yaml to layer overlays and strategic-merge/JSON patches over base manifests per environment.
GitOps treats Git as the single source of truth for desired state, and a reconciling agent continuously syncs the live cluster to match the repo, providing audit trails and pull-request-based changes.
Argo CD and Flux are the leading CNCF GitOps continuous-delivery tools; if someone changes the cluster manually, the agent reverts it back to the state declared in Git.
RollingUpdate is the default Deployment strategy: it incrementally replaces old Pods with new ones, gated by maxSurge (extra Pods allowed) and maxUnavailable (Pods that can be down) for little or no downtime.
The Recreate strategy terminates all old Pods before creating new ones, causing downtime but guaranteeing that two versions never run simultaneously.
Blue-green deployment runs the new version alongside the old and switches traffic at cutover; it requires roughly double the resources during the switch.
Canary deployment routes a small percentage of traffic to the new version first to limit blast radius, then promotes or rolls back based on metrics and traffic-splitting.
A rolling update can stall if a surge Pod cannot be scheduled (insufficient resources) while maxUnavailable prevents removing an old Pod first, leaving the rollout stuck.
Roll back a bad Deployment with 'kubectl rollout undo deployment/<name>'; validate manifests before applying with 'kubectl apply -f app.yaml --dry-run=server'.
Per the Twelve-Factor App methodology, store configuration in the environment (not in code) and treat backing services like databases as attached, swappable resources.
Inject sensitive values via Secrets - ideally managed by sealed-secrets or an external secrets manager - and reference them at runtime rather than baking them into images.
Manifests are applied as declarative YAML/JSON (often templated by Helm or generated by Kustomize) using 'kubectl apply' or pulled in by a GitOps agent.

Domain 4: Cloud Native Architecture

Key concepts you must know · 85 practice questions

The CNCF (Cloud Native Computing Foundation) is a Linux Foundation project that hosts cloud native projects (Kubernetes, Prometheus, Envoy) and tracks them through Sandbox, Incubating, and Graduated maturity levels.
The Open Container Initiative (OCI) standardizes the container image format and runtime behavior so images built by any tool (Docker, Podman, Buildah) run on any compliant runtime.
Cloud native principles include declarative APIs with desired-state reconciliation and immutable infrastructure (replace components rather than modifying them in place).
Microservices enable independent deployment and scaling of services at the cost of added network and operational complexity compared with a monolith; stateless apps keep state in an external store so any replica can serve any request.
Custom Resource Definitions (CRDs) extend the Kubernetes API with new resource types, and the Operator pattern pairs a CRD with a custom controller to automate day-2 operations.
The HorizontalPodAutoscaler (HPA) adjusts a workload's replica count based on observed metrics such as CPU utilization; the Cluster Autoscaler adds or removes nodes so unschedulable Pods can run and idle nodes are reclaimed.
Serverless means running code without managing servers and often scaling to zero when idle; Knative provides serverless workloads on Kubernetes and KEDA drives event-driven autoscaling (including to zero).
The three pillars of observability are logs (discrete timestamped events), metrics (numeric time series like request rate and latency), and traces (the path of a request across services).
Prometheus is the CNCF de facto standard for metrics; it uses a pull model, scraping the /metrics endpoint of each target and storing time series queried with PromQL, where each series is identified by its name plus labels.
OpenTelemetry (OTel) is a vendor-neutral CNCF project providing APIs, SDKs, and a collector to generate and export traces, metrics, and logs to backends such as Jaeger or Prometheus.
Jaeger is a distributed tracing backend that visualizes how a request flows across services and relies on context propagation between them.
Metrics Server collects resource usage and powers 'kubectl top' and CPU/memory-based HPA decisions; it is not a long-term metrics store.
Container logs should be written to stdout/stderr where node-level agents collect and ship them centrally; node-local log files are rotated and lost when a Pod or node is replaced.
Good alerting practice is to alert on user-impacting symptoms (SLO violations) with clear ownership and actionability, rather than alerting on every low-level cause; the CNCF community governs projects through open, collaborative processes.

KCNA exam tips

KCNA is multiple choice with no hands-on tasks, but you should still recognize what common kubectl, helm, and probe configurations do - study commands and their effects, not just definitions.
Kubernetes Fundamentals is by far the largest domain (44%) - prioritize core objects, cluster architecture (control-plane vs node components), scheduling, and containerization there.
Know the CNCF project landscape and what each tool is for: Prometheus (metrics), Jaeger/OpenTelemetry (tracing), Argo CD/Flux (GitOps), Helm (packaging), Envoy/Istio/Linkerd (service mesh), KEDA/Knative (event-driven/serverless).
Be precise about the three health probes: liveness restarts a container, readiness removes it from Service endpoints without restarting, and startup gates the other two during slow boots.
Watch for cloud native principles wording - declarative desired-state reconciliation, immutable infrastructure, and standard interfaces (CRI, CNI, CSI, OCI) are recurring exam themes.

Study guide FAQ

How is the KCNA exam structured and scored?

KCNA is a 90-minute, online proctored, multiple-choice exam (typically around 60 questions). It is scored out of 1000 with a passing score of 750. Unlike the CKA/CKAD/CKS, it is not a hands-on lab exam.

What are the KCNA exam domains and their weights?

The current KCNA has four domains: Kubernetes Fundamentals (44%), Container Orchestration (28%), Cloud Native Application Delivery (16%), and Cloud Native Architecture (12%). Observability, cloud native principles, and community/governance topics sit within the Cloud Native Architecture domain.

Do I need hands-on Kubernetes experience to pass KCNA?

No deep hands-on experience is required, since the exam is multiple choice. However, you should understand what core kubectl, helm, and YAML configurations do conceptually, so practicing with a local cluster (minikube, kind) or a free playground greatly helps with retention.

What's the difference between KCNA and the CKA?

KCNA is an associate-level, knowledge-based exam covering broad cloud native concepts across four domains. The CKA (Certified Kubernetes Administrator) is a performance-based, hands-on exam where you operate a real cluster from the command line. KCNA is a good stepping stone before tackling the CKA, CKAD, or CKS.

Official exam sources

The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.

The Linux Foundation - Kubernetes and Cloud Native Associate (KCNA)link and content verified 8 September 2026Four domains totalling 100%: Kubernetes Fundamentals 44%, Container Orchestration 28%, Cloud Native Application Delivery 16%, Cloud Native Architecture 12%. Matches our loader weights.

Related Cloud Native resources

Test yourself: 712 KCNA practice questions

KCNA: Kubernetes and Cloud Native Associate Study Guide