CKA Troubleshooting Practice Question
Which THREE of the following are valid steps to troubleshoot a Node in NotReady state? (Choose three)
⚠ Common exam trap
Many candidates confuse control plane components with node-level agents, incorrectly assuming that restarting the kube-apiserver or deleting the node object will fix a node-level NotReady state, when the real issue lies with the kubelet or container runtime on the node itself.
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
✓
Run 'systemctl status kubelet' on the node
Option A is correct because a Node in NotReady state is most often caused by the kubelet service being stopped or failed, and 'systemctl status kubelet' on the node quickly reveals whether the kubelet is active, inactive, or in a failed state. Option C is correct because the kubelet requires a working CRI container runtime such as containerd (or CRI-O) to report node health; if containerd is down, the kubelet cannot manage pods and the node transitions to NotReady, so verifying the runtime is running is a valid troubleshooting step. Option E is correct because 'journalctl -u kubelet' surfaces the kubelet's own error messages (e.g., failed to get node status, CRI connection errors, certificate or cgroup driver problems) that explain why the node is NotReady. Option B is not a valid step because restarting the kube-apiserver on the control plane does not fix a node-local kubelet or runtime failure and would disrupt the whole cluster. Option D is not valid because 'kubectl delete node <node-name>' removes the Node object from the API server rather than re-registering it; the kubelet re-registers only when it restarts and reconnects, so deleting the node is not a troubleshooting step for NotReady.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run 'systemctl status kubelet' on the node
Why this is correct
Running 'systemctl status kubelet' on the node checks whether the kubelet systemd service is active or has failed, showing the current unit state, exit code, and recent process info. This is a logical first step because a Node stuck NotReady often means the kubelet process itself is not running or repeatedly crashing. It directly inspects the node agent, unlike control-plane diagnostics, and can quickly reveal if the service is masked, stopped, or in a failed state.
- ✗
Restart the kube-apiserver on the control plane
Why it's wrong here
The kube-apiserver is a control-plane component that serves the Kubernetes API and persists node objects in etcd; it does not control the kubelet or the container runtime on any worker node. Restarting it cannot fix a node that is NotReady, because the API server only receives NodeStatus updates from the kubelet, it does not create or heal them. Moreover, restarting the API server is risky and unnecessary when the failure is at the node agent or runtime layer, and it would not regenerate any missing kubelet registration.
- ✓
Verify that the container runtime (e.g., containerd) is running
Why this is correct
The kubelet is a CRI client and depends on a running container runtime such as containerd to create sandboxes and start containers. If containerd is stopped, unhealthy, or has lost its socket, the kubelet cannot reconcile pods and will likely mark the node NotReady or fail with CRI timeout errors. Verifying the runtime service with 'systemctl status containerd' or 'crictl ps' ensures the lower-level container layer is responsive before blaming the kubelet or API server.
- ✗
Run 'kubectl delete node <node-name>' to re-register
Why it's wrong here
Running 'kubectl delete node <node-name>' only removes the Node object from the cluster's etcd-backed state; it does not restart or repair the kubelet or container runtime on the node itself. When the kubelet comes back online, it typically creates a new Node object automatically, so a delete is not a meaningful 're-registration' and won't cure an underlying service failure. Deleting a Node can also disrupt workloads that were scheduled on it and is not considered a troubleshooting step for a failing kubelet or runtime.
- ✓
Check the kubelet logs with 'journalctl -u kubelet'
Why this is correct
The kubelet writes structured logs with timestamped entries to the systemd journal, including CRI errors, TLS bootstrap failures, file system issues, and static pod manifest problems. Running 'journalctl -u kubelet' on the node lets you inspect these logs directly to pinpoint why the kubelet is not reporting Ready. This step often reveals the exact error that systemctl status only summarizes, such as a missing CNI binary or an invalid kubeconfig.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
kubectl Command Reference
kubectl is the command-line tool used to interact with and manage Kubernetes clusters by sending commands to the Kubernetes API.
Key term
Container Runtime
A container runtime is software that runs containers by using the host operating system's kernel to isolate processes, manage filesystem layers, and handle networking.
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.