CKA Practice Question: Cluster Architecture, Installation and Configuration
A CKA candidate runs 'kubectl get nodes' and sees that a worker node is in the 'NotReady' state. Which command should be used to diagnose the node's kubelet health?
⚠ Common exam trap
CNCF often tests the misconception that the kubelet runs as a Kubernetes pod (like kube-apiserver) and can be debugged with 'kubectl logs', when in reality it is a systemd service on the node, requiring OS-level commands like 'journalctl' or 'systemctl'.
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 the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the most direct way to diagnose kubelet health is to inspect its systemd unit logs using 'journalctl -u kubelet', which shows startup errors, certificate issues, or resource exhaustion that prevent the kubelet from functioning correctly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
systemctl status docker
Why it's wrong here
Docker is only a container runtime, not the agent that registers the node with the cluster; kubelet is responsible for reporting node status and managing pods. Checking `systemctl status docker` might reveal a runtime failure that could indirectly affect kubelet, but it will not show why the kubelet itself is failing to report Ready. In Kubernetes 1.24+, Docker is deprecated as a runtime, and modern clusters use containerd, so this command may not even be relevant. Since the symptom is a NotReady node, the kubelet's own logs are the definitive diagnostic source.
- ✗
kubectl get events --all-namespaces
Why it's wrong here
This command aggregates API events across all namespaces, which are generated by Kubernetes control-plane components and controllers; these events could show a NodeNotReady event, but they are only the symptom, not the underlying cause. Events may not be recorded if the control plane cannot reach the node, or they may be missed due to TTL of events. The actual reason—such as a kubelet certificate expiry or a failed CNI plugin—will be captured in the kubelet's systemd journal on the node, not in the API event stream. Therefore, while events provide a cluster-wide view, they are insufficient for diagnosing the kubelet's local failure.
- ✓
journalctl -u kubelet
Why this is correct
The kubelet runs as a systemd service on each node (in kubeadm and most Linux distributions), so `journalctl -u kubelet` reads the exact logs from that service, including startup errors, API server connection failures, certificate errors, and runtime health check failures. This is the authoritative source for why a node is NotReady, because NodeReady status is only updated when the kubelet successfully posts its status to the control plane. Unlike `kubectl get events`, these journal logs capture the actual exception that prevented the kubelet from functioning.
- ✗
kubectl logs -n kube-system kubelet-<node>
Why it's wrong here
The kubelet is not a pod in the kube-system namespace; it is a host-level system service that manages static pods and the container runtime. Therefore, `kubectl logs` cannot retrieve its logs—there is no such pod, and the command will return an error. Static control-plane components like `kube-apiserver` run as static pods and can be inspected with `kubectl logs`, but the kubelet itself is never a pod. To see kubelet logs, you must access the node directly and use `journalctl -u kubelet`.
Go deeper
Related to this question
Learn chapter
Troubleshooting Cluster and Node Issues
Key term
Kubernetes Node Roles
Kubernetes Node Roles are labels assigned to machines in a cluster that define whether a node runs application containers (worker) or manages the cluster (control plane).
Key term
Network Policies
A Kubernetes resource that controls how pods communicate with each other and with other network endpoints, acting as a firewall for pod-to-pod traffic.
About these practice questions
Courseiva writes every CKA question from scratch — 726 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.