CKAD Application Deployment Practice Question
You want to undo a rollout to the previous revision. Which command should you use?
⚠ Common exam trap
Watch out — candidates often confuse `rollout undo` with `set image` or `rollout history`, thinking they can manually revert by specifying a tag like 'previous' or by viewing history, but only `rollout undo` performs the actual rollback to a prior revision.
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 undo deployment/myapp
`kubectl rollout undo deployment/myapp` reverts the deployment to the previous revision by default, using the rollout history stored in the deployment's ReplicaSet annotations. This command directly triggers a new rollout that matches the pod template of the prior revision, effectively undoing the last change.
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 delete deployment/myapp --cascade=orphan
Why it's wrong here
Running `kubectl delete deployment/myapp --cascade=orphan` removes the Deployment object itself while leaving the underlying ReplicaSets and Pods untouched but no longer managed by any controller. This is a deliberate isolation technique, not a rollback; it does not restore a previous pod template, nor does it trigger any new ReplicaSet creation. The application may keep running, but it loses its declarative management and cannot be rolled out or rolled back without recreating the Deployment.
- ✓
kubectl rollout undo deployment/myapp
Why this is correct
`kubectl rollout undo deployment/myapp` is the correct way to revert a Deployment to its previous revision. It inspects the Deployment's rollout history (stored in the ReplicaSets it manages), identifies the most recent revision's pod template, and creates a new ReplicaSet with that template while scaling down the current one—effectively undoing the last change. This is a standard, safe operation that preserves rollout history and can be repeated to continue stepping backward.
- ✗
kubectl set image deployment/myapp app=myapp:previous
Why it's wrong here
Setting the image to a tag literally named `previous`—as in `kubectl set image deployment/myapp app=myapp:previous`—does not know anything about Kubernetes revision history. It merely updates the container's image field to `myapp:previous`, which might not exist in the registry and, if it does, will cause a new rollout to that tag. This is a new desired-state change, not an undo of the prior revision, so the Deployment's rollout history still contains the old image as the latest revision after this command.
- ✗
kubectl rollout history deployment/myapp --revision=2
Why it's wrong here
`kubectl rollout history deployment/myapp --revision=2` only shows the details of a specific historical revision—its pod template, labels, and annotations—it does not change the Deployment state. This command is useful for inspecting what a past rollout looked like, but it never creates a new ReplicaSet or alters the current desired state. To actually roll back, you must combine this with `kubectl rollout undo` using `--to-revision=2`; issuing the history command alone leaves the current revision untouched.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 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 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.