CKAD Application Observability and Maintenance Practice Question
You have a pod that is stuck in 'Pending' state. Which command would you run first to diagnose the issue?
⚠ Common exam trap
The trap here is that candidates often jump to `kubectl logs` (Option A) thinking it shows startup errors, but logs are only available after containers start, making it useless for a 'Pending' pod; instead, `kubectl describe pod` is the standard first diagnostic tool for scheduling and resource issues.
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 <pod>
`kubectl describe pod <pod>` provides detailed information about the pod's current state, including events, conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending). This is the first diagnostic step for a 'Pending' pod, as it surfaces the root cause (e.g., node resource pressure, PVC binding failures) without requiring additional commands.
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 <pod>
Why it's wrong here
kubectl logs <pod> is the wrong diagnostic for a Pending pod because that pod has no running or completed container yet, so there is no stdout/stderr to retrieve. The logs command requires a container to exist in a Running, Wait, or Terminated state; in Pending, the API server hasn't even received a container runtime ID. Instead of an error log about the pod, you would get a generic 'container not found' response, providing no insight into why scheduling or initialization failed.
- ✗
kubectl get pods
Why it's wrong here
kubectl get pods is insufficient for this scenario because it only shows the STATUS column as 'Pending' without any of the underlying reasons—such as unschedulable nodes, taint mismatches, insufficient CPU/memory, or unbound PersistentVolumeClaims. It aggregates the pod phase but omits the Conditions array and the Events list that describe what the scheduler and kubelet have attempted. You need a more detailed view to know whether to fix the pod spec, a quota, or the cluster capacity.
- ✗
kubectl get events
Why it's wrong here
kubectl get events is not the correct first step because it returns events from the entire namespace or cluster, making it easy to miss the specific FailedScheduling or FailedMount warning for your pod. Kubernetes events are also time-stamped and garbage-collected after a short TTL, so the relevant warning may already be gone by the time you run the command. A scoped lookup through kubectl describe pod filters to that object's events and pairs them with status conditions, giving the full context.
- ✓
kubectl describe pod <pod>
Why this is correct
kubectl describe pod <pod> is the standard diagnostic for a Pending pod because it shows the pod's Conditions (PodScheduled, Initialized, ContainersReady) and a dedicated Events section containing the exact scheduler or kubelet warnings. For example, it will display FailedScheduling with node resource pressure, FailedMount for volume issues, or taint/toleration mismatches. This output, combined with the assigned node and container statuses, directly pinpoints the blocker so you can take corrective action.
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.