How to Pass the CKA Exam in 2026: Study Guide for Kubernetes v1.37

This guide is for anyone booking the Certified Kubernetes Administrator exam in the next few months: working engineers who use Kubernetes but have never had to rebuild a broken control plane under a timer. By the end you will have a local practice cluster on the same Kubernetes version as the exam, a kubectl setup that saves minutes per task, drills for every curriculum domain, and a six-week plan. Everything here was checked on 10 November 2026 against the Linux Foundation CKA page, which says the exam runs Kubernetes v1.37, and the CNCF curriculum repository. Prerequisites: Docker, a Linux or macOS terminal, kubectl, and comfort with vim or nano. If you are still deciding whether the CKA is the right certification at all, start with my comparison of the best DevOps and cloud certifications in 2026.

Step 1: Learn what the v1.37 CKA actually tests

The exam is two hours of performance-based tasks, $445 with one free retake, valid for two years, and you need 66% to pass according to the LF certification FAQ. Results arrive by email within 24 hours. The domains and weights below come from CKA_Curriculum_v1.37.pdf in the CNCF repository.

Domain	Weight	What shows up in practice	Source
Troubleshooting	30%	Broken kubelet, failing control plane pods, services with no endpoints, logs and resource usage	CNCF curriculum
Cluster Architecture, Installation and Configuration	25%	RBAC, kubeadm install and upgrade, HA control plane, Helm and Kustomize, CRDs and operators, CNI/CSI/CRI	CNCF curriculum
Services and Networking	20%	Service types, NetworkPolicy, Gateway API, Ingress, CoreDNS	CNCF curriculum
Workloads and Scheduling	15%	Rollouts and rollbacks, ConfigMaps and Secrets, autoscaling, affinity, limits	CNCF curriculum
Storage	10%	StorageClasses, dynamic provisioning, access modes, reclaim policies, PV and PVC	CNCF curriculum

The important change is older than most courses admit. On 18 February 2025 the Linux Foundation added Helm, Kustomize, the Gateway API, CRDs and operators to the CKA. If your course still spends an hour on etcd internals and five minutes on Gateway API, it predates that change.

Step 2: Understand the exam environment before exam day

In my experience the environment trips people up about as often as Kubernetes does. The LF exam tips page describes it:

• The exam is proctored by PSI through the PSI Secure Browser, on a single monitor, and runs a remote Linux desktop.
• You get 15 to 20 tasks. Each task names a host; you ssh to it, do the work, and exit. Nested SSH is not supported, and the base host has none of the exam tools.
• On the task hosts, kubectl is installed with the k alias and bash completion, plus yq, curl, wget and man pages. Use sudo -i when a task needs root.
• In the terminal, copy and paste are Ctrl+Shift+C and Ctrl+Shift+V. Ctrl+W closes a Chrome tab, so do not use it to delete a word.
• Allowed documentation for the CKA is kubernetes.io/docs, kubernetes.io/blog, helm.sh/docs and gateway-api.sigs.k8s.io, per the resources allowed page. You may search kubernetes.io but must not open external results.

Run the PSI system check on the machine you will use, a personal one rather than a work laptop with endpoint security, a few days before.

Step 3: Build a v1.37 practice cluster with kind

You need a cluster you can break without consequences. kind v0.33.0, released on 26 August 2026, defaults to Kubernetes 1.37.0. Pin the node image digest so your cluster does not drift.

# kind-cka.yaml: one control plane, two workers, Kubernetes v1.37.0
# Image and digest from the kind v0.33.0 release notes.
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true   # install a CNI yourself; it is part of the curriculum
nodes:
  - role: control-plane
    image: kindest/node:v1.37.0@sha256:a1ed56cfb0e7b93589bdf97c8cd566405a265939e3620fc4f5de89adff580ae5
  - role: worker
    image: kindest/node:v1.37.0@sha256:a1ed56cfb0e7b93589bdf97c8cd566405a265939e3620fc4f5de89adff580ae5
  - role: worker
    image: kindest/node:v1.37.0@sha256:a1ed56cfb0e7b93589bdf97c8cd566405a265939e3620fc4f5de89adff580ae5

# Install kind v0.33.0 (or download the release binary), create the cluster, then install a CNI.
go install sigs.k8s.io/kind@v0.33.0
kind create cluster --name cka --config kind-cka.yaml
kubectl get nodes          # NotReady until a CNI is installed: that is expected
# Install Calico, Cilium or Flannel from its own docs, then:
kubectl get nodes -o wide  # all three nodes Ready, VERSION v1.37.0

kind is ideal for everything except kubeadm itself, since kind nodes are already bootstrapped. For the install and upgrade tasks, practise on two or three small Ubuntu VMs (Multipass, Vagrant or a cheap cloud instance) and follow the kubeadm install docs end to end at least twice. A cheap homelab works too; see the homelab DevOps learning post for options.

Step 4: Set up kubectl for speed

The exam already gives you k and completion. Add two variables and a vim config at the start of the exam; it takes thirty seconds and pays back on every task.

# Run once on each task host you use (or paste at the start of the session).
export do="--dry-run=client -o yaml"     # k create deploy web --image=nginx:1.29.8 $do > web.yaml
export now="--force --grace-period=0"     # k delete pod broken $now
cat >> ~/.vimrc <<'EOF'
set expandtab tabstop=2 shiftwidth=2
EOF

Generate manifests instead of typing them. Here is real output from kubectl create deployment web --image=nginx:1.29.8 --replicas=3 --dry-run=client -o yaml with kubectl v1.37.2 (clients older than v1.34 also print creationTimestamp: null lines):

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy: {}
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - image: nginx:1.29.8
        name: nginx
        resources: {}
status: {}

When you do not remember a field, kubectl explain is faster than the docs:

k explain pod.spec.affinity.nodeAffinity --recursive | less
k explain networkpolicy.spec.ingress
k api-resources | grep -i gateway       # check group and short names
k get pods -A --sort-by=.metadata.creationTimestamp
k get events -A --sort-by=.lastTimestamp | tail -20

Step 5: Drill cluster architecture, RBAC, Helm and etcd (25%)

RBAC tasks are quick points if you can do them without the docs.

k create namespace dev
k create serviceaccount app -n dev
k create role pod-reader --verb=get,list,watch --resource=pods -n dev
k create rolebinding app-pod-reader --role=pod-reader --serviceaccount=dev:app -n dev
k auth can-i list pods -n dev --as=system:serviceaccount:dev:app     # yes
k auth can-i delete pods -n dev --as=system:serviceaccount:dev:app   # no

etcd backup and restore uses etcdctl to save and etcdutl to restore; the Kubernetes etcd docs mark restore through etcdctl as deprecated. Read the cert paths from the etcd static pod rather than guessing.

# On the control plane node, as root.
grep -E "cert-file|key-file|trusted-ca-file|listen-client" /etc/kubernetes/manifests/etcd.yaml
ETCDCTL_API=3 etcdctl --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 \
  snapshot save /opt/etcd-backup.db
etcdutl --write-out=table snapshot status /opt/etcd-backup.db
# Restore into a NEW directory, then point the etcd-data hostPath in etcd.yaml at it.
etcdutl --data-dir /var/lib/etcd-restore snapshot restore /opt/etcd-backup.db

A kubeadm minor upgrade follows the same pattern every time. Package versions come from the pkgs.k8s.io repository for the target minor; 1.37.2-1.1 is current there at the time of writing.

# Control plane node (repo already switched to pkgs.k8s.io/core:/stable:/v1.37/deb/)
apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm='1.37.2-1.1' && apt-mark hold kubeadm
kubeadm upgrade plan
kubeadm upgrade apply v1.37.2
kubectl drain cp-1 --ignore-daemonsets
apt-mark unhold kubelet kubectl && apt-get install -y kubelet='1.37.2-1.1' kubectl='1.37.2-1.1' && apt-mark hold kubelet kubectl
systemctl daemon-reload && systemctl restart kubelet
kubectl uncordon cp-1
# Each worker: upgrade kubeadm, run "kubeadm upgrade node", drain, upgrade kubelet, restart, uncordon.

Helm and Kustomize questions are about installing components, not writing charts. Practise pinning chart versions and reading values.

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm repo update
helm show values metrics-server/metrics-server --version 3.14.0 | less
helm install metrics-server metrics-server/metrics-server --version 3.14.0 \
  -n kube-system --set 'args={--kubelet-insecure-tls}'   # insecure TLS is for kind only
helm list -A

kubectl kustomize overlays/prod     # render without applying
kubectl apply -k overlays/prod

Step 6: Drill services, networking and Gateway API (20%)

Know a default-deny NetworkPolicy and a targeted allow by heart.

# Deny all ingress in namespace "prod", then allow only frontend -> api on 8080.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: prod
spec:
  podSelector: {}
  policyTypes: ["Ingress"]
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: prod
spec:
  podSelector:
    matchLabels: {app: api}
  ingress:
    - from:
        - podSelector:
            matchLabels: {app: frontend}
      ports:
        - {protocol: TCP, port: 8080}

For the Gateway API, the latest release is v1.7.0 from 29 October 2026. In practice, install the standard CRDs and a controller (any implementation works locally), then write HTTPRoutes.

kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.7.0/standard-install.yaml
kubectl get crd | grep gateway.networking.k8s.io

# Route /api to Service "api" port 8080 through an existing Gateway "web-gw".
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: prod
spec:
  parentRefs:
    - name: web-gw
  hostnames: ["shop.example.com"]
  rules:
    - matches:
        - path: {type: PathPrefix, value: /api}
      backendRefs:
        - name: api
          port: 8080

Test connectivity from inside the cluster with a throwaway pod: k run t --image=busybox:1.37.0 --rm -it --restart=Never -- wget -qO- -T 2 http://api.prod:8080. If DNS fails, check CoreDNS pods and the Service's endpoints; my Kubernetes DNS troubleshooting guide has the full sequence.

Step 7: Drill workloads, storage and troubleshooting (55%)

Workloads and storage are mostly short tasks:

k set image deploy/web nginx=nginx:1.29.8 && k rollout status deploy/web
k rollout history deploy/web && k rollout undo deploy/web --to-revision=1
k autoscale deploy web --min=2 --max=5 --cpu=50%      # --cpu replaces the deprecated --cpu-percent
k create configmap app-cfg --from-literal=LOG_LEVEL=debug $do
k get sc                                               # find the default StorageClass

Troubleshooting is 30% and it is where the exam is won. Work outward from the node:

k get nodes; k describe node worker-1 | sed -n '/Conditions/,/Addresses/p'
ssh worker-1
sudo -i
systemctl status kubelet --no-pager
journalctl -u kubelet -n 50 --no-pager            # bad flag, wrong cert path, swap, cgroup driver
cat /var/lib/kubelet/config.yaml | grep -iE "staticPodPath|cgroupDriver"
crictl ps -a | grep -E "apiserver|etcd|scheduler|controller"
crictl logs <container-id> 2>&1 | tail -20
ls /etc/kubernetes/manifests/                     # a typo here breaks a control plane component

Break your kind or VM cluster on purpose: edit a static pod manifest with a wrong image, stop the kubelet, change a Service selector so it has no endpoints, set a wrong --client-ca-file. Fix each one with only the commands above. Do it until it is boring.

Step 8: Follow a six-week plan and use killer.sh last

Every exam purchase includes two killer.sh simulator sessions. The LF page says each gives 36 hours of access from activation, 17 questions, and a different set each time. Save both for the last week, when the score tells you something about readiness rather than about how much you have not studied yet.

Week	Focus	Done when
1	Curriculum read-through, kind cluster, kubectl setup, Pods and Deployments	You create any workload from $do without docs
2	RBAC, ConfigMaps, Secrets, scheduling, autoscaling	auth can-i checks pass first time
3	kubeadm install and upgrade on VMs, etcd backup and restore	Upgrade one minor version in under 15 minutes
4	Services, NetworkPolicy, Gateway API, Ingress, CoreDNS, storage	You debug a Service with no endpoints in 3 minutes
5	Troubleshooting drills, Helm and Kustomize, CRDs and operators	Five broken-cluster drills fixed in a row
6	killer.sh session 1, review, killer.sh session 2, book the exam	Session 2 noticeably better than session 1

Troubleshooting

Symptom	Likely cause	Fix
kubectl says connection refused on a task host	You are on the base host, or the wrong node	exit, then ssh to the host named in the task
Applied YAML fails with "unknown field"	Indentation or wrong API version	k explain <kind>.<field>; regenerate with $do
Node stays NotReady after a kubelet fix	kubelet not restarted, or CNI missing	systemctl daemon-reload && systemctl restart kubelet; check journalctl -u kubelet
API server gone after editing its manifest	Typo in /etc/kubernetes/manifests/kube-apiserver.yaml	Keep a backup copy first; crictl ps -a and crictl logs show the error
etcd restore "worked" but cluster shows old data	etcd still uses the old data dir	Update the etcd-data hostPath in etcd.yaml to the restored directory
Service returns nothing	Selector does not match Pod labels	k get endpointslices -l kubernetes.io/service-name=<svc>; fix the selector
HTTPRoute not attached	Wrong parentRefs name or namespace, or listener does not allow the route	k describe httproute <name> and read the status conditions
Pasted text is mangled in the terminal	Used Ctrl+V, or Ctrl+W closed the tab	Use Ctrl+Shift+V in the terminal; avoid Ctrl+W
Ran out of time with tasks untouched	Spent too long on one high-difficulty task	Flag after about 6 minutes, bank easy tasks, return later

FAQ

What Kubernetes version is the CKA exam on in 2026?

The Linux Foundation CKA page says the exam runs Kubernetes v1.37 as of November 2026. The environment is updated to each new minor release within roughly four to eight weeks, so check the page again in the week you book.

What is the CKA passing score?

You need 66% for the CKA (and the CKAD), and 67% for the CKS, according to the Linux Foundation's certification FAQ. Results arrive by email within 24 hours, and one retake is included with the $445 fee.

Can I use the Kubernetes documentation during the CKA?

Yes. You may use kubernetes.io/docs and kubernetes.io/blog, helm.sh/docs, and, for the CKA only, gateway-api.sigs.k8s.io. You can search kubernetes.io but must not open external search results.

How long should I study for the CKA?

If you already use Kubernetes at work, six weeks at around an hour a day is realistic. Starting from zero, plan two to three months and spend the extra time on Linux, networking and kubeadm on real VMs.

What I check first on any broken cluster, in the exam or in production, is the same short list: is the kubelet running, what does its journal say, are the static pods up, and do the Service endpoints exist. Most failures show up in one of those four places within a minute. Build that habit on a cluster you broke yourself and the exam turns into a speed test rather than a knowledge test. Official references worth bookmarking: the CKA curriculum, the exam tips, kubeadm upgrade docs and the kubectl quick reference.

---

Related: How to Fix Kubernetes CrashLoopBackOff: Causes and Commands (2026), How to Fix Kubernetes Pods Stuck in Pending and Kubernetes RBAC Explained (2026).