Google ACE Practice Question: A GKE Deployment must be updated to a new…

Answer analysis

Option-by-option breakdown

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

• ✗

  Recreate strategy

  Why it's wrong here

  The Recreate deployment strategy scales the old ReplicaSet down to zero before scaling up the new ReplicaSet, creating a gap where no Pods are running. This intentionally causes a period of service unavailability, making it unsuitable for production workloads that require continuous availability. It is only appropriate for non-critical or development environments, or for applications that cannot tolerate two versions running concurrently due to database schema locks or other shared resources.

• ✗

  Blue-green deployment using a separate Deployment and Service selector swap

  Why it's wrong here

  Blue-green deployment runs two complete versions of the application side-by-side: the stable 'blue' Deployment and the new 'green' Deployment, with a single Service whose selector is swapped to point to green after validation. While this allows instant rollback and zero-downtime, it requires doubling infrastructure resource consumption and additional orchestration to manage the selector flip and lifecycle of the old version. The question asks for the simplest way to update an existing Deployment, and RollingUpdate accomplishes the same zero-downtime goal without maintaining two full environments.

• ✓

  RollingUpdate strategy

  Why this is correct

  RollingUpdate is the default strategy for Kubernetes Deployments, progressively replacing old Pods with new ones while keeping a minimum number of Pods available at all times. It uses configurable parameters such as maxUnavailable and maxSurge to control how many Pods can be taken down or created beyond the desired replica count, allowing zero-downtime updates without any additional manifests. Since the Deployment controller manages the entire rollout automatically, it is the simplest and most direct way to achieve continuous availability.

• ✗

  Canary deployment with a traffic-splitting ingress

  Why it's wrong here

  A canary deployment introduces the new version to a small percentage of traffic first, then gradually increases the weight, requiring a traffic-splitting ingress like NGINX or a service mesh to route requests between the old and new Deployments. It is an excellent strategy for gathering feedback and reducing blast radius, but it demands separate Deployment manifests, weight configurations, and often additional components. For a straightforward zero-downtime update of a standard Deployment, RollingUpdate is far simpler because it is built-in and requires no extra infrastructure.

Go deeper

Related to this question