Home › Certifications › CKA › Troubleshooting — Cluster and Nodes
45 multiple-choice questions and 14 flashcards on Troubleshooting — Cluster and Nodes, about 15% of the CKA bank. Every one carries a written rationale.
Troubleshooting — Cluster and Nodes is one of 6 chapters in CoStudy's CKA — Certified Kubernetes Administrator bank, and it holds 45 of the bank's 300 multiple-choice questions — roughly 15% of the total. That proportion is not arbitrary: chapters follow the certifying body's published exam outline, and the number of questions in each is set by that domain's published weight, so the share of your practice time this chapter takes matches the share of the real exam it accounts for.
Studying by chapter is worth doing once you have a diagnostic score. A single overall percentage tells you whether you are close; it does not tell you which domain is dragging. Working a weak chapter in isolation, and re-testing it in isolation, is the fastest way to move a score that has stalled — and it is why the mock exams in CoStudy report by domain rather than as one number.
10 questions drawn from this chapter, with the full rationale shown — the controlling principle behind the right answer, and why each wrong option tempts and fails.
kubectl exec fails with 'error: unable to upgrade connection'. Likely cause?
Answer: A — The apiserver cannot reach or trust the kubelet on that node
A is right: exec, logs and port-forward are proxied from the apiserver to the kubelet on port 10250, so an unreachable kubelet or an untrusted serving certificate breaks the connection upgrade. B produces a forbidden message naming the subresource. C causes at most a version-skew warning. D returns a container-state error instead.
You need to confirm which containers the runtime is actually running on a node, independent of what the API server believes. Which command is MOST appropriate?
Answer: A — `crictl ps`, which queries the CRI endpoint directly on that node
A) Correct — `crictl ps` talks to the CRI socket on the host and shows the runtime's own view, which is exactly the independent evidence you want when API state is suspect. B) and D) are both useful but derive entirely from the API server, so they cannot corroborate or contradict it. C) lists images rather than running containers, answering a neighbouring question about pull state.
After running `etcdctl snapshot restore` into a new directory on a kubeadm node, etcd still serves the old data. What step was MOST likely missed?
Answer: D — Pointing the etcd static pod's data hostPath at the restored directory
D) Correct — restore only populates a directory on disk; etcd keeps reading whatever path its static pod mounts, so you must update the manifest's hostPath (or move the data) and let the kubelet restart the pod. A) would rewrite the manifest but discards the restore you just performed. B) matters for older etcdctl versions but a wrong API version fails the restore outright rather than producing stale reads. C) is unrelated — namespace churn does not change etcd's storage path.
You restore etcd from a snapshot taken six hours ago. Which consequence should you communicate to stakeholders as MOST significant?
Answer: C — Objects created or changed in the last six hours are gone from cluster state
C) Correct — a restore returns the API's object store to the snapshot instant, so anything written afterwards (Deployments, Secrets, scaling changes) disappears. D) is the most dangerous misunderstanding: etcd stores the PV and PVC objects, never the data inside the volumes, which is untouched. B) confuses restore with certificate management; the PKI on disk is unaffected. A) misattributes state to etcd — images live in the node's runtime store.
During `kubeadm upgrade`, which sequence describes the correct order of operations on the FIRST control-plane node?
Answer: B — Upgrade the kubeadm binary, run `kubeadm upgrade plan`, then `kubeadm upgrade apply`
B) Correct — kubeadm itself must be at the target version before it can plan and apply the upgrade of the control-plane components; kubelet and kubectl packages are upgraded afterwards. A) is direction-reversed: applying with the old kubeadm binary cannot produce the new version. C) upgrades the node agent ahead of the control plane, violating the version-skew ordering. D) uses `kubeadm upgrade node`, which is the subcommand for additional control-plane and worker nodes, not the first one.
After 'kubeadm init', 'kubectl get nodes' shows the node NotReady. What is the most common cause?
Answer: C — No CNI pod network add-on is installed yet, so kubelet reports NotReady
C is right: kubeadm init deliberately installs no pod network, and kubelet holds the node NotReady with a NetworkReady=false condition until a CNI plugin such as Calico, Flannel or Cilium is applied. A is tempting but self-refuting: if etcd were down, kubectl get nodes would not return at all. B would prevent the node from registering in the first place, so it would not appear in the list. D concerns joining workers, not the control-plane node created by init, and an expired token blocks registration rather than producing a registered NotReady node.
Several pods on one node are stuck in ContainerCreating, and `crictl ps -a` on that node shows no corresponding containers at all. Which layer should you examine NEXT?
Answer: C — The kubelet journal and the container runtime service on that node
C) Correct — the pods are already bound to the node, so the failure is between the kubelet and the runtime; the kubelet journal and containerd's status are where sandbox-creation errors appear. B) is already answered: placement clearly succeeded, or the pods would be Pending. A) governs the pace of replacement, not whether a bound pod's containers get created. D) acts before the object exists, whereas these pods exist and are assigned.
Before upgrading the kubelet on a worker node, which action BEST protects running workloads?
Answer: D — `kubectl drain <node> --ignore-daemonsets`, evicting pods before the upgrade
D) Correct — drain cordons the node and evicts its pods through the eviction API, honouring PodDisruptionBudgets; --ignore-daemonsets is needed because DaemonSet pods cannot be rescheduled elsewhere. A) is half-right with the critical caveat missing: cordon stops new placements but leaves existing pods in place. B) uses a soft preference the scheduler may ignore and evicts nothing. C) is a real but wildly disproportionate outage across the whole cluster.
A node shows NotReady. `systemctl status kubelet` reports the service as active (running). What is the BEST next diagnostic step?
Answer: C — Run `journalctl -u kubelet -n 200` and read the node's reported conditions
C) Correct — a running kubelet that cannot report Ready is telling you something downstream failed, and its journal plus `kubectl describe node` conditions name it (runtime not responding, CNI not initialised, disk pressure). B) is destructive theatre: deleting the Node object does not fix the underlying cause and the recreated object reports the same condition. A) and D) are both blind remediation ahead of a diagnosis, and D) additionally assumes the runtime is at fault before you have any evidence.
`kubectl get nodes` on a control-plane host returns `The connection to the server 127.0.0.1:6443 was refused`. Every other node still runs its workloads normally. What does this evidence MOST directly imply?
Answer: B — The kube-apiserver static pod is not serving, so the cluster API is down
B) Correct — a refused TCP connection on 6443 means nothing is listening: the API server process itself is not up. Running workloads persist because kubelets keep existing containers alive without the API. D) tempts because leader election failures are real, but the scheduler never terminates API traffic and its loss shows up as unscheduled pods, not a refused socket. C) reverses the dependency: kubelets are clients of the API server, so their state cannot close its listener. A) is a genuine failure mode, but kubectl talks to the host's port 6443 over the node network, not through pod networking.
4 cards from the 14 in this chapter.
Name the common causes of a node reporting NotReady.
The kubelet is stopped or crash-looping • the container runtime is down so the kubelet cannot report • no CNI plugin is installed or configured, leaving the network unready • disk, memory or PID pressure • expired kubelet client certificates • the node cannot reach the API server.
The container runtime is suspected — how do you confirm containerd is healthy?
'systemctl status containerd' and 'journalctl -u containerd' for the service, then 'crictl info' to confirm the runtime answers and reports a configured CNI, and 'crictl images' plus 'crictl ps' to confirm it can list images and running containers.
How do you check whether the cluster's certificates have expired, and how do you fix it?
Run 'kubeadm certs check-expiration' on the control-plane node for a per-certificate table of expiry dates. Renew with 'kubeadm certs renew all' (or a single certificate by name), then restart the static-pod components; if the admin kubeconfig also expired, regenerate it before kubectl will authenticate again.
Where does the kubelet read static pod manifests from, and how does that help recovery?
From /etc/kubernetes/manifests by default (the staticPodPath in the kubelet config). The kubeadm control-plane components live there as static pods, so editing or restoring those YAML files and letting the kubelet re-read them is how you repair an API server that will not start.
These are a sample. The full Troubleshooting — Cluster and Nodes chapter runs 59 items with per-chapter progress tracking, on the web and in the iOS app.