CKA Troubleshooting Practice Question
Which command can you run to see the events related to a specific pod?
⚠ Common exam trap
A common mix-up: candidates confuse `kubectl logs` (application output) with `kubectl describe` (cluster events), or assume `kubectl get events` is the only way to view events, missing that `kubectl describe` automatically filters events for the specified resource.
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` includes a dedicated 'Events' section that lists all lifecycle events for that specific pod, such as scheduling, container pulls, and restarts. This command filters events to only those relevant to the pod, making it the most direct way to view pod-specific events without needing to parse all cluster events.
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 fetches the container's stdout/stderr streams, capturing application-level output such as error traces or print statements. It does not query the Kubernetes API's event store, so cluster lifecycle events like scheduling failures, image pull retries, or liveness probe kills are invisible here. This command is for diagnosing what the application printed, not for understanding why the API server or kubelet took a particular action on the Pod.
- ✗
kubectl get pod pod-name
Why it's wrong here
kubectl get pod pod-name returns a concise, table-formatted snapshot of the Pod's current state, including its phase (Running, Pending, etc.), restart count, and readiness. This summary derives from the Pod's status field and can tell you where the Pod is stuck, but it does not include the ordered event history that shows a sequence of transitional actions and failures. To see the Events subsection that explains how that status was reached, you need the detailed view from describe.
- ✗
kubectl get events
Why it's wrong here
kubectl get events lists cluster-wide events from all namespaces and all resources, such as Node pressure, Deployment scaling, and every other Pod's lifecycle. While a specific Pod's events are included somewhere in that output, the command does not filter by resource name or namespace, making it impractical to isolate the events for one Pod. You would need to add selectors or use describe to scope the events to the target Pod reliably.
- ✓
kubectl describe pod pod-name
Why this is correct
kubectl describe pod pod-name retrieves the Pod's full configuration along with a dedicated 'Events' section that records timestamped, sequential notifications from the kubelet and controller-manager about that Pod. These events describe actions like scheduling decisions, container creation, image pulling, probe failures, and restarts, which are exactly what you need when debugging why a Pod is stuck or repeatedly crashing. The describe command aggregates just the events for that specific Pod, making it the direct answer to the question.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKA question from scratch — 302 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
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.