Certified Kubernetes Administrator (CKA) #26: Exam Tips, Time Management, and Patterns People Miss

From #1 through #25, we covered all five domains. This post is a condensed cheat sheet to read one more time right before you walk into the hands-on exam. There’s no new domain here — it gathers only how to run the 2-hour exam and the traps where operators most often bleed points across the whole series. Since this isn’t multiple choice but an exam where you fix and build a real cluster from an empty terminal, the same knowledge plays out differently — and how you run it separates a pass from a fail.

Running the 2 hours #

Working task by task #

CKA gives you about 15–20 tasks to solve within 2 hours. Unlike multiple choice, you don’t split time evenly per question — the point value shown on screen for each task is its priority. Unlike CKAD, CKA mixes high-value tasks that take more than 10 minutes each — like etcd recovery or a cluster upgrade — with low-value tasks finished by a single generator line, all in the same list.

The first rule of time management #

Don’t over-invest in any one task. If a task is eating more time than its point value justifies, build it as far as you can, flag it, and move on. The passing line is 66%, so you can afford to give up a hard task or two. The most common failure is clinging to one stuck 4-point task while missing two 8-point tasks your hands already knew.

Treat troubleshooting as the priority #

Troubleshooting is the largest domain at 30% of CKA. Troubleshooting tasks carry high point values, and once you find the cause, the fix itself is often a single line. But chasing the cause can swallow your time whole, so it’s safer to set a threshold of flagging and moving on if you can’t get a thread on the cause within 5 minutes. Conversely, high-value tasks with a fixed procedure — like etcd recovery — give you the best score per minute once your hands know them.

High value and well-rehearsed first #

Skim the task list from start to finish once, mentally tagging each by difficulty relative to its points. Handle tasks with a fixed procedure first — RBAC creation, writing PV/PVC, exposing a Service — to bank points quickly, and slot the troubleshooting that needs cause tracing and the labor-heavy upgrades in the middle. That’s the route to clearing the passing line.

Refreshing the kubectl speed setup #

Finish the setup from #1 within the first minute after the exam starts. It’s an investment that saves tens of seconds per task.

# kubectl to k
alias k=kubectl

# dry-run + YAML output to do
export do="--dry-run=client -o yaml"

# immediate deletion to now (for deleting and recreating a Pod fast)
export now="--force --grace-period=0"

# completion (extends to k as well)
source <(kubectl completion bash)
complete -o default -F __start_kubectl k

In ~/.vimrc, put settings that prevent YAML indentation mishaps.

set expandtab
set tabstop=2
set shiftwidth=2
set number

CKA frequently has tasks where you need to quickly change just one field in a static Pod manifest or a kubeadm config file. If yq is installed, it’s safer and faster than hand-editing.

# read a specific field
yq '.spec.containers[0].command' /etc/kubernetes/manifests/kube-apiserver.yaml

# edit a field (in-place)
yq -i '.spec.replicas = 3' deploy.yaml

There are a few more vim moves worth drilling into your hands. To indent a whole YAML block, select the lines in visual mode (V), indent one level with >, and repeat with .. When editing a static Pod manifest, a single misaligned space stops kubelet from bringing the Pod back up, so use :set list to tell tabs and spaces apart by eye.

Switch context first of all #

This is the biggest operational difference between CKA and CKAD. CKA has multiple clusters, and each task is only graded if solved in the designated cluster. If you don’t run first the use-context command shown at the top of the task description, even a correct answer ends up in the wrong cluster and scores zero.

# run first, for every task
k config use-context <the context specified in the task>

# check which cluster you're in right now
k config current-context

The same goes for tasks that go inside a node. Tasks like editing a static Pod, restarting kubelet, or taking an etcd snapshot must be solved after you SSH into the designated node. Doing on a worker node what belongs on a control plane node scores nothing.

# connect to the hostname given in the task
ssh node01

# when the task is done, always exit back to the original environment
exit

A common mistake is to start the next task while still SSH’d into a node. Bundling exiting back out once a node task is done into a single motion prevents wrong answers.

Use the official docs fast #

CKA allows you to browse kubernetes.io/docs and its subpages during the exam. So you don’t need to memorize every YAML field or long command. There are two principles for how to run it, though.

• Jump straight to the example via search. Drill the path of typing keywords like etcd backup, kubeadm upgrade, or rbac into the search box at the top of the docs to land straight on the example command and YAML. For long, hard-to-memorize commands — like the etcdctl certificate flags or the kubeadm upgrade procedure — copying from the docs is safer.
• Doc time is exam time too. The timer keeps running while you dig through the docs. Generate the skeleton of frequently used resources instantly with a generator, and use the docs only to confirm long procedures or hard-to-memorize flags.

When you copy a YAML snippet from the docs, the indentation comes along with it, so right after pasting it’s safer to turn off auto-indent interference with :set paste.

Patterns people miss #

These are the recurring patterns where operators bleed points in the hands-on exam. More points are lost to operational mistakes than to lack of knowledge.

1) Not switching context and namespace #

Each task is only graded if solved in the designated cluster and namespace. If you don’t run the use-context command shown in the task description first, even a correct answer ends up in the wrong cluster and scores zero. Since CKA has multiple clusters, this mistake is especially common.

k config use-context <the context specified in the task>
k config set-context --current --namespace=<the task's namespace>

2) Missing etcd certificate flags #

An etcdctl command only works with ETCDCTL_API=3 and all three certificate flags — --cacert, --cert, --key. Miss even one and an auth error stops you from taking or restoring a snapshot. You can find the certificate paths in the --cert-file, --key-file, and --trusted-ca-file of /etc/kubernetes/manifests/etcd.yaml.

ETCDCTL_API=3 etcdctl snapshot save /opt/snap.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

3) Missing drain options #

When draining a node, leaving out --ignore-daemonsets makes the command stall on DaemonSet Pods, and leaving out --delete-emptydir-data makes it block on Pods that use emptyDir. Missing these two options is a regular occurrence in upgrade and node-maintenance tasks.

k drain node01 --ignore-daemonsets --delete-emptydir-data
# when the task is done, make it schedulable again
k uncordon node01

4) Confusion over the static Pod manifest location #

The control plane components (apiserver, etcd, scheduler, controller-manager) run as static Pods in /etc/kubernetes/manifests/. This directory lives on the control plane node, so you won’t see it if you look on a worker node. The kubelet config’s staticPodPath points to exactly this directory. Moving a file out of the directory makes kubelet take the Pod down; putting it back brings it up.

# on the control plane node
ls /etc/kubernetes/manifests/
# which path kubelet watches
grep staticPodPath /var/lib/kubelet/config.yaml

5) Confusion over the upgrade order #

A cluster upgrade has a fixed order. Control plane first, workers after, and within the control plane it’s kubeadm upgrade first, then kubelet and kubectl. Take the nodes one at a time, in the order drain → upgrade → uncordon.

# 1) control plane node: kubeadm first
kubeadm upgrade plan
kubeadm upgrade apply v1.xx.y
# 2) drain the same node, then upgrade kubelet/kubectl and restart
k drain <cp-node> --ignore-daemonsets
# (upgrade kubelet kubectl via apt/yum)
systemctl daemon-reload && systemctl restart kubelet
k uncordon <cp-node>
# 3) for worker nodes, run kubeadm upgrade node then the same procedure

6) Not collecting partial credit #

Even a task you can’t solve perfectly earns points if you build it as far as you can. Even if you couldn’t fix the cause all the way through in a troubleshooting task, applying the possible fix that reflects what you diagnosed can pick up partial credit. Leaving it blank is the biggest waste.

7) Not reading the task to the end #

A single task often comes with multiple conditions. The instruction to take a snapshot may also specify the save path, or an RBAC task may add a condition that it’s limited to a specific namespace. Drop one condition and you only get partial credit. Pin down every condition in the task description before you start.

8) Forgetting to apply or restart after a change #

If you only edit the YAML file and never apply it, or you edit a static Pod manifest but don’t wait for kubelet to pick it up, it never lands on the cluster. After changing a config file, bundle in k apply -f or systemctl restart kubelet as a single motion.

Partial credit and verification #

CKA is graded per task, and some tasks award partial credit. And verify briefly every time you finish a task. For operator tasks, you need to confirm not “I made it” but “it actually came up and is running.”

# whether the resource you made actually came up
k get pod,deploy,svc -n <namespace>

# whether the node returned to Ready after a node task
k get nodes

# whether the control plane components came back up
k get pods -n kube-system

# whether the snapshot file actually got created
ls -l /opt/snap.db

Verification finishes within 30 seconds, but it prevents the most common point loss — “the task you thought you finished had actually failed.” Especially after editing a static Pod, kubelet takes a few seconds to bring the new Pod up, so check k get pods -n kube-system one more time.

Easily confused concept pairs #

Pairs that are easy to confuse in the heat of a task, compressed into a one-line difference each.

taint/toleration and affinity point in opposite directions. A taint rejects a Pod from the node side and a toleration lets it endure that rejection, whereas nodeAffinity, from the Pod side, prefers or forces a specific node. You need both together to complete a dedicated placement like “only this Pod on this node.”

Pre-exam checklist by domain #

The core commands and procedures your hands should produce immediately in each domain.

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

• kubeadm: kubeadm init/join, kubeadm token create --print-join-command
• upgrade: kubeadm upgrade plan/apply, control plane first, workers after
• etcd: the three certificate flags on etcdctl snapshot save/restore
• RBAC: Role/ClusterRole, RoleBinding/ClusterRoleBinding, k auth can-i
• certificates and kubeconfig: kubeadm certs renew, the /etc/kubernetes/pki path

Domain 2: Workloads and Scheduling (15%) #

• k create deploy, k set image, k scale, k rollout status/undo
• scheduling: nodeSelector, nodeAffinity, taint/toleration
• QoS determined by requests/limits, LimitRange, ResourceQuota
• ConfigMap/Secret: envFrom, valueFrom, volume mount

Domain 3: Services and Networking (20%) #

• Service via k expose, type ClusterIP/NodePort/LoadBalancer/ExternalName
• confirm Service selector matches Pod labels
• Ingress rules/paths/backend, IngressClass
• confirm CoreDNS works, NetworkPolicy podSelector/policyTypes (understand default deny)

Domain 4: Storage (10%) #

• PV/PVC static provisioning, matching accessModes and capacity
• StorageClass and dynamic provisioning, reclaimPolicy (Delete/Retain)
• connect a PVC to a Pod via volumeMounts and volumes
• volume expansion (allowVolumeExpansion)

Domain 5: Troubleshooting (30%) #

• Pod: k describe, k logs (--previous), Pending/CrashLoop/ImagePull/OOM patterns
• node: systemctl status kubelet, journalctl -u kubelet, NotReady and pressure
• control plane: /etc/kubernetes/manifests/ static Pods, check containers with crictl ps
• networking and DNS: check endpoints with k get ep, CoreDNS Pod and Service
• certificates: check expiry with openssl x509 -noout -dates, kubeadm certs renew

Pre-exam check for the online-proctored sitting #

CKA is an online-proctored exam in which you connect to a PSI remote terminal to work. Confirm the following before the exam starts.

ID #

• An ID with English Romanization (passport recommended), name matching your registration info exactly
• Present both sides of the ID to the camera as instructed in the proctor chat

Testing environment #

• Everything cleared off the desk, notes and posters removed from the walls
• Use only one screen even with dual monitors, disconnect the secondary display
• Block family and roommates from entering, secure a quiet, private space

System #

• Check in 30 minutes before the exam and pass the system check
• Close background apps, notifications, and VPN; a stable wired network is recommended
• First thing after the exam starts, set up alias k, do, completion, and .vimrc; check context before the first task

Wrap-up #

What this post locked in:

• Running the 2 hours. Points per task are the priority. High value and well-rehearsed first, flag and move on when stuck, no over-investing
• Troubleshooting priority. A 30% domain so points are big, but cut it off at the threshold and move on when cause tracing drags
• Speed setup. alias k, do, now, completion, vim indentation, yq within the first minute
• Context first. CKA has multiple clusters. use-context first for every task, exit after a node task
• Using the docs. Search straight to long commands like etcdctl and kubeadm; doc time is exam time too
• Regular mistakes. context/namespace, etcd certificate flags, drain options, static Pod location, upgrade order, partial credit, not reading the task fully, forgetting to apply/restart
• Partial credit and verification. Build as far as you can and confirm with k get nodes and k get pods -n kube-system
• Easily confused concept pairs, the core procedures per the five domains, the online-proctored check

Next: the full-scale hands-on mock exam #

This is the final post of the series.

In #27 Full-Scale Hands-on Mock Exam (all-domain integrated scenario + explanations), we’ll work through an integrated scenario with a domain distribution close to the real exam and add detailed explanations. It’s the final step — solving it against the clock like the exam environment, and reinforcing the heavyweight domains like troubleshooting and cluster architecture one more time.