CKAD Application Observability and Maintenance Practice Question
You want to view the events related to a specific pod named 'my-pod' in the 'default' namespace. Which command filters events to show only those pertaining to this pod?
⚠ Common exam trap
Test-takers frequently choose `kubectl describe pod my-pod` (option B) thinking it shows all events for the pod, but it only shows a truncated, non-filterable subset of recent events, not the full event history.
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=my-pod
`kubectl get events --field-selector involvedObject.name=my-pod` uses a field selector to filter events by the `involvedObject.name` field, which directly matches the pod's name. This approach is precise and avoids parsing unstructured output, ensuring only events related to that specific pod are returned.
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 get events --field-selector involvedObject.name=my-pod
Why this is correct
This command queries the Events API directly and uses a server-side field selector to filter events whose involvedObject.name equals my-pod. It returns the full event history for that pod as structured YAML/JSON without any client-side text parsing, making it the idiomatic, precise way to list pod-related events. You can extend it with -w to watch live events or add additional field selectors, such as reason=Failed, to narrow the results.
- ✗
kubectl describe pod my-pod
Why it's wrong here
kubectl describe pod my-pod does display an Events section at the bottom, but it is a human-readable summary that mixes pod details with only a small, truncated set of recent events. It omits fine-grained timestamps and does not support server-side filtering or programmatic output, so it cannot serve as a dedicated event list. For a complete, searchable event history, you must use kubectl get events with a field selector.
- ✗
kubectl get events | grep my-pod
Why it's wrong here
Piping kubectl get events through grep to match lines containing my-pod is brittle because the pod name may appear in any field, such as source.host or message, causing false positives. It also performs client-side filtering after fetching all events from the cluster, which is inefficient and unscalable in busy namespaces. A field selector, by contrast, filters server-side and targets only the involvedObject.name, making the grep approach unreliable and unidiomatic.
- ✗
kubectl logs my-pod
Why it's wrong here
kubectl logs my-pod retrieves the container's stdout/stderr streams, which capture only what the application printed during execution. Kubernetes events are entirely separate API objects generated by controllers and kubelet (e.g., FailedScheduling, BackOff) and are stored in etcd, not in container logs. Therefore, logs provide application-level telemetry and have no bearing on inspecting lifecycle or scheduling events for the pod.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD 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 CKAD exam.