CNCF CKA (CKA): Complete Study Guide 2026

The Certified Kubernetes Administrator (CKA) is the gold standard for proving you can run Kubernetes in production. Unlike multiple-choice exams, CKA is a two-hour, hands-on, terminal-based performance exam — you fix a broken cluster, schedule workloads, and configure networking in real time. There is nowhere to hide. That is also why it carries weight: every hiring manager in the cloud-native space recognizes it immediately.

This guide covers the current exam blueprint (valid through 2026), gives you a realistic breakdown of what each domain actually demands, and tells you exactly how to spend your final four weeks. Let's move.

Exam at a Glance

• Vendor: Cloud Native Computing Foundation (CNCF) / The Linux Foundation
• Exam code: CKA
• Format: Performance-based, live terminal (browser-based, PSI proctored)
• Duration: 2 hours
• Passing score: 66%
• Cost: $395 USD (includes one free retake)
• Kubernetes version tested: 1.31 (verify on the official page before your exam date)
• Open-book policy: You may use kubernetes.io/docs, kubernetes.io/blog, and github.com/kubernetes during the exam. One extra browser tab, nothing else.

Domain Breakdown

The exam is divided into five domains. Learn the weights — they tell you where to invest your study hours.

Domain 1: Troubleshooting (30%)

This is the heaviest domain and the one most candidates underestimate. The exam will hand you a broken cluster — pods stuck in CrashLoopBackOff, nodes in NotReady, services that resolve nowhere — and expect you to diagnose and fix it within minutes. You will not have time to Google your way through this.

Key subtopics:

• Evaluating cluster and node logging (journalctl -u kubelet, kubectl logs, kubectl describe)
• Monitoring application and cluster component health
• Troubleshooting application failures: misconfigured probes, wrong image tags, missing ConfigMaps/Secrets
• Troubleshooting cluster component failures: kube-apiserver, etcd, kube-scheduler, kube-controller-manager
• Networking failures: DNS not resolving, Services not routing, NetworkPolicy blocking traffic

Study advice: Practice breaking things deliberately. Spin up a kubeadm cluster on two VMs (or use Killercoda), corrupt a static Pod manifest in /etc/kubernetes/manifests/, and fix it. Repeat until it feels boring.

Domain 2: Cluster Architecture, Installation & Configuration (25%)

The second-heaviest domain covers the full lifecycle of a cluster: bootstrapping with kubeadm, upgrading control plane components, managing etcd backups and restores, and configuring RBAC at scale.

Key subtopics:

• Manage role-based access control (RBAC): Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and ServiceAccounts
• Prepare the underlying infrastructure for a Kubernetes cluster using kubeadm
• Perform a version upgrade of a Kubernetes cluster using kubeadm (control plane and worker nodes)
• Implement etcd backup and restore — this is almost always on the exam
• Understand Kubernetes API primitives and understand how to deploy manifests
• Configure kubectl to access multiple clusters (kubeconfig, contexts)

Study advice: Run a kubeadm upgrade end-to-end at least three times. The official upgrade docs are open-book, but you cannot afford to read them line by line during the exam. Memorize the four-command sequence: drain → upgrade → uncordon → verify.

Domain 3: Services & Networking (20%)

Kubernetes networking is deceptively complex. This domain tests whether you understand how traffic actually flows — not just which YAML fields to set.

Key subtopics:

• Understand the connectivity between Pods (CNI model, same-node vs. cross-node)
• ClusterIP, NodePort, LoadBalancer, and ExternalName service types — when and why
• Ingress resources and Ingress controllers: writing rules, path-based and host-based routing
• Configure and use CoreDNS; understand how service DNS names are constructed (svc.cluster.local)
• NetworkPolicy: write policies that restrict ingress/egress by namespace selector, pod selector, and port

Study advice: NetworkPolicy is a common failure point. The "deny-all then allow specific" pattern trips people up because a missing podSelector: {} means something entirely different from an absent selector. Draw traffic flow diagrams by hand until the mental model is solid.

Domain 4: Workloads & Scheduling (15%)

This domain covers everything that makes a workload run reliably: how the scheduler places Pods, how you control rolling updates, and how you expose configuration to applications.

Key subtopics:

• Understand Deployments, ReplicaSets, DaemonSets, StatefulSets, Jobs, and CronJobs
• Configure and use ConfigMaps and Secrets (as env vars and volume mounts)
• Understand resource requests and limits; know how QoS classes (Guaranteed, Burstable, BestEffort) are assigned
• Understand how to scale and perform rolling updates and rollbacks on Deployments
• Scheduling mechanisms: nodeSelector, node affinity, pod affinity/anti-affinity, taints and tolerations
• Use static Pods; configure a Pod to run on a specific node using nodeName

Domain 5: Storage (10%)

Storage is the smallest domain by weight, but exam questions here are precise — a wrong access mode or a missing StorageClass reference means zero points for that task.

Key subtopics:

• Understand PersistentVolumes (PV), PersistentVolumeClaims (PVC), and the binding lifecycle
• Access modes: ReadWriteOnce, ReadOnlyMany, ReadWriteMany — which storage backends support which
• StorageClasses and dynamic provisioning
• Configure applications to use PVCs as volumes
• Understand volume types: emptyDir, hostPath, configMap, secret, and PVC-backed volumes

Sample Questions

Question 1 — Easy

Scenario: A Deployment named web-app in the production namespace is running 3 replicas. You need to scale it to 6 replicas without editing the manifest file directly.

Answer:

kubectl scale deployment web-app --replicas=6 -n production

Explanation: kubectl scale is the imperative command for adjusting replica counts on the fly. It does not modify the underlying YAML stored in source control — so in a real environment you would follow up with a manifest update, but for exam purposes, the command is sufficient. Verify with kubectl get deployment web-app -n production and confirm READY 6/6.

💡 Exam Tip: For any "do X without editing the file" instruction, reach for the imperative kubectl command. For any "ensure this survives a restart" instruction, edit or apply the manifest.

Question 2 — Medium

Scenario: The node worker-02 is in NotReady state. You SSH into it and find that the kubelet service has stopped. Identify the root cause and restore the node to Ready.

Answer approach:

# On worker-02
sudo systemctl status kubelet
sudo journalctl -u kubelet --since "10 minutes ago" | tail -50
# Look for: certificate errors, failed to connect to apiserver, config parse errors
sudo systemctl start kubelet
sudo systemctl enable kubelet
# Back on control plane
kubectl get node worker-02  # should return Ready within ~30s

Explanation: A NotReady node almost always means kubelet is not running or cannot reach the API server. journalctl -u kubelet is your first and fastest diagnostic tool — it will tell you whether the issue is a bad certificate, a misconfigured --config path, or a missing CNI plugin. After fixing the root cause, verify the node transitions to Ready before moving on. In the exam, partial credit is rare — the node must actually be healthy.

💡 Exam Tip: The troubleshooting pattern is always: status → logs → fix → verify. Never skip the verify step — the exam scorer checks cluster state, not your intent.

Question 3 — Hard

Scenario: You must back up the etcd cluster running on the control plane node, then simulate a disaster by stopping etcd, and restore the cluster from the backup. The etcd data directory is /var/lib/etcd. The etcd CA cert, server cert, and key are in /etc/kubernetes/pki/etcd/.

Answer approach:

# Step 1: Snapshot backup
ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Step 2: Verify snapshot
ETCDCTL_API=3 etcdctl snapshot status /tmp/etcd-backup.db --write-out=table

# Step 3: Stop etcd (static pod — move the manifest)
mv /etc/kubernetes/manifests/etcd.yaml /tmp/etcd.yaml
# Wait ~10s for the container to stop

# Step 4: Restore to new data directory
ETCDCTL_API=3 etcdctl snapshot restore /tmp/etcd-backup.db \
  --data-dir=/var/lib/etcd-restored

# Step 5: Update the etcd static pod manifest to point to new data dir
# Edit /tmp/etcd.yaml — change --data-dir and the hostPath volume to /var/lib/etcd-restored
# Also update the volumeMount if it references the old path

# Step 6: Bring etcd back
mv /tmp/etcd.yaml /etc/kubernetes/manifests/etcd.yaml
# Wait for etcd pod to become Running
kubectl get pods -n kube-system | grep etcd

Explanation: etcd backup/restore is tested on virtually every CKA sitting. The most common mistakes are: (1) forgetting ETCDCTL_API=3, (2) using the wrong TLS flags, and (3) restoring to a new directory but forgetting to update the static Pod manifest's hostPath volume and --data-dir flag so that etcd actually reads from it. All three mistakes produce a cluster that silently fails to recover. Always verify with kubectl get nodes after the restore — if the API server responds and nodes are Ready, you're done.

💡 Exam Tip: Bookmark the etcd backup page on kubernetes.io before the exam. During the exam, you have one extra tab — use it for exactly this page. The flag names are too long to memorize perfectly under pressure.

Four-Week Study Plan

Free Official Resources

• Kubernetes Official Documentation — Open-book during the exam. Know how it is organized, not just what it contains. The Tasks and Concepts sections are most useful.
• CNCF Curriculum Repository — The authoritative, version-controlled exam blueprint PDF. Always check this before your exam date for domain weight changes.
• Killercoda CKA Scenarios — Browser-based Kubernetes environments, free tier available. Use these daily for hands-on practice without maintaining your own VMs.
• Linux Foundation: Introduction to Kubernetes (LFS158x) — Free edX course from the exam owner. Good conceptual foundation before you start hands-on labs.
• Killer.sh simulator — Two free sessions are included with your exam purchase. Each session is harder than the real exam by design. Take your first session at the start of Week 4; use the score to target your final week.

Exam Day Tips

• Use aliases aggressively. Set alias k=kubectl and export do="--dry-run=client -o yaml" immediately when the terminal opens. You will save 15–20 minutes across the exam.
• Read every question fully before typing. Many tasks have a namespace specified in the middle of the question, not at the end. Missing the namespace costs you the entire task.
• Flag and skip, do not spiral. If a task is blocking you after 4 minutes, flag it and move on. Return at the end. Two 5-point tasks are worth more than one 4-point task you spent 20 minutes on.
• Verify every task before moving on. The exam does not give you partial credit for correct YAML that fails to apply. Run kubectl get or kubectl describe after every task.
• Context switching is real. Each question specifies a cluster context with kubectl config use-context. Run the provided context-switch command at the top of every question — not just the ones that look different.

Recommended Next Certifications

After passing the CKA, your natural progression depends on whether you want to go deeper into Kubernetes or broader into the cloud-native ecosystem:

• CKAD (Certified Kubernetes Application Developer) — Complements the CKA by focusing on the developer side: multi-container Pod patterns, Helm, custom resources, and application observability. Many engineers hold both.
• CKS (Certified Kubernetes Security Specialist) — Requires a valid CKA as a prerequisite. Covers supply chain security, runtime threat detection with Falco, Pod Security Admission, and network policy hardening. Highly valued in regulated industries.
• AWS Certified DevOps Engineer – Professional / Azure DevOps Engineer Expert — If you manage Kubernetes on a public cloud (EKS, AKS, GKE), pairing the CKA with a cloud-native DevOps professional certification gives you end-to-end credibility from cluster provisioning to CI/CD pipelines.
• HashiCorp Terraform Associate — Most production Kubernetes clusters are provisioned with Terraform. This entry-level cert solidifies your IaC foundation and pairs naturally with CKA on a resume.

The CKA is hard because real Kubernetes administration is hard. Two hours in a live terminal, with a cluster that may or may not do what you expect, is the closest any certification gets to the actual job. Put in the hands-on hours, break your cluster on purpose, and you will pass. Good luck.