Courseiva
TroubleshootingmediumMultiple ChoiceObjective-mapped

CKA Troubleshooting Practice Question

A pod 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` or `kubectl exec` out of habit, forgetting that these commands only work for running pods, while 'Pending' indicates a pre-scheduling failure that requires inspecting events and conditions via `kubectl describe`.

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 pod stuck in 'Pending' state means it has not been scheduled to a node yet. The `kubectl describe pod` command provides detailed event logs, scheduler decisions, and resource constraints (e.g., insufficient CPU/memory, persistent volume claims not bound, node selector mismatches) that reveal why scheduling failed. This is the first diagnostic step because it surfaces the root cause without requiring the pod to be running.

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 <pod-name> is ineffective for diagnosing a Pending pod because the kubelet has not yet started any containers; there is no container runtime log stream to retrieve. In the Pending phase, the scheduler may not have assigned the pod to a node, or image pulling/volume mounting has not begun, so logs simply return an error stating that the pod's containers are not ready or that the pod is not running.

  • kubectl describe pod <pod-name>

    Why this is correct

    kubectl describe pod <pod-name> is the correct diagnostic command because it aggregates the pod's object metadata, current status, conditions, and most importantly, recent Events from the API server, scheduler, and kubelet. For a Pending pod, the Events section reveals whether the scheduler failed due to insufficient resources, taints/tolerations, node selector mismatches, or whether a PersistentVolume claim is awaiting binding — the precise reason for the stuck state.

  • kubectl top pod <pod-name>

    Why it's wrong here

    kubectl top pod <pod-name> reports live CPU and memory utilization from the metrics-server for pods that are actually Running, so a Pending pod returns an error like 'error: metrics not available yet' or an empty response. Resource usage is irrelevant here because containers have not been created, and the command cannot expose scheduling or admission-control failures that keep a pod in Pending.

  • kubectl exec -it <pod-name> -- sh

    Why it's wrong here

    kubectl exec -it <pod-name> -- sh requires an existing, running container to attach to and execute a shell inside, which does not exist for a Pending pod. The API server will reject the request with an error such as 'cannot exec into a container in a pod that is not running' or 'container not found', so this command provides no diagnostic value and is only valid after the pod transitions to Running.

About these practice questions

This CKA question is part of Courseiva's 302-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 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.