Courseiva
Deploying and Implementing a Cloud SolutionmediumMultiple ChoiceObjective-mapped

Google ACE Deploying and Implementing a Cloud Solution Practice Question

An engineer deployed a new version of their application on GKE using a Deployment. Users report that the new version has a bug. The engineer wants to quickly revert to the previous version. How can they achieve this?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Run kubectl rollout undo deployment/<deployment-name>

Kubernetes Deployments support rollbacks using 'kubectl rollout undo'. The command automatically reverts to the previous revision. Deleting and recreating the Deployment would require re-creating from the previous manifest. 'kubectl rollout history' shows history but doesn't roll back. Scaling down then up does not revert the version.

Answer analysis

Option-by-option breakdown

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

  • Scale the deployment to zero and then scale back up

    Why it's wrong here

    Scaling a Deployment to zero terminates all Pods; scaling back up creates new Pods using the Deployment's current Pod template, which still contains the new application version. This action never alters the Deployment's pod template or its associated ReplicaSet, so the old version is not restored. Furthermore, this approach introduces full downtime, making it unsuitable as a rollback strategy.

  • Run kubectl delete deployment and re-apply the old manifest

    Why it's wrong here

    Deleting the Deployment removes the Deployment resource, its underlying ReplicaSets, and all Pods, immediately causing a service outage. Re-applying an old manifest not only requires that you still possess that old YAML file, but it also creates a fresh Deployment with a clean rollout history, discarding the revision evidence you might need. This manual, destructive procedure is inconsistent with Kubernetes' declarative lifecycle management and should be avoided when a built-in rollback mechanism exists.

  • Run kubectl rollout undo deployment/<deployment-name>

    Why this is correct

    `kubectl rollout undo deployment/<deployment-name>` instructs the Deployment controller to revert to the previous revision by restoring the prior Pod template and rolling it out with the same gradual scaling strategy—creating a new ReplicaSet while terminating the current one in a controlled fashion. This preserves availability because the controller scales up the new/old ReplicaSet before scaling down the current one. The command is the canonical, declarative way to undo a bad deployment with minimal downtime.

  • Run kubectl rollout history deployment/<deployment-name>

    Why it's wrong here

    `kubectl rollout history deployment/<deployment-name>` is a read-only command that lists all rollout revisions, including their REVISION numbers and CHANGE-CAUSE annotations. It does not modify the Deployment, ReplicaSets, or Pods, so running it cannot undo a bad deployment. To actually revert, you would need to follow it with `kubectl rollout undo` and optionally the `--to-revision` flag; simply viewing history leaves the current version running.

About these practice questions

This ACE question is part of Courseiva's 769-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.