KCNA Container Orchestration Practice Question
A pod is in the 'Pending' state. Which of the following is a likely cause?
⚠ Common exam trap
CNCF often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff), tempting candidates to confuse post-scheduling errors with pre-scheduling conditions.
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 sufficient resources to run the pod
A pod enters the 'Pending' state when it has been accepted by the API server but cannot be scheduled onto a node. The most common cause is insufficient cluster resources (CPU, memory, or ephemeral storage) on any available node to satisfy the pod's resource requests. The Kubernetes scheduler continuously evaluates node resource availability and will leave the pod in Pending until a suitable node is found or the request times out.
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 liveness probe is failing
Why it's wrong here
A failing liveness probe targets a container already running, so kubelet restarts it rather than leaving the pod unscheduled; the pod would show Running with restarts. Liveness probes suit detecting hung applications post-startup, not scheduling failures. Pending instead reflects the scheduler being unable to place the pod, typically insufficient resources or unsatisfied node affinity.
- ✗
The container image is not found in the registry
Why it's wrong here
A missing image surfaces as ImagePullBackOff or ErrImagePull after the scheduler has already bound the pod to a node, so its phase becomes Running-then-waiting, not Pending. Registry absence matters when diagnosing pull failures. Pending specifically means no node has been assigned yet, so image availability is irrelevant at that stage.
- ✓
No node has sufficient resources to run the pod
Why this is correct
The scheduler cannot bind the pod to any node because each candidate lacks allocatable CPU or memory to satisfy the pod's resource requests. Unschedulable pods remain Pending with a FailedScheduling event, so insufficient node capacity is the direct cause here.
- ✗
The container exited with OOMKilled
Why it's wrong here
OOMKilled is a container termination reason occurring after the pod has been scheduled and started, producing CrashLoopBackOff or Error, never Pending. It applies when diagnosing runtime memory limits. Pending means the scheduler has not yet bound the pod to any node, so container exit states cannot be the cause.
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.