KCNA Kubernetes Fundamentals Practice Question
A platform engineer is troubleshooting a Pod stuck in the Pending state and wants to identify scheduling-related causes. Which two commands or outputs are most useful for diagnosing why the scheduler cannot place the Pod? (Choose two.)
⚠ Common exam trap
The trap here is reaching for kubectl logs or kubectl exec on a Pending Pod, when those commands require a running container and a Pending Pod has none.
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 get events --field-selector involvedObject.name=<pod-name>
Scheduling failures are reported as events on the Pod object. Both kubectl describe pod and a field-selector-filtered kubectl get events expose FailedScheduling messages that name the blocking predicate, such as insufficient resources or an unsatisfied node affinity. Node listings and container logs or exec sessions cannot reveal scheduler decisions for a Pod that has never been bound to a 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.
- ✓
kubectl get events --field-selector involvedObject.name=<pod-name>
Why this is correct
Filtering cluster events by the involved object name surfaces the same scheduler warnings and failure reasons in a time-ordered list, which is helpful when events have scrolled past the default kubectl describe output window. It confirms conditions such as FailedScheduling with the specific predicate that rejected each candidate node.
- ✗
kubectl get nodes and review the STATUS and Allocatable columns
Why it's wrong here
kubectl get nodes shows node readiness and basic capacity, but it does not display allocatable resources or explain why a specific Pod failed to schedule. It can reveal a NotReady node, yet it cannot show affinity mismatches or insufficient per-node allocatable CPU and memory for the pending Pod.
- ✓
kubectl describe pod <pod-name> and inspect the Events section
Why this is correct
The Events section produced by kubectl describe pod records scheduler messages such as insufficient CPU or memory, node affinity mismatches, and taint-related failures. These messages directly state why the default scheduler could not bind the Pod to any node, making this the primary diagnostic step for Pending Pods.
- ✗
kubectl exec -it <pod-name> -- /bin/sh to inspect the node from inside
Why it's wrong here
kubectl exec requires a running container to attach to, and a Pending Pod has no container process. The command fails outright, so it cannot be used to inspect scheduling conditions. Debugging a Pending Pod must rely on API objects and events, not on interactive access to the workload.
- ✗
kubectl logs <pod-name> to read the container startup output
Why it's wrong here
kubectl logs retrieves stdout and stderr from containers that have already started. A Pending Pod has no running container and no log stream, so the command returns an error or empty output and provides no information about scheduling failures. Logs are useful only after a container actually runs.
Go deeper
Related to this question
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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
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.