CKA Node NotReady but kubelet running Practice Question
You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?
⚠ Common exam trap
Test-takers frequently confuse 'cordon' (which affects scheduling but not readiness) with 'NotReady' (which indicates a health or connectivity failure), leading them to pick Option C when the node is actually unreachable.
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
✓
Network connectivity issue between kubelet and API server
When a node is NotReady but the kubelet is running, the most common cause is a network connectivity issue between the kubelet and the API server. The kubelet reports node status via periodic heartbeats (node-status-update-frequency, default 10s) and if the API server cannot receive these updates due to network problems (e.g., firewall rules, DNS resolution failure, or dropped packets), the node controller marks the node as NotReady after the node-monitor-grace-period (default 40s). The kubelet being running eliminates installation issues, and the API server being down would affect all nodes, not just one.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The kubelet is not installed
Why it's wrong here
This is incorrect. The scenario states the kubelet is running, which presumes the kubelet binary is installed and the service is active. If the kubelet were not installed, you would not see a running kubelet process, and the node would likely not even register with the cluster. A missing kubelet would cause a completely different symptom, such as the node never appearing or being in a perpetual register/unregister loop, not a transition from Ready to NotReady.
- ✓
Network connectivity issue between kubelet and API server
Why this is correct
This is the correct answer. The kubelet is responsible for reporting the node's status to the API server through periodic heartbeat updates. When there is a network connectivity issue between the kubelet and the API server, the API server's node controller does not receive these updates for longer than the node-monitor-grace-period (default 40 seconds). As a result, the node is marked as NotReady, even though the kubelet process itself continues to run locally and can still manage containers on the node.
- ✗
The node has been cordoned
Why it's wrong here
This is incorrect because cordoning a node (kubectl cordon) only marks it as unschedulable, meaning new Pods will not be scheduled onto it. Cordon does not alter or affect the node's Ready condition; a cordoned node with a healthy kubelet and API connectivity will still show Ready. Node readiness is determined entirely by the API server's ability to receive heartbeats from the kubelet, not by the node's scheduling state.
- ✗
The API server is down
Why it's wrong here
This is incorrect. If the API server were completely down, you would not be able to query node status at all because kubectl commands would fail to reach the API server. Moreover, an API server outage would affect all nodes in the cluster, not just a single node, causing every node's status to become stale or unknown, rather than a single node being marked NotReady while others remain Ready. The described symptom—a single node NotReady with its kubelet running—specifically points to a node-level communication problem, not a control-plane-wide failure.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CKA exam frequently reuses these exact scenarios with slightly different constraints.
✓Network connectivity issue between kubelet and API serverCorrect answer▾
Why this is correct
This is the correct answer. The kubelet is responsible for reporting the node's status to the API server through periodic heartbeat updates. When there is a network connectivity issue between the kubelet and the API server, the API server's node controller does not receive these updates for longer than the node-monitor-grace-period (default 40 seconds). As a result, the node is marked as NotReady, even though the kubelet process itself continues to run locally and can still manage containers on the node.
✗The kubelet is not installedWrong answer — click to see why▾
Why this is wrong here
Question states kubelet is running.
✗The node has been cordonedWrong answer — click to see why▾
Why this is wrong here
Cordoning makes node Unschedulable, not NotReady.
✗The API server is downWrong answer — click to see why▾
Why this is wrong here
If API server is down, kubectl get nodes would fail, not show NotReady.
Analysis generated from the official CKAblueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Visual reference
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.