CKA Troubleshooting Practice Question
A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?
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
✓
systemctl start kubelet
Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.
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 it's wrong here
journalctl -u kubelet is a diagnostic command that retrieves the kubelet's systemd journal entries, which can reveal crashes, startup failures, or configuration errors. However, reading logs is purely passive and does not alter the state of the kubelet service; if the service is stopped or failed, the node remains NotReady because the kubelet is not running to report status. You must pair log inspection with an action like systemctl start kubelet to actually recover the node.
- ✓
systemctl start kubelet
Why this is correct
systemctl start kubelet directly addresses the most common cause of a NotReady node: the kubelet service being stopped or inactive. When started, the kubelet initializes, connects to the API server, and begins sending its Node status heartbeat, which the node controller uses to mark the node Ready once all conditions (such as memory, disk, and runtime) are satisfied. This is the immediate, targeted remediation for a node stuck in NotReady due to a down kubelet, and it is the correct first step after confirming the service is not running.
- ✗
kubectl delete node <node-name>
Why it's wrong here
kubectl delete node <node-name> removes the Node object from the cluster's API server, but it has zero effect on the local kubelet process running on the node itself. If the kubelet is stopped, deleting the node does not start it; the node will simply disappear from cluster state until the kubelet re-registers it, which only happens if the kubelet runs. Worse, deleting a node can trigger cluster logic that evicts pods or cleans up resources, so this action is both ineffective and potentially disruptive, making it a poor troubleshooting choice for a NotReady node caused by a local service issue.
- ✗
systemctl restart docker
Why it's wrong here
systemctl restart docker assumes Docker is the container runtime and that restarting it will resolve the NotReady state, but many modern Kubernetes clusters use containerd or CRI-O instead, making this command irrelevant. Even if Docker is the runtime, restarting it does not address a stopped kubelet; the kubelet is the component that reports node readiness, so if it is down, no runtime restart will change the NotReady condition. This option targets the wrong service and is at best a blind restart that may introduce additional downtime without fixing the actual problem.
Go deeper
Related to this question
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.