KCNA Container Orchestration Practice Question
A developer creates a Deployment with 3 replicas. After updating the pod template, they run 'kubectl rollout status deployment/my-deployment' and see that the rollout is stuck. Which command should they use to investigate the rollout history?
⚠ Common exam trap
CNCF often tests the distinction between commands that show current state (describe, get events) versus commands that show historical state (rollout history), trapping candidates who confuse 'investigating the rollout history' with general troubleshooting.
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 rollout history deployment/my-deployment
'kubectl rollout history' is the dedicated command to view the revision history of a Deployment, including the changes made to the pod template in each revision. When a rollout is stuck, this command helps identify which revision caused the issue and allows you to roll back to a previous stable revision. The other commands provide general debugging information but do not specifically show the rollout history.
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
Why it's wrong here
Events show scheduling, image-pull and probe failures, not the Deployment's recorded revisions or which ReplicaSet is stalled. It tempts because events are the first stop for most cluster faults, and would be correct if pods were failing to start rather than the rollout history being needed.
- ✗
kubectl describe deployment my-deployment
Why it's wrong here
kubectl describe deployment reports current status, events and replica conditions, but not the revision history or which ReplicaSet is failing to progress. It is the right first command for general troubleshooting; rollout history specifically requires kubectl rollout history.
- ✓
kubectl rollout history deployment/my-deployment
Why this is correct
The rollout history subcommand queries the Deployment's recorded revisions, showing each revision number and change-cause annotation. This reveals whether a bad revision or stalled progression caused the stuck rollout, directly satisfying the need to investigate rollout history.
- ✗
kubectl logs deployment/my-deployment
Why it's wrong here
Deployment-level logs aggregate nothing useful here: logs come from pods, not the Deployment object, and reveal runtime output rather than revision history. It tempts because logs diagnose crashing containers, which is the right move when pods start but fail, not when a rollout stalls on revision tracking.
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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.