KCNA Kubernetes Fundamentals Practice Question
A Pod has been in 'Pending' state for an unusual amount of time. Which of the following is a likely cause?
⚠ Common exam trap
Kubernetes certification exams often test the distinction between Pod lifecycle phases (Pending vs. Running vs. CrashLoopBackOff) and the specific conditions that cause each state, tricking candidates into confusing post-scheduling issues (like image errors or probe failures) with pre-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 cluster does not have enough resources to schedule the Pod
A Pod stuck in 'Pending' state indicates that the Pod has been accepted by the API server but has not been scheduled to a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) across all nodes, preventing the scheduler from finding a suitable node that meets the Pod's resource requests. The scheduler continuously evaluates nodes using predicates and priorities, and if no node passes the predicates (e.g., NodeResourcesFit), the Pod remains Pending.
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 invalid
Why it's wrong here
An invalid image causes ImagePullBackOff or ErrImagePull once the kubelet attempts to start the container, not a sustained Pending phase. It is tempting because image problems are a common Pod failure, but Pending means the scheduler cannot bind the Pod to a node, typically from insufficient resources or unsatisfied node selectors.
- ✗
The Pod's liveness probe is failing
Why it's wrong here
A failing liveness probe restarts an already-running container, producing CrashLoopBackOff or repeated restarts, not Pending. It is tempting because probe failures are a frequent Pod fault, but probes only execute after scheduling and container start, whereas Pending indicates the scheduler has not yet assigned the Pod to a node.
- ✓
The cluster does not have enough resources to schedule the Pod
Why this is correct
Insufficient allocatable CPU or memory across nodes leaves the scheduler unable to bind the Pod, so it remains Pending indefinitely. This directly satisfies the stem's scheduling-failure constraint: the kube-scheduler cannot find a node meeting the Pod's resource requests, unlike image-pull or runtime errors that occur after binding.
- ✗
The Service pointing to the Pod is misconfigured
Why it's wrong here
A misconfigured Service affects traffic routing to an already-running Pod; it does not prevent scheduling, so the Pod would still reach Running. It is tempting because Service faults cause connectivity failures, but Pending is reported by the scheduler before any container starts, pointing to unschedulable resource or affinity constraints.
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 →
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.