CKA Troubleshooting Practice Question
A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)
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
✓
The kubelet service has stopped on the node
Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status. Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A pod on the node is in ImagePullBackOff
Why it's wrong here
ImagePullBackOff indicates the container runtime cannot pull an image for a specific pod, but the kubelet itself remains operational and continues to report node heartbeats. Node status is determined by kubelet health and resource conditions, not by individual pod failures, so the node stays Ready even if every pod on it is stuck in ImagePullBackOff.
- ✗
The node has insufficient memory
Why it's wrong here
Insufficient memory creates MemoryPressure, prompting the kubelet to evict pods and potentially set a corresponding condition, but that condition is distinct from Ready. The kubelet still runs, reports node status, and does not lose its ability to communicate with the control plane, so the node is not marked NotReady solely due to memory pressure.
- ✓
The kubelet service has stopped on the node
Why this is correct
When the kubelet service stops on a node, it can no longer send periodic StatusUpdates (heartbeats) to the API server. After the node-monitor-grace-period expires without a heartbeat, the kube-controller-manager marks the node as NotReady, and even if the node is restarted, the status remains until a healthy kubelet reports again.
- ✗
The Kubernetes API server is down
Why it's wrong here
The API server is the control-plane endpoint for cluster state; if it goes down, the kubelet's heartbeat requests fail, but the node itself is not automatically set to NotReady. Node status transitions to Unknown after the grace period if heartbeats cannot be received, and may later become NotReady only when the control plane resumes and reevaluates conditions—so API server downtime alone does not directly flip a node to NotReady.
- ✓
The network plugin (e.g., Calico, Flannel) is not functioning
Why this is correct
A non-functional network plugin (like Calico or Flannel) causes the kubelet to fail its network readiness checks and report the NetworkUnavailable condition. The controller-manager then transitions the node to NotReady because the node cannot provide pod networking, even though the kubelet itself is running and available to the API server.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 302 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.