CKAD Application Deployment 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.

• ✓

  kubectl rollout undo deployment my-deployment

  Why this is correct

  The `kubectl rollout undo deployment my-deployment` command is the correct rollback mechanism because it reverts the Deployment to the previously active ReplicaSet, effectively restoring the last known good Pod template. You can optionally specify `--to-revision` to target a specific historical revision; otherwise, it undoes only the most recent rollout, scaling down the current ReplicaSet and scaling up the prior one.

• ✗

  kubectl rollout redo deployment my-deployment

  Why it's wrong here

  `kubectl rollout redo deployment my-deployment` is invalid because `redo` is not a subcommand of `kubectl rollout`. The valid rollout subcommands are `history`, `pause`, `restart`, `resume`, `status`, and `undo`; since `redo` does not exist, kubectl would immediately fail with a syntax error and perform no action whatsoever.

• ✗

  kubectl rollout revert deployment my-deployment

  Why it's wrong here

  `kubectl rollout revert deployment my-deployment` might sound semantically appropriate, but `revert` is not a recognized verb in kubectl's rollout command group. The actual verb used for rolling back is `undo`, and kubectl strictly parses its subcommands; passing `revert` results in an error such as 'unknown command' and does not alter the Deployment's state.

• ✗

  kubectl rollout history deployment my-deployment

  Why it's wrong here

  `kubectl rollout history deployment my-deployment` is a read-only informational command that lists all previous revision numbers and their change causes. It is useful for inspecting rollout history or for determining which `--to-revision` to use with `undo`, but it never modifies the Deployment's desired state, so it cannot perform a rollback on its own.

Go deeper

Related to this question