GCP Professional Cloud Architect Practice Question

Your organization runs a stateless Go microservice on Cloud Run, deployed as two identical regional services that sit behind a global external HTTP(S) load balancer. Operations wants to release a new container image with minimal risk: 5 % of traffic should be routed to the new version while error-rate and latency are monitored for 30 minutes; if no issues appear, all production traffic must shift to the new version without any user-visible downtime. Which deployment approach best satisfies these canary requirements with the least operational overhead?

Migrate the workload to Google Kubernetes Engine and configure the Deployment with maxSurge = 1 and maxUnavailable = 0, allowing one additional pod of the new version at a time.
Create a new revision of the existing Cloud Run service in each region, set a 95 / 5 traffic split toward the new revision, monitor metrics, and increase the split to 100 % per region once the rollout is validated.
Provision a separate Cloud Run service in every region, use weighted DNS records so 5 % of requests resolve to the new endpoints, then raise the DNS weight to 100 % after 30 minutes.
Deploy the new image as a tagged revision, immediately delete the currently serving revision so traffic shifts to the new code, and rely on Cloud Run to automatically roll back if errors rise.

Report Issue

Answer Description

Cloud Run lets you create a new revision of an existing service and assign a percentage of requests to that revision. Because Cloud Run services are regional, you apply the 95 / 5 traffic split in each region where the service runs. The global HTTP(S) load balancer continues to direct users to their nearest healthy region, so the overall proportion of traffic going to the new revision remains roughly 5 % as long as regional traffic volumes are comparable. Cloud Monitoring can alert on error-rate and latency for each revision. When success criteria are met, you update the traffic allocation in each region to route 100 % to the new revision; if problems appear, you can instantly revert the split to 0 %. Using weighted DNS records introduces TTL delays and coarser control, deleting the current revision forces an unsafe all-at-once cut-over, and moving to GKE for pod-level rolling updates adds unnecessary complexity for a service already running on Cloud Run.

Ask Bash

Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.