CKAD Services and Networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  View the deployment revision history, then choose the revision to rollback to, then perform the rollback using kubectl rollout undo, then wait for the rollout to complete, then verify the deployment status

  Why this is correct

  This is the correct sequence. First, `kubectl rollout history deployment/<name>` lists available revisions (with revision numbers and change-causes), giving you the data needed to select a target. Then `kubectl rollout undo deployment/<name> --to-revision=<N>` triggers a rollback by scaling the old ReplicaSet back up and the current one down. `kubectl rollout status deployment/<name>` is mandatory to block until the new/old ReplicaSet reaches the desired state, and only after that does `kubectl get deployment` or `kubectl describe deployment` confirm the deployment is healthy and ready.

• ✗

  Choose the revision to rollback to, then view the deployment revision history, then perform the rollback, then wait for the rollout to complete, then verify

  Why it's wrong here

  This order is invalid because you cannot meaningfully 'choose the revision to rollback to' before viewing the revision history. Without `kubectl rollout history`, you have no way to know which revision numbers exist, what changes they introduced, or which one is the safe rollback target; you would be picking a random or guessed revision number. The correct flow starts with history exploration, then selection, and only then the `undo` command with a specific `--to-revision` flag.

• ✗

  View the history, choose the revision, perform the rollback, then verify, then wait for completion

  Why it's wrong here

  The critical flaw here is placing verification before waiting for rollout completion. Running `kubectl rollout status` (which is the 'wait' step) after an undo is what ensures the ReplicaSet has reached the desired number of ready replicas; if you skip ahead to `kubectl get pods` or `kubectl rollout status` immediately after `undo`, you may observe the old pods still terminating and the new ones still pending, leading to a false assumption that the rollback failed. You must let the rollout reconcile (wait) before you check the deployment's health or pod readiness.

• ✗

  Perform the rollback, then view the history, then choose the revision, then wait, then verify

  Why it's wrong here

  Performing the rollback before viewing history is fundamentally backwards: `kubectl rollout undo` without a `--to-revision` flag only reverts to the immediate previous revision, and with a flag it requires you to already know the target revision number. There is no way to 'choose the revision' after the undo has already executed, because the action is done and the target was never specified. The correct sequence is to first enumerate the history, then decide on a target revision, then execute the undo and wait/verify.