KCNA Container Orchestration Practice Question
A Pod is stuck in 'Pending' state. Which command is most helpful to diagnose the issue?
⚠ Common exam trap
CNCF often tests the misconception that 'kubectl logs' is the universal debugging command, but for pending pods, logs are unavailable because containers haven't started, making 'kubectl describe' the correct choice for pre-run 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
✓
kubectl describe pod my-pod
'kubectl describe pod my-pod' provides detailed information about the pod's current state, including events, conditions, and resource constraints. When a pod is stuck in 'Pending', it typically means the scheduler cannot place it on a node due to issues like insufficient CPU/memory, persistent volume claims not being bound, or node selector mismatches. The 'describe' command surfaces these specific reasons in the 'Events' section and 'Conditions' field, making it the most direct diagnostic tool.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl logs my-pod
Why it's wrong here
kubectl logs reads stdout from containers that have started, so a Pending Pod has no container and returns an error. It is tempting because logs are the first tool for most Pod faults, and would be correct once the Pod is Running and the application itself is misbehaving.
- ✗
kubectl get events
Why it's wrong here
kubectl get events lists cluster events but is not scoped to the failing Pod's scheduling decision, so it buries the relevant FailedScheduling reason among unrelated entries. It is tempting because events do record scheduler messages, and would be correct when auditing cluster-wide activity rather than diagnosing one Pending Pod.
- ✓
kubectl describe pod my-pod
Why this is correct
`kubectl describe pod` surfaces the scheduler's events, including `FailedScheduling` messages such as insufficient CPU, memory, or unsatisfied node affinity. This directly addresses the Pending constraint, since Pending means no node has been assigned, and the Events section names the exact reason scheduling failed.
- ✗
kubectl top pod my-pod
Why it's wrong here
kubectl top pod reports live CPU and memory consumption for a running container, so it returns no metrics for a Pod that has never been scheduled. It is tempting because it is the standard tool for spotting resource-hungry Pods, and would be correct when diagnosing an OOMKilled or throttled Pod already in Running state.
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.