CKA Troubleshooting Practice Question
You run 'kubectl get nodes' and one node shows 'NotReady'. Which command should you run first to check the kubelet status on that node?
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
✓
journalctl -u kubelet
The kubelet is responsible for node status. On the node, you can check its logs with journalctl.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
journalctl -u kubelet
Why this is correct
journalctl -u kubelet reads the systemd journal for the kubelet service, the daemon that registers the node and reports its status to the control plane. When a node is NotReady, kubelet logs will contain the underlying error, such as a failed heartbeat to the API server, CNI interface issues, or a misconfigured kubeconfig. This is the authoritative source because kubelet runs as a systemd unit and its stderr/stdout are captured in the journal.
- ✗
kubectl describe node <node-name>
Why it's wrong here
kubectl describe node <node-name> queries the API server for the node object and displays its conditions, including Ready=False, along with address and capacity info. It does not show logs from the kubelet process itself; it only shows the API-side view of the node's status. While useful to confirm the node is NotReady, it cannot reveal the root cause—like a kubelet crash loop or a CNI plugin failure—because that diagnostic output lives in the kubelet's journal, not in the Describe output.
- ✗
cat /var/log/syslog | grep kubelet
Why it's wrong here
In distributions using classic syslog, kubelet output might be written to /var/log/syslog, but systemd-based systems route service output through the journald daemon, so this file may be incomplete or omit the kubelet entirely. journalctl -u kubelet is the canonical method because it reads the unit's complete output, including multi-line stack traces, without depending on rsyslog filters and rotation. Grepping /var/log/syslog also lacks the structured fields and filtered view for the kubelet unit.
- ✗
systemctl status kube-apiserver
Why it's wrong here
systemctl status kube-apiserver checks the API server process on the control plane, not the kubelet on the worker node. A node's NotReady condition is generated by the kubelet's failure to post heartbeats, or by the controller-manager after missing the grace period, so the kube-apiserver status is irrelevant to the node's readiness. This command would help if the entire cluster was unreachable, but for one Node NotReady, the kubelet is the correct service to inspect.
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.