CKAD Application Observability and Maintenance Practice Question
A pod is stuck in 'Pending' state. You run 'kubectl describe pod' and see '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory.' What does this mean?
⚠ Common exam trap
CNCF often tests the distinction between pod lifecycle phases (Pending, Running, CrashLoopBackOff) and the specific error messages in 'kubectl describe pod', leading candidates to confuse scheduling failures with runtime issues like image pull errors or probe failures.
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's resource requests exceed available resources on any node
The 'Pending' state indicates the pod has been accepted by the Kubernetes API server but cannot be scheduled onto a node. The message '0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory' means the scheduler evaluated all nodes and found that none had enough allocatable CPU and memory to satisfy the pod's resource requests. This is a scheduling failure caused by the pod's requests exceeding the available resources on any node.
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 not available
Why it's wrong here
An unavailable image is only discovered after the scheduler successfully binds the pod to a node, at which point the kubelet attempts a pull and reports ImagePullBackOff or ErrImagePull in the container's waiting reason. That is a distinct failure mode from the unschedulable Pending state, which arises before any node is chosen and no image pull is attempted.
- ✗
The liveness probe is failing
Why it's wrong here
Liveness probes are executed exclusively by the kubelet on containers that are already started, so they have no bearing on the scheduling phase. If a liveness probe fails during runtime, the container is killed and restarted, producing a CrashLoopBackOff or restart loop, not a Pod phase of Pending.
- ✓
The pod's resource requests exceed available resources on any node
Why this is correct
The scheduler filters nodes by checking whether each node's allocatable CPU and memory can accommodate the pod's declared requests. When every node fails that check, the events on the pod show '0/N nodes are available' with 'Insufficient cpu' or 'Insufficient memory', and the pod remains Pending until resources free up or the request is lowered.
- ✗
The container is crashing due to an error
Why it's wrong here
A container that crashes due to an error has already started, and the kubelet will restart it, eventually marking the container status as CrashLoopBackOff. Pending occurs before any container is launched, so a crash can never place a pod into Pending; only scheduling or pre-start initialization issues can.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-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 CKAD 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 CKAD exam.