Google ACE Practice Question: A team deploys a new version of their application…

Answer analysis

Option-by-option breakdown

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

• ✗

  Delete the blue Deployment and create the green Deployment as the replacement

  Why it's wrong here

  Deleting the blue Deployment before creating the green Deployment is effectively a recreate deployment strategy, which causes an outage window between the old Pods terminating and the new Pods becoming Ready. Even with fast startup, this breaks the blue-green requirement of keeping both versions live simultaneously, and it removes the ability to instantaneously roll back by toggling the Service selector. Additionally, you would still need to update the Service selector to point to the green Pods, so deleting blue is an unnecessary and disruptive step.

• ✓

  Update the Service's label selector from 'version: blue' to 'version: green'

  Why this is correct

  Changing the Service's label selector from version: blue to version: green repoints the Service's Endpoints to the green Pods immediately, because Kubernetes Services route traffic by matching Pod labels, not by any explicit backend list. Since the blue Deployment remains untouched, it stays running with its Pods intact, making a rollback as simple as reverting the selector back to blue. No downtime occurs because the green Pods are already healthy and registered as ready before the switch, and the Service's ClusterIP and DNS name remain unchanged.

• ✗

  Update the Deployment's container image tag — GKE automatically performs a blue-green rollout

  Why it's wrong here

  Updating a Deployment's container image tag triggers a rolling update by default, in which the Deployment gradually replaces existing ReplicaSets rather than performing a blue-green switch. Kubernetes has no built-in 'blue-green' rollout mode for a single Deployment; the pattern requires two separate Deployments (blue and green) with a shared Service that you flip from one version's selector to the other. GKE does not automatically convert an image update into a blue-green deployment, so this option misrepresents the platform's native behavior.

• ✗

  Use kubectl patch to update the Service's ClusterIP to point to the green Deployment

  Why it's wrong here

  ClusterIP is an immutable virtual IP assigned to a Service at creation time—kubectl patch cannot change it, and even if it could, the IP does not serve as a pointer to a specific Deployment. Service traffic is dispatched to Pods through EndpointSlices built from the Service's label selector, so patching the ClusterIP would neither update those endpoints nor cause the green Pods to receive requests. The only meaningful way to redirect traffic is to modify the selector, because that is the mechanism Kubernetes uses to link Services to Pods.

Go deeper

Related to this question