KCNA Kubernetes Fundamentals Practice Question
A Pod is in the 'Pending' state. What is the most likely cause?
⚠ Common exam trap
A common pitfall is confusing Pod lifecycle phases (Pending, Running, Succeeded, Failed, Unknown) with error states like CrashLoopBackOff or ImagePullBackOff. Candidates often wrongly attribute 'Pending' to application-level failures instead of scheduling issues.
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 is still being scheduled because no Node has enough resources
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.
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 is still being scheduled because no Node has enough resources
Why this is correct
A Pod remains in 'Pending' when the scheduler cannot find a Node that satisfies its resource requests, such as CPU or memory limits. The kube-scheduler evaluates each Node’s allocatable capacity against the Pod’s specified requests; if no Node has sufficient unallocated resources, the Pod is unschedulable and stays Pending. This directly satisfies the constraint of insufficient Node capacity.
- ✗
The container image is missing
Why it's wrong here
A missing image surfaces as ErrImagePull or ImagePullBackOff once the kubelet has already scheduled the Pod to a node, so the Pod would not remain Pending. Image availability matters during container creation, not scheduling. This option would fit a scenario where a Pod is Running but its container repeatedly fails to start.
- ✗
The Service referencing the Pod does not exist
Why it's wrong here
A missing Service cannot cause Pending, because Services select Pods by label after scheduling; they never gate kubelet admission. Pending means the scheduler found no node satisfying the Pod's resource requests, node selectors, taints or affinity. Services matter for reachability, so this would fit a scenario where Pods run but traffic fails.
- ✗
The application inside the container has crashed
Why it's wrong here
A crashed container produces CrashLoopBackOff or Error, not Pending, because the kubelet has already scheduled the Pod to a node. Pending means the scheduler cannot place the Pod — insufficient resources, taints, or unbound PVCs. Container crashes are tempting because they are the most visible Pod failure, but they occur after scheduling.
About these practice questions
Courseiva writes every KCNA question from scratch — 930 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 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.