Courseiva
Kubernetes Fundamentals →hardMultiple Select

KCNA Kubernetes Fundamentals Practice Question

A developer is troubleshooting a Pod that is stuck in the Pending state. Which two commands can help identify the reason for the scheduling failure? (Choose two.)

⚠ Common exam trap

The trap here is reaching for logs or exec to debug a Pending Pod, but those require a running container and will not work before scheduling.

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>

When a Pod is Pending, the scheduler has not placed it on a node. The describe command and filtered events both surface scheduler events that state the reason, such as insufficient resources or taints. Logs, exec, and top require a running container and are not useful for a Pod that has never started.

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 exec -it <pod-name> -- /bin/sh

    Why it's wrong here

    The exec command opens a shell inside a running container. Since the Pod is Pending and not scheduled, there is no container to exec into. This command will fail and does not help diagnose scheduling problems.

  • ✗

    kubectl top pod <pod-name>

    Why it's wrong here

    The top command displays CPU and memory usage for running Pods. A Pending Pod has no resource usage because it is not running. This command requires metrics-server and only works for scheduled Pods, so it cannot identify why the Pod is stuck in Pending.

  • ✗

    kubectl logs <pod-name>

    Why it's wrong here

    The logs command retrieves output from containers that have already started. A Pod in Pending state has not been scheduled to a node, so no containers are running and no logs exist. This command would return an error or no output, and cannot reveal scheduling issues.

  • ✓

    kubectl get events --field-selector involvedObject.name=<pod-name>

    Why this is correct

    This command filters cluster events related to the specific Pod. Events include scheduler messages such as '0/3 nodes are available: 3 Insufficient cpu', which directly explain why the Pod cannot be scheduled. It is an effective way to isolate relevant scheduling failures.

  • ✓

    kubectl describe pod <pod-name>

    Why this is correct

    The describe command shows detailed information about the Pod, including events at the bottom. Scheduling failures such as insufficient resources, taints, or node selectors are recorded as events, making this the primary tool to diagnose why a Pod is Pending.

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 →

How Courseiva writes practice questions · Editorial policy

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.