CKA Troubleshooting Practice Question
A node in the cluster is showing status 'NotReady'. You run 'kubectl describe node worker1' and see that the kubelet has not posted node status for more than 1 minute. Which command should you run on the node to check the kubelet logs?
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
On systemd-based systems, 'journalctl -u kubelet' is the standard command to view kubelet logs. 'journalctl -f -u kubelet' follows the log, but the question asks for checking logs, not following.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
cat /var/log/kubelet/kubelet.log
Why it's wrong here
Reading /var/log/kubelet/kubelet.log is unreliable on modern systemd-based distributions because kubelet typically logs to the journal, not to a flat file. Even if the file exists, it may be stale or contain only early boot logs, while current errors go to journald. The path /var/log/kubelet.log is also not standard across all distros, so you may miss critical runtime errors that journalctl -u kubelet would capture.
- ✗
kubectl logs kubelet -n kube-system
Why it's wrong here
kubectl logs is designed to retrieve logs from a pod container, but kubelet is a system-level daemon running directly on the host, not as a pod in the kube-system namespace. The command 'kubectl logs kubelet -n kube-system' would fail because no pod named kubelet exists in that namespace; even with a pod selector, this approach cannot access the kubelet's journal. To inspect kubelet logs, you must use journalctl or check a file on the node, not kubectl.
- ✗
systemctl restart kubelet
Why it's wrong here
Running systemctl restart kubelet is a reactive measure that might temporarily bring the node back to Ready, but it does not uncover the root cause of the NotReady status. In fact, if kubelet is crash-looping due to a misconfiguration or CNI issue, restarting it only causes repeated flapping and may exacerbate instability. The correct first step is to inspect the kubelet logs to identify why it is failing, not to blindly restart the service.
- ✓
journalctl -u kubelet
Why this is correct
journalctl -u kubelet is the correct command on systemd-based systems because the kubelet runs as a systemd service and writes its logs to the systemd journal. This command filters the journal to show only kubelet entries, revealing errors such as failed API server connectivity, CNI plugin failures, or node lease renewal problems. These logs are essential for diagnosing why the node is NotReady, as they contain the actual failure messages that file-based logs or kubectl cannot provide.
Go deeper
Related to this question
About these practice questions
This CKA question is part of Courseiva's 726-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.