KCNA Kubernetes Fundamentals Practice Question
A pod is stuck in Pending state. Which THREE of the following are possible causes?
⚠ Common exam trap
CNCF often tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly attribute image or probe issues to the Pending state.
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 pod specifies a nodeSelector that does not match any node
Option A is correct because the scheduler filters nodes using the pod's nodeSelector (and node affinity); if no node carries matching labels, the pod cannot be placed and remains Pending. Option C is correct because the scheduler only assigns a pod to a node whose allocatable resources can satisfy the pod's resource requests; insufficient CPU/memory leaves the pod unschedulable in Pending. Option E is correct because a pod referencing an unbound PersistentVolumeClaim cannot be scheduled until the PVC is bound to a PersistentVolume, so it stays Pending. Option B is not a scheduling cause: a nonexistent image leads to ImagePullBackOff/ErrImagePull after the pod has been scheduled to a node, so the pod is not Pending. Option D is also not a scheduling cause: a failing liveness probe only occurs after the container is running, causing restarts (CrashLoopBackOff), not a Pending phase.
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 specifies a nodeSelector that does not match any node
Why this is correct
The scheduler filters nodes by nodeSelector; if no node carries matching labels, no feasible node remains, so the pod stays Pending with no node assigned. This directly satisfies the stem's Pending constraint, since scheduling never completes.
- ✗
The container image does not exist
Why it's wrong here
A missing image fails at the kubelet's image pull stage, yielding ErrImagePull or ImagePullBackOff once the pod is already scheduled to a node. It is tempting because image problems are frequent. Pending occurs earlier, when no node satisfies the pod's resource requests, selectors or taints.
- ✓
No node has enough CPU or memory to satisfy the pod's resource requests
Why this is correct
The scheduler's resource-fit predicate rejects nodes whose allocatable CPU or memory cannot cover the pod's requests. With every node filtered out, no binding occurs, leaving the pod Pending — precisely the stuck state the stem describes.
- ✗
The pod has a liveness probe that is failing
Why it's wrong here
A failing liveness probe restarts the container after it has started, producing CrashLoopBackOff or Running states, never Pending. It is tempting because probe failures are a common pod fault. Pending means the scheduler cannot place the pod, typically from insufficient resources, taints or unsatisfied node affinity.
- ✓
A PersistentVolumeClaim used by the pod is not bound
Why this is correct
An unbound PersistentVolumeClaim leaves the pod's volume unsatisfiable, so the scheduler cannot place it on any node and it remains Pending. This directly satisfies the stem's Pending constraint: without a bound PV, the volume binding predicate fails, blocking scheduling until the claim is satisfied.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA 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 →
Same concept, more angles
2 more ways this is tested on KCNA
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A pod is in 'Pending' state for a long time. What is the most likely cause?
medium- A.The pod's container has crashed
- B.The pod's service endpoint is misconfigured
- ✓ C.The scheduler cannot find a node that satisfies the pod's resource requests or constraints
- D.The container image is invalid
Why C: A pod remains in 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is that the scheduler cannot find a node that meets the pod's resource requests (CPU/memory) or constraints (node selectors, affinity rules, taints/tolerations). Until a suitable node is found, the pod stays in Pending, waiting for scheduling.
Variation 2. A Pod is in the 'Pending' state. What is the most likely cause?
easy- ✓ A.The Pod is still being scheduled because no Node has enough resources
- B.The container image is missing
- C.The Service referencing the Pod does not exist
- D.The application inside the container has crashed
Why A: A Pod in 'Pending' state means the Pod has been accepted by the API server but is not yet running. The most common reason is that the scheduler cannot find a Node with sufficient CPU, memory, or other resources to place the Pod. This triggers the scheduler to continuously attempt to bind the Pod to a suitable Node, leaving it in Pending until resources become available or the Pod is deleted.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This KCNA 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 KCNA exam.