CKA Practice Question: Cluster Architecture, Installation & Configuration
Exhibit
``` $ kubectl get nodes NAME STATUS ROLES AGE VERSION master NotReady control-plane,master 10d v1.28.0 node1 Ready <none> 10d v1.28.0 $ kubectl describe node master | grep -A5 Conditions Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- NetworkUnavailable False Mon, 01 Jan 2024 12:00:00 +0000 Mon, 01 Jan 2024 12:00:00 +0000 CalicoIsUp Calico is running on this node MemoryPressure False Mon, 01 Jan 2024 12:00:00 +0000 Mon, 01 Jan 2024 12:00:00 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Mon, 01 Jan 2024 12:00:00 +0000 Mon, 01 Jan 2024 12:00:00 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure PIDPressure False Mon, 01 Jan 2024 12:00:00 +0000 Mon, 01 Jan 2024 12:00:00 +0000 KubeletHasSufficientPID kubelet has sufficient PID available Ready False Mon, 01 Jan 2024 12:00:00 +0000 Mon, 01 Jan 2024 12:00:00 +0000 KubeletNotReady container runtime is down ```
Refer to the exhibit. The master node shows NotReady status. The kubelet is reporting 'container runtime is down'. Which command should be used to investigate and fix this issue?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
systemctl status containerd && systemctl restart containerd
The kubelet is unable to communicate with the container runtime. Since the master uses containerd (common in kubeadm), checking the containerd service status and restarting it is the first step.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl delete node master && kubeadm reset
Why it's wrong here
This is a destructive, disproportionate response to a transient status condition. `kubectl delete node master` removes the node object from the cluster's etcd, and `kubeadm reset` tears down the local control-plane components, deletes etcd data, and resets the kubelet configuration. The NotReady state is almost never caused by a corrupted node; it is typically a health-check failure from the kubelet being unable to reach the container runtime. Reinitializing the node would require regenerating bootstrap tokens, re-joining the control plane, and restoring the cluster state — far more disruption than simply checking and restarting the runtime service.
- ✗
systemctl status kubelet && systemctl restart kubelet
Why it's wrong here
The kubelet is the agent that reports node status, but it is a client of the container runtime through the CRI (Container Runtime Interface). If containerd is stopped or hung, the kubelet cannot create pod sandboxes, so it repeatedly fails its runtime readiness probe and transitions the node to NotReady. Restarting the kubelet service alone does not start the runtime; it only re-runs the same failing CRI connection attempts, and the node will remain NotReady until containerd is operational. The proper troubleshooting sequence is to verify the runtime first, then check kubelet logs after the runtime is healthy.
- ✓
systemctl status containerd && systemctl restart containerd
Why this is correct
In a kubeadm-provisioned cluster, the default and expected container runtime is containerd, with the CRI socket typically located at `/run/containerd/containerd.sock`. If the containerd service has stopped, crashed, or is unresponsive, the kubelet cannot communicate over CRI to create pods or static control-plane pods, causing it to report NotReady. Running `systemctl status containerd` confirms whether the service failed, and `systemctl restart containerd` restores the CRI endpoint so the kubelet can re-establish its connection and recover node status. After restarting, you can validate with `crictl ps` or check that the node becomes Ready within a few minutes.
- ✗
systemctl status docker && systemctl restart docker
Why it's wrong here
This option incorrectly assumes Docker is the configured CRI runtime. Modern kubeadm clusters use containerd by default, and dockershim was removed in Kubernetes 1.24, so Docker is not a drop-in replacement for containerd at the CRI level. Even if Docker is installed on the node, the kubelet will not use it unless explicitly configured through the `--container-runtime-endpoint` flag or the CRI configuration; in a kubeadm setup, that endpoint points to containerd. Restarting Docker when the actual runtime is containerd does nothing to fix the CRI connection broken by containerd being down, so the node would remain NotReady.
Go deeper
Related to this question
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.