KCNA Kubernetes Fundamentals Practice Question
A Pod is stuck in Pending state. Which of the following is the MOST likely cause?
⚠ Common exam trap
This question tests the distinction between scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff, probe failures), so the trap is confusing post-scheduling container issues with pre-scheduling resource constraints.
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
✓
No node has enough resources to run the Pod
A Pod stuck in Pending state means the scheduler cannot place it on a node. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the Pod unscheduled. This is indicated by the Pod's status remaining Pending and typically confirmed via `kubectl describe pod` showing events like '0/1 nodes are available: 1 Insufficient cpu'.
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's container is crashing
Why it's wrong here
A crashing container has already been scheduled and started, so the Pod shows CrashLoopBackOff rather than Pending. It tempts because crashes are frequent, but Pending means the scheduler has not placed the Pod, which container runtime failures cannot cause.
- ✗
The container image has a typo
Why it's wrong here
A mistyped image name yields ImagePullBackOff or ErrImagePull after scheduling, not Pending. It tempts because image errors are common, but the kubelet only pulls images once a node is assigned, so an unschedulable Pod never reaches that stage.
- ✓
No node has enough resources to run the Pod
Why this is correct
Pending means the scheduler cannot bind the Pod to any node. Insufficient allocatable CPU or memory across all nodes is the most common trigger, since the scheduler filters out nodes whose free resources cannot satisfy the Pod's requests.
- ✗
The Pod's liveness probe is failing
Why it's wrong here
A failing liveness probe restarts an already-running container, producing CrashLoopBackOff or Running states, not Pending. It tempts because probe failures are common Pod faults, but liveness probes only execute after scheduling succeeds, so they cannot explain a Pod awaiting node assignment.
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.