CKA Study Guide: How to Pass the Certified Kubernetes Administrator Exam

The CKA is a practical exam. There are no multiple-choice questions: you get a Linux terminal, 15 to 20 tasks, and two hours to make a set of real clusters look the way each task describes. An automated grader then checks the clusters, not your commands.

That changes how you prepare. Reading about Kubernetes is not enough. You need to be fast and accurate at the command line, and you need to have seen things break. This guide goes through what each domain tests, the commands that come up again and again, and a study plan built around hands-on practice.

Short on time? Read the domain sections, then work through the CKA practice lab. It runs 18 exam-style tasks in a simulated three-node cluster in your browser, with nothing to install.

Who the CKA is for

The CKA is aimed at people who run Kubernetes clusters: DevOps engineers, platform engineers, SREs and cloud engineers. It is the Kubernetes certification most job descriptions name.

There are no formal prerequisites, but you should already be comfortable with:

• Linux at the command line: files and permissions, systemctl and journalctl, editing with vim or nano. The Linux tutorial covers it.
• Containers: images, ports, volumes and logs. See the Docker tutorial.
• Kubernetes basics: Pods, Deployments and Services. If those are new, start with the Kubernetes tutorial and the beginner lab, or consider the KCNA first.

What the exam environment is like

Knowing the environment in advance saves real minutes on the day. According to the Linux Foundation's exam instructions:

• Each task names a host. The task starts with an ssh command; run it, do the work there, then exit back to the base machine. Use sudo -i when you need root.
• kubectl is ready to go. Every task host has the k alias and Bash autocompletion already set up, plus yq, curl and wget.
• It is a remote Linux desktop. In the terminal, copy and paste are Ctrl+Shift+C and Ctrl+Shift+V. Use Ctrl+Alt+W instead of Ctrl+W, which would close the browser tab. The Insert key is disabled, so press i to enter insert mode in vim.
• You may use the documentation: kubernetes.io/docs (including its search), the Kubernetes blog, helm.sh/docs, and for the CKA, the Gateway API docs. Nothing else.
• Don't reboot the base machine. It does not restart your environment.

The exam runs on a recent Kubernetes version (v1.37 at the time of writing) and moves to each new minor release within about four to eight weeks.

Domain 1: Troubleshooting (30%)

The largest domain, and the one that separates a pass from a fail. Tasks usually start with a symptom, such as "the application in namespace X is not reachable" or "node Y is NotReady", and leave the diagnosis to you.

What to practise:

• Pods that will not start. Read the STATUS, then the events:

k get pods -A                      # anything not Running?
k describe pod <pod> -n <ns>       # read Events at the bottom
k get events -n <ns> --sort-by=.lastTimestamp
k logs <pod> -n <ns> --previous    # logs from the container that just crashed

Know the common states by heart: ImagePullBackOff, CrashLoopBackOff, CreateContainerConfigError, OOMKilled and Pending for lack of resources.

• Broken nodes. A NotReady node is almost always the kubelet or the container runtime:

ssh <node>
sudo -i
systemctl status kubelet
journalctl -u kubelet -n 50 --no-pager
systemctl status containerd
crictl ps -a                       # containers, even when the API server is down

See Kubernetes node NotReady for the usual causes.

• Broken control plane components. On kubeadm clusters, the API server, scheduler, controller manager and etcd run as static Pods defined in /etc/kubernetes/manifests/. A typo in one of those files takes the component down. Find it with crictl ps -a and crictl logs <id> when kubectl itself cannot reach the API server.

• Services with no traffic. Check that the Service selector matches the Pod labels and that the endpoints are not empty:

k get svc,endpointslices -n <ns>
k get pods -n <ns> --show-labels

An empty endpoints list is covered in Service has no endpoints.

• Resource usage. k top nodes and k top pods -A --sort-by=memory need metrics-server, which exam clusters usually have.

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

RBAC comes up on almost every attempt. Learn to do it imperatively, without YAML:

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

The same pattern works with create clusterrole and create clusterrolebinding for cluster-wide access. Always verify with auth can-i.

Cluster lifecycle with kubeadm. Know the order of a version upgrade, and keep the official "Upgrading kubeadm clusters" page bookmarked, because the exact package commands depend on the version:

1. Upgrade kubeadm on the control plane node, then run kubeadm upgrade plan and kubeadm upgrade apply v1.x.y.
2. Drain the node, upgrade kubelet and kubectl, then systemctl daemon-reload && systemctl restart kubelet, and uncordon it.
3. For each worker: drain it, upgrade kubeadm, run kubeadm upgrade node, upgrade the kubelet, restart it, uncordon.

Node maintenance is part of that and comes up on its own too:

k cordon node01                         # no new Pods
k drain node01 --ignore-daemonsets      # evict what is there
k uncordon node01                       # back in service

Helm and Kustomize were added to the curriculum recently. You need to be able to install a chart with values, and apply a Kustomize overlay:

helm repo add <name> <url> && helm repo update
helm install <release> <name>/<chart> -n <ns> --create-namespace --set key=value
helm list -A
k apply -k ./overlays/prod

Also know what the extension interfaces are (CNI for networking, CSI for storage, CRI for the container runtime), how to list CRDs with k get crd, and what an operator does.

Domain 3: Services and Networking (20%)

• Services: create them with k expose, and know when to use ClusterIP, NodePort and LoadBalancer.
• NetworkPolicies: a common task is "allow only pods labelled X to reach the database". Start from a default-deny policy and add what is allowed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-allow-api
  namespace: exam
spec:
  podSelector:
    matchLabels:
      app: db
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - port: 5432

• Gateway API and Ingress: the curriculum now covers both, and the Gateway API docs are allowed during the exam. Be able to write an HTTPRoute that sends a hostname or path to a Service. The Kubernetes Ingress tutorial explains how the two compare.
• CoreDNS: Services resolve as <service>.<namespace>.svc.cluster.local. Test from inside the cluster with a throwaway Pod:

k run tmp --rm -it --image=busybox:1.36 --restart=Never -- nslookup web.exam.svc.cluster.local

Domain 4: Workloads and Scheduling (15%)

Mostly imperative commands, plus editing the generated YAML:

k create deployment frontend --image=nginx:1.27 --replicas=3 -n exam
k set image deployment/frontend nginx=nginx:1.28 -n exam
k rollout status deployment/frontend -n exam
k rollout undo deployment/frontend -n exam
k create configmap app-config --from-literal=APP_MODE=production -n exam
k create secret generic db-creds --from-literal=DB_PASSWORD=s3cr3t -n exam

Scheduling tasks involve resource requests and limits, nodeSelector, node affinity, and taints and tolerations. If a Pod will not schedule, the untolerated taint guide shows how to read the scheduler's message. Autoscaling means a HorizontalPodAutoscaler; see the HPA tutorial.

Domain 5: Storage (10%)

The smallest domain, but quick points if you know the shape of the YAML:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
  namespace: exam
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: standard
  resources:
    requests:
      storage: 1Gi

Know the access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany, ReadWriteOncePod), the reclaim policies (Retain and Delete), and how a StorageClass provisions volumes dynamically. If a claim stays Pending, see PVC pending. The Kubernetes storage tutorial covers the rest.

Speed techniques that matter

Two hours for 15 to 20 tasks is about six to eight minutes each. These habits buy that time:

• Let kubectl write the YAML. k run web --image=nginx --dry-run=client -o yaml > web.yaml, edit, then k apply -f web.yaml. It works with most k create subcommands too.
• Save a shortcut for it at the start of the exam: export do="--dry-run=client -o yaml", then k create deploy web --image=nginx $do > web.yaml.
• Look up fields without the docs: k explain pod.spec.containers.livenessProbe is faster than searching.
• Delete without waiting: k delete pod web --grace-period=0 --force when a task just needs it gone.
• Read the task twice: the namespace, the exact names, and the host to ssh into. A correct resource in the wrong namespace scores zero.
• Skip and come back. Each task carries a weight. If one is not working after ten minutes, flag it and move on.

A six-week study plan

At about an hour a day, with Kubernetes basics already in place:

Two practical notes on the plan:

• Build at least one cluster with kubeadm yourself. kind and minikube hide the control plane, and that is exactly what the troubleshooting and upgrade tasks are about.
• Save killer.sh for the end. Each session gives 36 hours of access. Its questions are deliberately harder than the real exam, so a low first score is normal.

Exam-day checklist

• Run the PSI system check on the computer you will use, a day or two before.
• Clear your desk and walls, have your government ID ready, and close every other application.
• In the first minute: check that k works and set your do variable.
• For every task: run the ssh command it gives you, check the namespace, do the work, verify it, then exit.
• Leave ten minutes at the end to revisit flagged tasks.

Frequently Asked Questions

How hard is the CKA exam?

It is hard mainly because of time. Most tasks are not conceptually difficult, but two hours for 15 to 20 hands-on tasks leaves little room to look things up. Candidates who have practised the imperative commands until they are automatic, and who have troubleshot real broken clusters, usually pass.

What is the CKA passing score?

66%. Tasks are weighted differently, so a long multi-step task counts for more than a one-liner. Results are emailed within 24 hours.

How much does the CKA cost, and is there a retake?

The exam costs $445 on its own, and the price includes one free retake and two killer.sh simulator sessions. The Linux Foundation runs regular discounts, and it also sells bundles with courses.

Can I use the Kubernetes documentation during the CKA?

Yes. You can use kubernetes.io/docs including its search, the Kubernetes blog, the Helm docs and the Gateway API docs, in the browser inside the exam environment. You must not open other sites.

How long should I study for the CKA?

With Kubernetes basics already in place, four to eight weeks at about an hour a day is typical. Starting from scratch, add a few weeks for containers and Kubernetes fundamentals first.

Should I take the CKAD or CKA first?

If you run or plan to run clusters, take the CKA first; it is the one DevOps job listings ask for. If you mostly deploy applications onto clusters someone else runs, the CKAD is the better first step. The two overlap a lot, so the second one goes faster.

How long is the CKA valid?

Two years. Passing the CKA again before it expires renews it.