CKA Troubleshooting Practice Question
A pod has been in Pending state for a long time. 'kubectl describe pod' shows the event: '0/3 nodes are available: 1 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate, 2 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?
⚠ Common exam trap
A common trap is confusing taints added automatically by the node controller (like `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable`) with taints added manually by an administrator (like `node.kubernetes.io/unschedulable` from `kubectl cordon`). In this scenario, the presence of these automatic taints on all nodes indicates that the kubelet is not running, not that nodes are cordoned.
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 on each node is not running
The taints `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` are automatically added by the node controller when a node's kubelet stops reporting its status (the `node-monitor-grace-period`, default 40s, is exceeded). Since all three nodes exhibit these taints, the kubelet is not running on any of them, preventing the node from being marked `Ready` and causing the scheduler to find no suitable node for the pod.
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 pod's image is incorrect
Why it's wrong here
An incorrect image pull specification does not result in a pod remaining in the Pending phase. The scheduler selects a node before the kubelet ever attempts to pull the image; a failed image pull produces an ImagePullBackOff or ErrImagePull event during the ContainerCreating phase. Therefore, if the pod is still Pending with no assigned node, the root cause is a scheduling failure, not an image problem.
- ✓
The kubelet on each node is not running
Why this is correct
When kubelet is not running on a node, the node's heartbeat to the control plane is absent; after the node-monitor-grace-period, the Node controller marks the node NotReady and applies the node.kubernetes.io/not-ready:NoSchedule taint. Since no nodes are schedulable, the kube-scheduler cannot find a match for the pod, leaving it in Pending indefinitely. This is often the systemic cause when all nodes are unreachable or their kubelets have crashed.
- ✗
The pod has resource requests that exceed node capacity
Why it's wrong here
If a pod's resource requests exceed the allocatable capacity of every node, the kube-scheduler will leave the pod Pending but emit specific events such as '0/3 nodes are available: insufficient cpu, insufficient memory.' The kubelet is still running and nodes are Ready in this scenario, so the nodes are not tainted or unschedulable. You would see those resource-related failure messages in kubectl describe, not a complete absence of scheduling attempts.
- ✗
The nodes are all cordoned
Why it's wrong here
Cordoning a node with kubectl cordon sets its spec.unschedulable field to true, which makes the kube-scheduler skip it while the node itself remains Ready and the kubelet continues to run. When all nodes are cordoned, the pod stays Pending, but the Events will contain messages like 'node(s) cordoned' or a predicate failure for NodeUnschedulable. This differs from a kubelet outage, which changes the Node condition to NotReady and adds a NoSchedule taint.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
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
This CKA question is part of Courseiva's 302-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.