CKA Exam Drilling: interview questions

You have a CKA. What does it prove, and what does it not? Mid

It proves you can operate a cluster fast and correctly under pressure: 15-20 hands-on tasks in 2 hours on real clusters, graded only on the end state - workloads, Services and NetworkPolicies, storage, RBAC, kubeadm upgrades, etcd backup and restore, and troubleshooting broken nodes and control planes (30% of the exam). It also proves habits: the right context and namespace every time, generators instead of hand-written YAML, verifying every change.

It does not prove:

• design judgement - how to lay out namespaces, RBAC or network policies for many teams;
• running production over time: monitoring, capacity, upgrades on schedule, on-call;
• managed cloud clusters, delivery pipelines, or the application side.

So: a strong signal of hands-on skill, not of architecture or operating experience. Pair it with being able to explain why - the questions in this chapter's debrief.

Also asked: How do you work efficiently with kubectl day to day? · How do you make sure a change you made actually worked? · How do you prioritise when you have more tasks than time?

The CKA is graded on end state only. How does that change how you work? Junior

A script checks the cluster and the files afterwards; it never reads your history. So:

• How you got there does not matter - a generator, edited YAML or kubectl patch all count. Use the fastest.
• Where matters completely: the right objects on the wrong cluster or in the wrong namespace score zero. The first thing typed for every task is its ssh host or kubectl config use-context line, then -n NS on every command.
• Names and paths are exact: /opt/course/3/pod.txt is not /opt/course/3/pod. Copy them from the task text.
• Nothing is checked while you work, so verifying is your job: get, describe, auth can-i, cat the answer file.
• Partial credit exists - a task is several checks, so an 80% task still scores most of its points; a task never started scores none.
• A rollout still running when time is up may be graded as not ready.

Also asked: How do you keep from making changes in the wrong cluster or namespace? · How did you prepare for the CKA? · What is allowed during the CKA exam?

Learn it: 19.1 The exam: what it is and what it is not

A Deployment has no ready pods. What are your first commands? Junior

1. k get pods -n NS - the STATUS column says which part of the failure catalogue you are in: Pending, ImagePullBackOff, CrashLoopBackOff, CreateContainerConfigError, Running but 0/1.
2. k describe pod POD -n NS - the Events at the bottom and Last State (exit code, reason). The last event names the object to fix: the scheduler's reason, the registry's answer, a missing ConfigMap key, a failing probe.
3. k logs POD -n NS --previous - for a crash loop, the run that died.
4. If no pods exist at all: k describe rs -n NS - quota, Pod Security or a missing ServiceAccount rejects them there.

Then fix in place - k set image, k set env, k set resources, k edit, k rollout undo - rather than deleting and recreating, and verify with k get pods until 1/1 Running with no new restarts.

Also asked: A Service exists and its pods are running, but there is no traffic. What do you check? · How would you give a ServiceAccount read access to pods in one namespace, and prove it? · Which domains carry the most weight in the CKA, and how does that shape practice?

Learn it: 19.2 The five domains and the tasks they turn into

How do you create a Kubernetes manifest quickly without writing it from scratch? Junior

Never start from a blank file:

• Generators with $do (export do="--dry-run=client -o yaml"): k run web --image=nginx:1.27 --port=80 $do > web.yaml, k create deploy ... $do, k create cronjob ... --schedule ... $do. Edit the file, k apply -f.
• Many tasks need no file at all - the command is the answer: k create role/rolebinding, k expose, k set image/resources/env, k scale, k autoscale, k label, k taint, k create job --from=cronjob/X.
• Kinds without a generator: copy the example from the docs page (PV, PVC, StorageClass, NetworkPolicy), or generate a Deployment and change it (a DaemonSet: change the kind, delete replicas and strategy).
• Field names: k explain cronjob.spec.jobTemplate.spec --recursive in two seconds.
• Immutable pod fields: k edit saves your copy when it refuses; k replace --force -f that file.

Plus the setup: alias k=kubectl, completion with complete -o default -F __start_kubectl k, and an editor that uses spaces, not tabs.

Also asked: How do you find the right field name or structure for a Kubernetes object? · A pod field you need to change is immutable. What do you do? · Why does Tab completion not work for an alias without extra setup?

Learn it: 19.3 The speed kit: alias, $do, generators, editors, explain

How do you prioritise when you have more tasks than time? Junior

By points per minute, in passes:

1. First pass: read each task, run its context line, decide in seconds. Quick ones (contexts into a file, an HPA, an RBAC role) - do them, verify, move on. Long or unclear ones - flag and skip. Exception: if the cluster itself is broken, fix it now, other tasks depend on it.
2. Second pass: the flagged ones, heaviest first.
3. Third pass: re-read every task against what you did - names, namespace, paths, "only", "exactly". This finds more points than any other ten minutes.

And two rules: the eight-minute rule - when a task has used its budget and you are not converging, note where you are, flag it, move on; and partial credit - before skipping a long task, do the 30-second parts. Do not stare at rollouts; check them later. In practice, attempts records your time per drill against its budget.

The same applies outside exams: in an incident, timebox a hypothesis instead of spending 30 minutes on one.

Also asked: During an incident you have spent 30 minutes on one hypothesis without progress. What do you do? · How do you estimate time for operational work like an upgrade? · Why is partial work on a task better than none?

Learn it: 19.4 Time: budgets, triage, skipping, partial credit

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

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

• workloads: k get pods -n NS - Running, 1/1, restarts not climbing; k rollout status for a Deployment;
• Services: k get endpointslices, then a real request from a pod (k exec ... -- wget -qO- svc:port);
• RBAC: k auth can-i ... --as=... - one check that must say yes and one that must say no;
• answer files: cat them - the file is what counts, not the command;
• nodes: k get nodes Ready, and the persistent setting (fstab, enabled units) checked.

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?

Learn it: 19.5 How points are lost: the classic mistakes

How do you find information quickly when you are working with an unfamiliar Kubernetes feature? Junior

In order of speed:

1. kubectl explain - field names and shapes without leaving the terminal: k explain pod.spec.containers.livenessProbe --recursive; without --recursive you get descriptions and defaults.
2. -h on the command - k create role -h shows the flags and examples.
3. The source of truth on the machine - for control-plane components the static pod manifest (sudo grep cert-file /etc/kubernetes/manifests/etcd.yaml gives etcdctl's TLS flags faster than any page).
4. The docs, by search, to a known page - "Configure a Pod to Use a PersistentVolume for Storage", "Network Policies", "Using RBAC Authorization", the kubectl Quick Reference. Know which page has the example you need.

Then copy and trim: paste the example, delete what the task does not ask for, rename everything - never keep the example's namespace or labels by accident.

Also asked: How do you write a NetworkPolicy under time pressure without mistakes? · Why prefer kubectl explain over the documentation website? · Which documentation pages would you bookmark for Kubernetes operations work?

Learn it: 19.6 Using the docs at exam speed

How do you practise a technical skill so it sticks? Junior

By working on the misses, not the things you already know:

• Log every miss with its reason and the rule that fixes it - a plain greppable file: date, source, task, result, minutes, why, fix.
• Classify the why, because each kind has a different cure: knowledge (re-read, then drill), speed (the drill again until under budget), reading (a pre-flight routine), environment (fix the habit or the editor settings).
• Spaced repetition: redo the miss the same day without hints, a fresh randomized round two or three days later, and strike it once it is under budget twice in a row. Assisted attempts (looked at the solution) do not count as done from memory.
• Measure: time per attempt, against a budget.

The same idea scales to a team: a blameless log of incidents with symptom, cause and fix, turned into runbooks and drills, so a mistake is made once.

Also asked: How do you learn from mistakes, yours or the team's? · How would you build a runbook culture on a platform team? · How do you know when you are ready for an exam or an on-call rotation?

Learn it: 19.42 The wrong-answer log, and how the app repeats your misses

How do you prepare for a high-stakes change, like a production upgrade? Junior

The same way as for the exam - rehearse, check the environment, then follow a calm routine on the day:

• Rehearse under real conditions: a dry run on a copy (a staging cluster, a mock exam), timed; redo every step that went wrong until it is clean, and write down why it went wrong.
• Check the environment days before: access, tooling, versions, backups taken and a restore tested - the equivalent of the exam's system check.
• Pick the moment: a time you are sharp, where a failure or a retry does not wreck the week; nothing new the day before.
• On the day: a written order of steps, verify after each one, never skip the last steps (uncordon, restart, persist) - on exam day that includes the setup on each host (export do=...) and exiting every node session, and stop starting new work near the end of the window - verify what is done.
• Afterwards: record what happened, and the weakest part goes to the top of the list for next time.

Also asked: How do you stay calm and effective under time pressure? · Why did you decide to get the CKA, and was it worth it? · What would you do if the platform failed in the middle of a timed task?

Learn it: 19.43 The last two weeks and exam day