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.

• ✗

  gcloud container clusters upgrade; kubectl rollout status; kubectl rollout undo

  Why it's wrong here

  gcloud container clusters upgrade is a cluster-level operation that updates the GKE control plane and/or node pools, not the container image of a Deployment. Running it leaves the web-app Deployment's pod template unchanged, so kubectl rollout status simply reports the health of the existing revision rather than monitoring a new v2 rollout, and kubectl rollout undo has nothing relevant to revert. This sequence fails to target the application layer and cannot accomplish a versioned deployment update with rollback.

• ✓

  kubectl set image deployment/web-app web-app=gcr.io/myproject/web-app:v2; kubectl rollout status; kubectl rollout undo

  Why this is correct

  kubectl set image directly updates the Deployment's pod template to reference the v2 image, which triggers a rolling update orchestrated by the Deployment controller. kubectl rollout status then watches that update to completion, returning a non-zero exit code if the rollout fails (e.g., due to crash-loops or insufficient readiness), which is the correct signal for conditional rollback. kubectl rollout undo reverts to the previous revision, but note it should be gated on that failure in practice; even so, this is the only option that uses the proper Kubernetes-native commands for image update, rollout monitoring, and rollback.

• ✗

  kubectl edit deployment web-app; kubectl rollout status; kubectl delete deployment web-app

  Why it's wrong here

  kubectl edit opens the Deployment manifest in an editor and, if misapplied, can introduce unintended changes or be non-scriptable; more importantly, it only works if you manually remember to set the image and save, which is error-prone for automated workflows. kubectl delete deployment web-app removes the entire Deployment, its ReplicaSets, and its Pods, causing downtime and leaving no previous revision to roll back to; kubectl rollout status after deletion would fail because the Deployment no longer exists. This sequence is disruptive and does not provide a rollback mechanism, whereas the correct approach uses kubectl rollout undo to revert a failed rollout without deleting the workload.

• ✗

  kubectl apply -f web-app.yaml; kubectl rollout status; kubectl rollout undo

  Why it's wrong here

  Kubectl apply applies the YAML but does not wait for the rollout to finish before running kubectl rollout status; worse, kubectl rollout undo executes unconditionally, reverting even a successful update rather than only on failure. This option is tempting because it mirrors a common deploy-monitor-revert workflow, and it would be correct if the goal were to manually confirm status and then always revert to the previous revision regardless of success. However, the scenario requires conditional rollback on failure, which this sequence cannot achieve without error-handling logic.

Go deeper

Related to this question