CKAD Application Observability and Maintenance Practice Question
A pod named 'app' is stuck in 'Pending' state. You run 'kubectl describe pod app' and see the event: '0/3 nodes are available: 3 Insufficient cpu'. What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates confuse resource requests with resource limits, or assume that the pod is failing at runtime (like CrashLoopBackOff) when the error is purely a scheduling issue indicated by the Pending state and the specific 'Insufficient cpu' event.
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 CPU request is higher than the available CPU on any node
The event '0/3 nodes are available: 3 Insufficient cpu' indicates that the pod's CPU resource request exceeds the allocatable CPU capacity on every node in the cluster. Kubernetes schedules pods based on resource requests, not limits, so if the sum of CPU requests across all pods on a node would exceed the node's capacity, the pod remains Pending. This is the most likely cause because the error message directly points to insufficient CPU resources.
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 CPU request is higher than the available CPU on any node
Why this is correct
A pod with a CPU request exceeding the allocatable CPU on every node cannot be scheduled. The Kubernetes scheduler filters out nodes lacking sufficient unallocated capacity to satisfy the request, leaving the pod in the Pending phase and emitting events such as 'Insufficient cpu'. Requests, not limits, drive these placement decisions, so the pod can wait indefinitely until node capacity is freed or the request is lowered.
- ✗
The container image is not found
Why it's wrong here
If the container image were missing, the kubelet would only attempt to pull it after the pod has been scheduled to a node. That process would record events like ErrImagePull or ImagePullBackOff, and the pod would appear in a Waiting or ContainerCreating phase, not Pending. Because a Pending pod has not yet been assigned to any node, image-related failures cannot occur at this stage.
- ✗
The pod is in CrashLoopBackOff
Why it's wrong here
CrashLoopBackOff is a runtime state that occurs after a pod has been scheduled and its containers have started, then repeatedly crashed. The pod phase in this scenario is Running or Waiting while the kubelet enforces an exponential backoff restart delay. A pod in Pending has never started containers because it has not been scheduled, making CrashLoopBackOff mutually exclusive with a Pending phase.
- ✗
The pod has been evicted due to memory pressure
Why it's wrong here
Eviction is a node-level action that terminates already-scheduled, running pods when the node experiences memory or disk pressure, and the pod's phase becomes 'Evicted' or 'Failed'. A pod must be scheduled and running before it can be evicted, but a Pending pod has not yet been placed on a node. Therefore, memory-pressure eviction cannot be the reason a pod remains in the Pending phase.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 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.