OnCallReady

Lesson 19.5 · CKA Exam Drilling · 13 min read

How points are lost: the classic mistakes

In plain words

Imagine a spelling test where you know every word, but you lose marks because you wrote on the wrong page, spelled your name wrong on top, answered question 5 in the box for question 6, and never read back what you wrote. Nothing to do with spelling, all points lost.

These are the CKA's classic point-losers, and none of them is about Kubernetes: the wrong context or host, the wrong namespace, not verifying, the wrong file or format (pod.txt versus pod, a header line in an answer file), fixing by recreating, doing more than asked, leaving a node half-way, and forgetting the last step (uncordon, restart the kubelet, update fstab). The pre-flight line fixes them: context, namespace, names copied, generator, verify, cat the file, exit the node.

Points lost for nothing

The problem. Most lost points are not missing knowledge: they are the right fix on the wrong cluster, in the wrong namespace, or never checked. A short routine per task removes them.

What you need to know already: contexts and kubeconfig (15.1), namespaces (15.26), ssh to nodes and sudo -i (18.1).

These are the mistakes that cost passing candidates their margin and failing candidates the exam. None of them is about Kubernetes knowledge.

1. Wrong context, wrong host

The task said ssh cka7021 (or use-context hk8s); you stayed where the previous task left you. Every command works, the task looks done, it scores zero because the grader looks at the other cluster.

# the pattern (wk8s, hk8s are placeholders for the contexts a task names)
$ k config current-context
wk8s
$ k config use-context hk8s
Switched to context "hk8s".

The fix is mechanical: the first line of every task is its context/ssh line, typed before reading the rest. In this chapter every drill round starts you in the wrong context deliberately, and "Done in context X" is an objective of its own.

On ssh-based exams the mirror image: you are still on the previous task's host (the prompt says so - read it), or you forgot to ssh at all and k does not exist:

# the pattern (NS, RES, N, hk8s are placeholders for what a task names)
k get pods
k: command not found

2. Wrong namespace

$ k create deploy api --image=nginx:1.27
deployment.apps/api created
$ k get deploy api -n project-tiger
Error from server (NotFound): deployments.apps "api" not found

It went to default. Either -n NS on every command, or, for a task with many commands:

$ k config set-context --current --namespace=project-tiger
Context "hk8s" modified.

...and remember that this now applies to every later task on that context. Generated YAML without -n has no namespace field and lands wherever the current context points when you apply it; with -n NS the generator writes namespace: NS into the YAML - safer.

Cluster-scoped objects (PV, StorageClass, ClusterRole, Node) ignore -n; namespaced ones need it. A RoleBinding in the wrong namespace grants nothing where the task checks.

3. Not verifying

The grader checks state, and you only know state by looking. The five verifications that catch almost everything:

# the pattern (NS, VERB, RES, SUBJECT, N are placeholders for what a task names)
$ k get pods -n NS                                    # Running, READY 1/1, RESTARTS 0
$ k auth can-i VERB RES -n NS --as=SUBJECT            # yes, and a no
$ k exec -n NS toolbox -- wget -qO- -T 2 http://svc   # traffic actually flows
$ k get pvc -n NS                                     # Bound
$ cat /opt/course/N/file                              # the answer, not the command

A typo in an image tag shows up only as ImagePullBackOff a few seconds later. A Service with the wrong targetPort has endpoints and still refuses connections. Only a check catches them.

4. The wrong file, the wrong format

"Write it to /opt/course/5/pods" - you wrote /opt/course/5/pod.txt. "Only the name" - the file contains the header line too:

# the pattern (NS, RES, N, hk8s are placeholders for what a task names)
k top pod -n shop --sort-by=memory | head -1 > /opt/course/5/pod
cat /opt/course/5/pod
NAME      CPU(cores)   MEMORY(bytes)

--no-headers (or tail -n +2) and cat afterwards. Remember that ssh host cmd > file writes the file on the machine you typed it on, not on the host - often exactly what the task wants, sometimes not.

5. Fixing by recreating

"Fix Deployment X" - you deleted it and made a new one. It may pass; it may not (the grader may check the revision history, the uid, labels you did not copy). Fix in place: set, patch, edit, rollout undo. Same for taints: a task that says "make the pod run on the tainted node" is not solved by removing the taint - the grader checks the taint is still there.

6. Doing more than asked

"Allow only role=frontend" - you also allowed the monitoring namespace, just in case. "Exactly get, list" - you added watch. Extra permissions, extra policy peers and extra fields fail "exactly" checks. Read the adverbs: only, exactly, all, without.

7. Leaving things half-way on a node

# the pattern (NS, RES, N, hk8s are placeholders for what a task names)
mv /etc/kubernetes/manifests/kube-apiserver.yaml /tmp/

...and then the task time ran out. You took a component down and did not bring it back; every later task on that cluster fails too. Before editing a static pod manifest, copy it (cp kube-apiserver.yaml /root/kube-apiserver.yaml.bak) and edit in place rather than moving it out and back. After a node task: exit the root shell and the ssh session - the next task's ssh from a task host is nested ssh, which the exam does not support.

8. Forgetting the last step

The pre-flight for each task, in one line

Context, namespace, names copied, generator, verify, cat the file, exit the node.

Why it helps

Candidates who fail the CKA with enough knowledge almost always fail on these, and candidates who pass lose their margin here. The fixes are mechanical habits, which makes them the cheapest points available: typing the context line first, -n on every command, one verification per task, cat on every answer file.

They're also the production mistakes you want to never make: a change applied to the wrong cluster, a fix that deleted and recreated something whose history or UID mattered, extra permissions "just in case", a node left cordoned or a manifest moved out and never moved back. Building these habits for the exam builds them for the job.

Commands in this lesson

cat

FAQ

If I do a task perfectly in the wrong context, do I get anything?

No. The grader checks the cluster the task named. Everything works, the task looks done, and it scores zero because the objects are on the other cluster. The only fix is the habit: type the task's ssh or context line before reading the rest, every time. The drills here start each round in the wrong context on purpose.

Why not just delete and recreate a broken Deployment?

It may pass, but the grader may check things you'd lose: the revision history, the object's uid, labels or annotations you didn't copy. "Fix" means fix in place: set, patch, edit, rollout undo. The same goes for "make the pod run on the tainted node": add a toleration; don't remove the taint, because the check may verify it's still there.

Why did my answer file fail when the content was right?

Usually the format: a header line from kubectl top or get (use --no-headers or tail -n +2), extra columns when the task said "only the name", the wrong file path or extension, or the file written on the wrong machine (ssh host cmd > file writes locally). cat the file after writing it; the file is graded, not the command.

Is it bad to grant a bit more than asked, to be safe?

On the exam, yes: tasks often say "only", "exactly", "all" or "without", and extra permissions, extra NetworkPolicy peers or extra fields fail those checks. In production it's the same principle as least privilege. Read the adverbs in the task, and give exactly what it asks for.

What's the danger of moving a static pod manifest out to edit it?

If time runs out before you move it back, you've taken a control-plane component down, and every later task on that cluster fails too. Copy the manifest to a backup outside the directory and edit it in place instead. And after any node task, exit the root shell and the ssh session, because the next task's ssh would be nested.

In an interview Junior

How do you make sure a change you made actually worked?

Look at the state, not at the command's success message - one verify command per change:

And before that, check you were in the right place: the context or host, and the namespace. Most points lost are the right fix on the wrong cluster, in the wrong namespace, or never checked: a typo in an image tag only shows as ImagePullBackOff seconds later, and a Service with the wrong targetPort still has endpoints. Fix in place rather than recreating, and do only what was asked.

Also asked: Tell me about a mistake you made in a technical task and what you changed afterwards. · Why is fixing in place usually better than deleting and recreating? · What are the "last steps" people forget after node maintenance?

Practise this lesson in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.