KCNA Kubernetes Fundamentals Practice Question
A developer creates a Deployment with 3 replicas. After a few seconds, they run `kubectl get deployments` and see `READY 2/3`. They want to quickly identify why one replica is not ready. Which command should they use to inspect the status of the individual Pods?
⚠ Common exam trap
The trap here is using a Deployment-level command when the issue is at the Pod level; always inspect the Pods themselves to see individual readiness and status.
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 pods -l app=myapp -o wide
To quickly identify which Pod is not ready, listing Pods with the Deployment's label selector and wide output shows each Pod's status and node. This provides an immediate view of which replica is failing and basic context. Describing the Deployment or fetching logs from the Deployment does not show per-Pod readiness. Filtering events by the Deployment name misses Pod-level events. The correct approach is to query the Pods directly.
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 describe deployment myapp
Why it's wrong here
Describing the Deployment shows its rollout status, events, and replica counts, but it does not list individual Pod statuses. It may indicate that 2 of 3 replicas are available but will not show which Pod is failing or why. To inspect a specific Pod, you need to look at the Pods themselves or their events. This command is useful for Deployment-level issues but not for per-Pod diagnosis.
- ✓
kubectl get pods -l app=myapp -o wide
Why this is correct
This command lists all Pods matching the label selector app=myapp, showing their status, restarts, and node assignment. It directly reveals which Pod is not Ready and provides basic details. The -o wide flag adds IP and node information, which can help correlate with node issues. This is the quickest way to see the individual Pod statuses and identify the problematic replica.
- ✗
kubectl get events --field-selector involvedObject.name=myapp
Why it's wrong here
This filters events for the Deployment object named myapp, but not for its Pods. Events related to Pod scheduling or readiness are associated with the Pod objects, not the Deployment. This command would miss Pod-specific events that explain why a replica is not ready. It is not the correct way to inspect individual Pod statuses.
- ✗
kubectl logs deployment/myapp
Why it's wrong here
This command fetches logs from one Pod of the Deployment, typically the first one. It does not indicate which Pod is not ready and may show logs from a healthy Pod. Logs are useful for application errors but not for identifying which replica is failing to become Ready. It does not provide the status overview needed to pinpoint the problematic Pod.
Go deeper
Related to this question
About these practice questions
One of 930 original KCNA 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 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.