CKA Troubleshooting Practice Question
A node is 'NotReady'. Which THREE steps should you take to troubleshoot?
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
✓
Check kubelet logs with 'journalctl -u kubelet'
Option C is correct because when a node reports NotReady, the kubelet is the primary agent responsible for reporting node status, so inspecting its logs with 'journalctl -u kubelet' reveals errors such as failed certificate rotation, container runtime connectivity issues, or PLEG problems. Option D is correct because 'systemctl status kubelet' on the node quickly shows whether the kubelet service is active, failed, or crash-looping, which is a fundamental first check for a NotReady node. Option E is correct because 'kubectl describe node <node-name>' displays the node's Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure) and events, giving the exact reason and timestamp for the NotReady state. Option A is not appropriate because kube-apiserver logs on the control plane do not diagnose why a specific node's kubelet stopped posting status; the API server merely reflects the missing heartbeats. Option B is not appropriate because rebooting the node immediately is a disruptive action that destroys diagnostic state and should only be done after evidence is gathered, not as a troubleshooting 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.
- ✗
Check the kube-apiserver logs on the control plane
Why it's wrong here
Checking the kube-apiserver logs on the control plane is misleading because those logs track API requests, authentication, and admission control, not the health of a worker node's kubelet. A NotReady state originates from the node controller's evaluation of heartbeats and node conditions that the kubelet itself reports, so if the kubelet is down or misconfigured, the API server only records missing heartbeats, not the root cause. Thus, this step wastes time and diverts attention away from the actual node-side problem.
- ✗
Reboot the node immediately
Why it's wrong here
Rebooting the node immediately is counterproductive as it forcibly terminates all running pods and can cause data loss for stateful workloads, while also increasing pressure on remaining nodes. It might temporarily restart a crashed kubelet but will not resolve persistent issues such as a bad CNI configuration, expired kubelet certificate, or full disk. Moreover, if the underlying cause is a configuration error, the node will only return to NotReady after the reboot, making this a risky and ineffective first step.
- ✓
Check kubelet logs with 'journalctl -u kubelet'
Why this is correct
The kubelet is the node agent that registers the node, runs pods, and continuously posts its status and heartbeat to the control plane, so its logs are the definitive source for why it stopped functioning. Running 'journalctl -u kubelet' reveals systemd unit output including fatal errors like failure to connect to the container runtime via the CRI socket, expired certificates, or resource exhaustion. You can also use '--since' or '-f' to focus on the time the node became NotReady and to watch for live errors, making this a primary diagnostic step.
- ✓
SSH to the node and run 'systemctl status kubelet'
Why this is correct
Running 'systemctl status kubelet' directly on the node provides an immediate status of the kubelet service, showing whether it is active, failed, or entering a crash-loop backoff. This command also displays the most recent journal entries, allowing you to see the exact error that prevented the service from staying up. It is a quick, hands-on check that tells you if you need to start the service or dig further into logs, and it requires SSH access to the affected node.
- ✓
Run 'kubectl describe node <node-name>' to see conditions
Why this is correct
The 'kubectl describe node' command gives a cluster-side view of the node's conditions, including Ready, MemoryPressure, DiskPressure, PIDPressure, and NetworkUnavailable, along with timestamps of condition transitions. A Ready condition with a reason like 'KubeletNotReady' indicates that heartbeats are missing, which points directly to kubelet problems. The Events section may also reveal prior failures, making this a useful first command to run from the control plane to understand the high-level state before SSHing into the node.
Go deeper
Related to this question
Learn chapter
Network Policies and Secure Connectivity
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.
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.
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.