Cloud Digital Leader Scaling with Google Cloud operations Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Blue/green deployment, where two identical environments run simultaneously and traffic is switched atomically

  Why it's wrong here

  Blue/green deployment runs two full environments in parallel, but actual traffic migration is a single binary cutover: once the green environment passes validation, the load balancer atomically shifts 100% of user traffic from blue to green. The scenario here instead shifts just 5% of traffic to the new version, then incrementally increases that percentage as health metrics are observed. Canary's progressive, metric-driven percentage changes are fundamentally different from blue/green's all-at-once switch.

• ✓

  Canary deployment, where a new version receives a small percentage of traffic first and is progressively rolled out as metrics confirm it is healthy

  Why this is correct

  Canary deployment precisely matches the description: 5% traffic initially, monitoring, then gradual increase to 100%. The term comes from the mining practice of using canaries to detect dangerous gas — the canary deployment detects problems before full rollout.

• ✗

  Rolling deployment, where instances are updated sequentially one at a time until all run the new version

  Why it's wrong here

  Rolling deployment updates instances sequentially—one at a time or in small batches—by rotating old instances out and new instances in until every instance runs the new version, without ever removing all capacity at once. Although both versions may briefly serve traffic during a rolling update, the mix is determined by batch size and deployment order, not by a deliberately held traffic weight such as 5%. Rolling also does not require pausing to evaluate metrics at each stage, whereas a canary rollout explicitly gates each percentage increase on observed health.

• ✗

  Recreate deployment, where the old version is terminated before the new version is deployed

  Why it's wrong here

  Recreate deployment terminates all old-version instances (scales to zero) before creating any new-version instances, which naturally causes a full downtime window. The described scenario actively routes 5% of live traffic to the new version while the old version continues serving the remaining 95%, so both versions are running concurrently. That concurrent dual-serving is the opposite of the stop-the-world nature of a recreate deployment, making this option wrong.

Go deeper

Related to this question