CKA Troubleshooting Practice Question
Which TWO of the following are common causes for a pod to be in the 'Pending' state?
⚠ Common exam trap
The CKA exam often tests the distinction between pod lifecycle phases—candidates confuse 'Pending' (pre-scheduling or pre-startup) with post-startup failures like probe failures or image pull errors, which occur in later states.
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
✓
Insufficient cluster resources (CPU/memory) to schedule the pod
Option B is correct because the Kubernetes scheduler places a pod into the Pending state when no node has enough allocatable CPU or memory to satisfy the pod's resource requests, so the pod remains unscheduled until resources free up or the cluster scales. Option D is correct because if a pod references a PersistentVolumeClaim that is not yet Bound (for example, waiting on a dynamic provisioner or a matching PersistentVolume), the scheduler cannot satisfy the volume's node affinity/topology constraints and the pod stays Pending. Option A is not a cause of Pending; an image that cannot be pulled produces an ImagePullBackOff/ErrImagePull status while the pod is already scheduled and typically Running or Waiting on a node. Option C is not a cause of Pending; a failing liveness probe causes kubelet to restart the container, resulting in CrashLoopBackOff or repeated restarts, not a scheduling failure. Option E is not a cause of Pending; an unreachable node affects existing pods (marking them Unknown/NotReady) rather than preventing scheduling, since the scheduler simply avoids nodes it considers unhealthy.
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 container image is not found
Why it's wrong here
Image not found is a container runtime failure that only matters after the scheduler successfully places the pod onto a node and the kubelet starts pulling the image. At that point, the kubelet retries and sets the pod's status to ImagePullBackOff, not Pending. A Pending phase specifically means the pod has not yet been admitted to a node, so an incorrect image reference cannot be the cause.
- ✓
Insufficient cluster resources (CPU/memory) to schedule the pod
Why this is correct
If the cluster lacks nodes with enough allocatable CPU or memory to satisfy the pod's resource requests, the Kubernetes scheduler cannot assign the pod to any node and leaves it in Pending. The scheduler only considers unreserved resources calculated as capacity minus requests from existing pods; a node with insufficient free capacity or failing a node selector will keep the pod unschedulable. The scheduler emits events like '0/3 nodes are available: insufficient cpu' to point you to this condition.
- ✗
The pod's liveness probe is failing
Why it's wrong here
A liveness probe is executed by the kubelet only after a container has already started successfully, so a failing liveness probe cannot prevent the initial scheduling. A probe failure causes the kubelet to restart the container and moves the pod through Running, Waiting, or CrashLoopBackOff states, not Pending. Because Pending precedes container creation entirely, liveness probe status is irrelevant during that phase.
- ✓
A PersistentVolumeClaim (PVC) referenced by the pod is not bound
Why this is correct
When a pod references a PersistentVolumeClaim, the kubelet cannot start containers until that PVC is bound to a PersistentVolume; if no suitable PV exists, the pod will remain Pending. The scheduler may not even place the pod because the volume binding can block scheduling, and once placed, the kubelet reports an event about the unbound claim. This condition is resolved by creating a PV or by enabling dynamic provisioning, after which the pod leaves Pending and proceeds.
- ✗
The node is unreachable due to network issues
Why it's wrong here
If a node becomes unreachable due to network issues after a pod has been scheduled, the node controller marks the node as Unknown and uses the pod eviction timeout to decide whether to reschedule pods, but this does not move the pod to the Pending phase. The pod on that unreachable node continues to be in Unknown or some terminal phase depending on policy, not Pending. Pending is the phase of a pod that has been accepted by the API server but has not been scheduled to a healthy, reachable node.
Go deeper
Related to this question
Learn chapter
Configuring Storage Classes and Dynamic Provisioning
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
Persistent Volumes
A Persistent Volume is a piece of storage in a Kubernetes cluster that has been provisioned by an administrator and exists independently of any single pod that uses it.
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.