Google ACE Practice Question: A team wants to roll back a GKE Deployment to its…

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 revert deployment/my-app --to-previous

  Why it's wrong here

  `kubectl revert` is not a valid kubectl subcommand; the kubectl CLI has no `revert` verb. Running this command would fail immediately with an unknown command error, so it cannot perform any rollback. The correct imperative verb for rolling back a Deployment is always `kubectl rollout undo`, which operates on the controller's revision history rather than a hypothetical `--to-previous` flag.

• ✓

  kubectl rollout undo deployment/my-app

  Why this is correct

  `kubectl rollout undo deployment/my-app` is the built-in rollback mechanism. It instructs the Deployment controller to revert the pod template to the spec from the previous ReplicaSet revision, scaling up the old ReplicaSet and scaling down the new one. This preserves the Deployment's revision history, so you can undo again or jump to a specific revision with `--to-revision`. It is the correct, declarative way to return to a stable version without recreating the Deployment object or disrupting its managed state.

• ✗

  kubectl apply -f previous-deployment.yaml

  Why it's wrong here

  Applying `kubectl apply -f previous-deployment.yaml` reapplies a static manifest file, which does not interact with the Deployment’s revision history managed by the controller. The correct rollback mechanism uses `kubectl rollout undo` to revert to a prior revision stored in the Deployment’s annotation. This option is tempting because `apply` is the standard way to update a Deployment from a file, and it would work if the team wanted to redeploy a known-good configuration from source control rather than rolling back through the built-in revision system.

• ✗

  kubectl delete deployment/my-app && kubectl create -f deployment.yaml

  Why it's wrong here

  Deleting the Deployment with `kubectl delete` removes the Deployment object and all of its underlying ReplicaSets, including the rollout revision history stored in annotations. This causes downtime while the pod is recreated, and the subsequent `kubectl create` starts a fresh Deployment with no previous revisions, so you cannot roll back further. The operation is also not a rollback—it merely reapplies whatever is in the YAML file, which may or may not match the last stable version.

Go deeper

Related to this question