KCNA Kubernetes Fundamentals Practice Question
A pod is stuck in 'Pending' state. Which of the following is a likely cause?
⚠ Common exam trap
The KCNA exam often tests the distinction between pod scheduling failures (Pending) and runtime failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly associate image or command issues with the Pending state instead of recognizing that Pending is exclusively a scheduling-phase problem.
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
✓
Insufficient CPU or memory resources on any available node
A pod remains in 'Pending' state when the scheduler cannot find a suitable node to run it. The most common reason is insufficient CPU or memory resources on any available node, as the scheduler checks resource requests against node allocatable resources before binding the pod. If no node meets the pod's resource requirements, the pod stays pending until resources become available.
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 command returned a non-zero exit code
Why it's wrong here
A non-zero exit code produces CrashLoopBackOff or Error, which requires the pod to have been scheduled and its container started, so Pending is not the symptom. It is tempting because failing commands are frequent, and this would be correct when a running container repeatedly exits and restarts.
- ✗
The container image is invalid
Why it's wrong here
An invalid image surfaces as ImagePullBackOff or ErrImagePull after the kubelet has already bound the pod to a node, so the pod leaves Pending. It is tempting because image problems are a common pod failure, and this would be the answer when a pod schedules successfully but its container never starts.
- ✓
Insufficient CPU or memory resources on any available node
Why this is correct
The scheduler cannot bind the pod to any node because no node has sufficient allocatable CPU or memory to satisfy the pod's resource requests. With no feasible node, the pod remains unscheduled in Pending rather than being placed and failing at runtime.
- ✗
The pod's liveness probe failed
Why it's wrong here
A failed liveness probe triggers container restarts, reported as CrashLoopBackOff or Unhealthy, which presupposes the pod is already running on a node. It is tempting because probes are a familiar failure source, and this would be the answer when a healthy-looking pod keeps restarting after deployment.
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.