Courseiva
Troubleshooting →easyMultiple Choice

CKA kubectl describe Practice Question

You have a Pod that is stuck in Pending state. Which command should you use to get detailed information about why the Pod is not running?

⚠ Common exam trap

Candidates often mistakenly think that `kubectl logs` can diagnose startup failures, but logs only exist for running containers, whereas `kubectl describe` reveals pre-scheduling and admission issues that cause the Pending state.

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>

`kubectl describe pod <pod-name>` provides detailed event logs, status conditions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims pending, node selector mismatches) that explain why the Pod is stuck in Pending state. The Pending state indicates the Pod has been accepted by the API server but not yet scheduled or started, and `describe` surfaces the exact scheduler or admission controller failures.

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

    This command retrieves the standard output (stdout) and standard error (stderr) streams directly from the container runtimes of running or terminated containers. Because a Pod in a "Pending" state has not yet had its containers created or started by the kubelet, no container logs exist to be fetched. Attempting this command on a Pending Pod will result in an API error indicating the containers are not running.

  • ✓

    kubectl describe pod <pod-name>

    Why this is correct

    This command queries the Kubernetes API server for the complete state of the Pod resource, rendering its configuration, current conditions, and controller events. The "Events" section at the bottom of the output is critical for troubleshooting Pending Pods, as it reveals scheduler decisions, such as insufficient CPU/memory, node taints, or missing PersistentVolumeClaims. This makes it the primary tool for diagnosing scheduling failures.

  • ✗

    kubectl exec <pod-name> -- /bin/sh

    Why it's wrong here

    This command initiates an interactive session or executes a specific binary inside an active container by leveraging the container runtime's execution API via the kubelet. Since a Pending Pod has not been scheduled to a node or has not initialized its container network and namespaces, there is no active container process to attach to. Consequently, the API server will reject the request with a connection or state error.

  • ✗

    kubectl get pod <pod-name>

    Why it's wrong here

    This command retrieves a high-level, tabular summary of the Pod's current phase, readiness, and restart count directly from the etcd database. While it confirms that the Pod is indeed in the "Pending" state, it does not expose the underlying scheduler events or resource constraints causing the delay. To diagnose the root cause of the scheduling failure, a more verbose inspection tool is required.

About these practice questions

One of 726 original CKA 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 →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKA 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 CKA exam.