Transit ops must confirm a schedule API Deployment finished updating before announcing the new version. Which kubectl workflow best observes that progress?
Select an answer to reveal the explanation.
Short Explanation
Before you cut the ribbon on a new bridge, you check that the last beam is in place. rollout status watches the Deployment until the new revision is ready—history helps if you need to see which revision landed.
Full Explanation
Transit ops must confirm a schedule API Deployment finished updating before announcing the new version. The kubectl workflow built for that observation is kubectl rollout status (and kubectl rollout history when you need revision context). rollout status blocks or streams until the Deployment reports the new revision complete—or surfaces a progress deadline failure—so operators have an authoritative controller signal rather than guessing from unrelated node files or DNS tricks. For a public schedule cutover, that status gate is the ribbon-cutting checklist item.
Only editing /etc/hosts on every worker and assuming the rollout completed confuses node name resolution with Deployment progress; hosts files do not reflect ReplicaSet readiness. Deleting etcd snapshots during the update destroys recovery artifacts and does not provide rollout observation. Changing the Service type to ExternalName and watching DNS instead of the Deployment replaces in-cluster selection with a CNAME alias and still does not tell you whether the new Pod template is fully rolled out.
Exam caveat: rollout status watches the Deployment condition/progress; combine with get/describe and history for revision identity, especially before announcing civic releases. Operational check: kubectl rollout status deployment/<schedule-api>, optionally kubectl rollout history, then spot-check Pod images and Endpoints before communications go out.