CKA Troubleshooting Practice Question
Which THREE of the following are common causes for a pod to remain in 'Pending' state?
⚠ Common exam trap
The CKA exam often tests the distinction between pre-scheduling (Pending) and post-scheduling (Running, Waiting, Terminated) failures; candidates mistakenly associate image pull or OOM errors with Pending, but these occur only after the pod is bound to a node.
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
✓
Node taints that the pod does not tolerate
A pod stays in Pending when the Kubernetes scheduler cannot place it on any node, and node taints that the pod does not tolerate (option A) cause the scheduler to filter out those nodes, leaving the pod unscheduled. Insufficient CPU or memory resources on any node (option D) is a classic scheduling failure: the scheduler's resource-fit predicate rejects every node, so the pod remains Pending. A PersistentVolumeClaim that is not bound (option E) also blocks scheduling, because a pod referencing an unbound PVC cannot be assigned to a node until the volume is provisioned and bound. By contrast, Image pull backoff (option B) occurs after scheduling, when the kubelet cannot pull the image, so the pod is in Waiting/ContainerCreating rather than Pending. Container OOMKilled (option C) is a runtime termination state that happens after the container starts, so it does not cause a Pending 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.
- ✓
Node taints that the pod does not tolerate
Why this is correct
If one or more nodes have taints (e.g., node-role.kubernetes.io/control-plane:NoSchedule) and the pod spec lacks matching tolerations, the scheduler will exclude those nodes from feasible candidates. As a result, the pod remains in Pending because no node can satisfy both taint/toleration rules and other scheduling predicates. This is a common cause of Pending, especially in single-node clusters or clusters with specialized node pools.
- ✗
Image pull backoff
Why it's wrong here
ImagePullBackOff is a container waiting state, not a scheduling phase; by the time the kubelet attempts to pull the image, the pod has already been scheduled and assigned to a node. If a pod were still Pending, image pull issues would not yet be relevant because scheduling happens before the kubelet interacts with the image. This error condition appears in container statuses, not the pod's scheduling condition, so it cannot explain why a pod is stuck in Pending.
- ✗
Container OOMKilled
Why it's wrong here
An OOMKilled container has been started and then terminated by the kernel because it exceeded its memory limit; this is a post-scheduling runtime event. A pod that is Pending has not had any containers created, so it cannot have an OOMKilled status. OOMKilled appears in the container state as Terminated with reason OOMKilled, whereas Pending is a pod-level phase reflecting the scheduler's failure to find a suitable node.
- ✓
Insufficient CPU or memory resources on any node
Why this is correct
The scheduler evaluates each node's allocatable CPU and memory against the pod's resource requests; if no node can satisfy those requests, the pod cannot be placed and remains in Pending. This is common when requests are set too high or the cluster is saturated, because even if free capacity exists, the sum of requested resources across all pods may exceed a node's allocatable amount. The scheduler surfaces this as an Unschedulable condition with messages such as "Insufficient cpu" or "Insufficient memory".
- ✓
PersistentVolumeClaim is not bound
Why this is correct
A pod that references a PersistentVolumeClaim in its volume definitions is stuck in Pending if that PVC is not in the Bound phase, because the scheduler can place the pod only once all volumes can be attached or mounted. The PVC may remain unbound because no matching PersistentVolume exists or the storage class has not provisioned one, and kube-scheduler waits until the volume binding is ready before selecting a node. This is a distinct storage-related scheduling constraint, not a CPU or memory resource problem.
Go deeper
Related to this question
Learn chapter
Installing Kubernetes with kubeadm
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.
Key term
Storage Classes
A Storage Class in Kubernetes is a template that defines how persistent storage is provisioned automatically, including the type of storage, performance characteristics, and provisioning policies.
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.