Google ACE Practice Question: Ensuring Successful Operation of a Cloud Solution

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 status deployment/my-app

  Why it's wrong here

  kubectl rollout status deployment/my-app is a monitoring command that blocks until the current rollout completes, reporting whether pods have been successfully updated. It does not modify the deployment or its container image, so it cannot perform the required rollback to a previous revision. In the context of reverting a bad update, status is useful only after an undo has been initiated, not as the action itself.

• ✓

  kubectl rollout undo deployment/my-app

  Why this is correct

  kubectl rollout undo deployment/my-app is the correct command because it reverts the deployment to the previous revision, restoring the prior pod template spec and container image. Kubernetes retains rollout history for each change to the pod template, and undo automatically scales down the current ReplicaSet and scales up the previous one, seamlessly rolling back the application without manual image specification.

• ✗

  kubectl delete deployment/my-app --cascade=false

  Why it's wrong here

  kubectl delete deployment/my-app --cascade=false removes the Deployment object while leaving its ReplicaSets and Pods orphaned, effectively abandoning the application without a controller. This does not update or roll back the container image; it simply stops managing the resources and makes future updates or rollbacks impossible without manually recreating the Deployment. It is a destructive operation, not a rollback mechanism.

• ✗

  kubectl set image deployment/my-app my-container=gcr.io/my-project/my-image:v1

  Why it's wrong here

  kubectl set image deployment/my-app my-container=gcr.io/my-project/my-image:v1 directly changes the container image to the specified tag, triggering a new rollout to that image. While this could manually point to a previous image version, it does not leverage the Deployment's revision history like rollout undo does, and it requires knowing the exact image reference. In a rollback scenario, undo is safer and more accurate because it reverts to the exact previous configuration without guessing the image tag.

Go deeper

Related to this question