Free study guide · DevOps

How to pass the Certified Kubernetes Administrator (CKA)

What the exam covers, how to plan your study, and how to read its questions. From the CertLumen course for this exam, kept up to date with the official exam guide.

What the exam covers

A study plan that works

The default path. It covers all 20 lessons and all 10 labs in order, with a section drill after each section and flashcards on most days. Troubleshooting (30%) and cluster setup (25%) get the most days. Mock exams and the first killer.sh session fill the last three days, as the real exam is hands-on and wants stamina. Lab days are longer than lesson days: the kubeadm lab alone is about two hours. Plan on about 1.5–3 hours a day.

Exam strategy

How the exam works

The CKA is a hands-on, performance-based exam. You do not pick answers: you sit at a Linux remote desktop with a terminal and solve a series of tasks on live Kubernetes clusters, then an automatic grader checks the state of the clusters. It is delivered online and proctored by PSI. The exam environment follows the current Kubernetes minor version (v1.37 today); the Linux Foundation updates it within about four to eight weeks of a new release.

What you get at the keyboard

• A remote desktop opened inside the PSI Secure Browser, with a terminal, a Firefox window for the allowed documentation and a VSCodium editor (extensions are disabled).
• kubectl with the k alias and bash completion, yq, curl, wget and man pages are already installed on the work hosts.
• Each task names the cluster or host to use. For node work you ssh <node>, use sudo -i for root, and exit to come back to the base system. Nested SSH does not work and you must not reboot base.
• A timer shows the minutes left, with alerts at 30, 15 and 5 minutes. Pause does not stop it, and a lost connection does not give time back.
• Copy and paste in the terminal use Ctrl+Shift+C and Ctrl+Shift+V. The Insert key is disabled, so in vi press i to insert and Esc to leave insert mode.

The documentation you may open

You may use only the sites in the Linux Foundation *Resources Allowed* document, in the Firefox window inside the exam. For the CKA they are the Kubernetes documentation (kubernetes.io/docs) and blog (kubernetes.io/blog), the Helm documentation (helm.sh/docs) and the Gateway API documentation (gateway-api.sigs.k8s.io, CKA only), plus the task-specific links in each task's Quick Reference box. Searching inside kubernetes.io/docs is allowed, but you must not open external search results. Documentation installed with the operating system (under /usr/share) is allowed too.

Pacing

With 15 to 20 tasks in 120 minutes you have about six to eight minutes per task on average, and tasks vary: a RBAC task may take two minutes, a broken control plane fifteen. The weights are the lever. Do the quick tasks first, bank those points, and return to the long ones.

1. First 5 minutes: confirm your tools work (k get nodes), set up aliases and vim settings, and skim the task list if the UI lets you.
2. First pass (about 70 minutes): take tasks in order, skip any that need more than ten minutes, and write the skipped task numbers in a scratch file on the remote desktop. Notes on paper or devices are not allowed.
3. Second pass (about 35 minutes): return to the skipped tasks, highest weight first.
4. Last 10 minutes: re-check each task you finished: right cluster, right namespace, object exists, Pods Running. Fix any partial work.

Reading a task

• Cluster or context first: if a task names a cluster, context or host, switch before you do anything (kubectl config use-context <name>, or ssh <node>). Doing the right fix on the wrong cluster scores zero.
• Namespace: note it, and add -n <ns> to every command, or set it with kubectl config set-context --current --namespace=<ns> and set it back afterwards.
• Exact names: use the object, file, label, port and path names from the task, character for character. The grader looks for those.
• What is checked: tasks end in a state (a Pod Running, a file with specific content, a Service reachable). Verify that state with a command before you move on.
• Files to write: save outputs where the task says, for example kubectl logs ... > /opt/out.log. Check the file exists and is not empty.
• Do not do extra: deleting or changing objects the task did not mention can break another task's check.

What each domain really tests

Traps typical of this exam

• Wrong context, host or namespace. The most expensive mistake and it costs a whole task. Look at the prompt, kubectl config current-context and hostname before every task.
• Editing the mirror Pod. Deleting kube-apiserver-cp1 does nothing: the file in /etc/kubernetes/manifests is the source. The kubelet reloads it in seconds.
• Forgetting to leave ssh. Run exit back to the base host before the next kubectl task, or you run kubectl where it has no kubeconfig.
• RoleBinding with a ClusterRole is still namespaced. Only a ClusterRoleBinding grants cluster-wide access.
• storageClassName omitted versus "". Omitted means the default class; empty means none, which is how you bind to a pre-made PV.
• etcd restore needs etcdutl snapshot restore --data-dir <new dir> and then the etcd manifest's hostPath pointed at the new directory.
• Upgrading in the wrong order: control plane first, upgrade apply once, upgrade node elsewhere, drain before kubelet, uncordon after.
• drain flags: --ignore-daemonsets is almost always needed, --delete-emptydir-data when emptyDir Pods run.
• A NetworkPolicy dash: namespaceSelector and podSelector in one list item are AND, in two items OR. A default-deny egress policy also blocks DNS.
• Probes: readiness removes a Pod from Service endpoints, liveness restarts the container, startup protects slow starters.
• Pending Pods: no events at all points to a dead scheduler; FailedScheduling means the scheduler works and found no fit.
• Leaving files or Pods in a broken state while you try fixes. Undo experiments that did not work.

Debugging tactics when a command fails

• Read the error line: forbidden is RBAC, no matches for kind is a missing CRD or wrong apiVersion, connection refused is a down component, not found is a wrong name or namespace.
• kubectl explain <kind>.spec --recursive | less lists valid fields; kubectl api-resources lists kinds and short names.
• kubectl describe shows Events at the bottom, where most causes are written.
• kubectl get events -A --sort-by=.lastTimestamp | tail shows what just happened cluster-wide.
• When kubectl itself is down, drop to the node: systemctl status kubelet, journalctl -u kubelet, crictl ps -a, crictl logs.

Using this course

Words that point to the answer

Phrases in a question that usually point to one answer. The course has the full list.

Revise from the cheat sheet

The course's cheat sheet has a page for each of these:

• Cluster architecture, installation and configuration
• Workloads and scheduling
• Services and networking
• Storage
• Troubleshooting