KCNA Kubernetes Fundamentals Practice Question
A developer is troubleshooting a Pod that remains in the Pending state and never gets scheduled. The developer suspects the issue is related to node selection constraints. Which two kubectl commands can help identify why the Pod cannot be scheduled? (Choose two.)
⚠ Common exam trap
The trap here is reaching for logs or exec to debug a Pending Pod, when no container has started and only control-plane events can reveal the scheduling failure.
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-name>
A Pending Pod has not been scheduled, so diagnostics must come from the control plane rather than the container. kubectl describe pod surfaces scheduler Events and status conditions, and kubectl get events filtered by the Pod name provides the same FailedScheduling reasons in a focused list. Commands that require a running container or metrics pipeline cannot function before scheduling occurs.
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-name>
Why it's wrong here
kubectl logs retrieves container output, which requires the container to have started and produced logs. A Pod stuck in Pending has no running container, so logs are unavailable and return an error. This command is useful for runtime failures after scheduling, but it cannot explain why the scheduler has not placed the Pod.
- ✓
kubectl describe pod <pod-name>
Why this is correct
kubectl describe pod shows the Pod's status conditions and recent Events, including scheduler messages such as '0/3 nodes are available: 3 node(s) didn't match node selector' or insufficient resources. These Events directly reveal why the scheduler could not place the Pod, making describe the most direct diagnostic for a Pending Pod with a node selection issue.
- ✗
kubectl exec -it <pod-name> -- /bin/sh
Why it's wrong here
kubectl exec requires a running container inside the Pod. Because the Pod is Pending, no container is running and exec fails immediately. This command is used for interactive troubleshooting inside a live workload, not for diagnosing scheduling failures, so it cannot help determine why the Pod has not been placed on a node.
- ✓
kubectl get events --field-selector involvedObject.name=<pod-name>
Why this is correct
kubectl get events with a field selector filters the event stream to those involving the specific Pod. Scheduler failures generate Warning events on the Pod, such as FailedScheduling with detailed reasons. This provides a focused, chronological view of scheduling attempts and complements describe by isolating the relevant events even in a busy namespace.
- ✗
kubectl top pod <pod-name>
Why it's wrong here
kubectl top pod reports CPU and memory usage from the metrics pipeline and requires the Pod to be running and metrics-server to be available. A Pending Pod has no resource usage to report, so this command returns an error or no data. It is a performance monitoring tool, not a scheduler diagnostics tool, and does not explain placement failures.
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.