An enterprise organization runs a critical e-commerce service behind an external Application Load Balancer on Google Cloud. The development team needs to deploy a major update using a canary deployment strategy. The deployment strategy must satisfy the following operational requirements: Direct 5% of production user traffic to the canary backend service (service-v2) to evaluate performance and error rates under real traffic. Keep 95% of traffic routed to the stable production backend service (service-v1). Allow the operations team to incrementally increase traffic to service-v2 or instantly revert to 100% on service-v1 without deploying new infrastructure. Which traffic management configuration should you recommend?

Configure route rules in the load balancer's URL map path matcher that utilize `routeAction.weightedBackendServices` to assign weight 95 to `service-v1` and weight 5 to `service-v2`.: ### What URL Map Weighted Backend Services Are **URL maps** in Google Cloud Application Load Balancers provide advanced traffic routing and management capabilities. Using **`weightedBackendServices`** under a path matcher's **`routeAction`**, you can split incoming HTTP(S) traffic among multiple backend services based on assigned integer weights. ### How It Meets the Requirements * **5% Canary Allocation**: Setting `weight: 95` on `service-v1` and `weight: 5` on `service-v2` distributes incoming production requests proportionately between the two independent backend services. * **Incremental Rollout & Instant Rollback**: As operational confidence grows, engineers can update the URL map weights (e.g., from 95/5 to 50/50, and eventually 0/100 for full rollout). If issues arise, updating the weights back to 100/0 immediately diverts all incoming traffic back to the known-good version. * **No Infrastructure Re-provisioning**: Modifying URL map weights is an in-place control-plane configuration change that requires no redeployment of instances or changes to frontend IP configurations. ### Key Advantages * **Granular Traffic Control**: Allows percentage-based traffic steering at the load balancer level without requiring custom application routing code. * **Independent Health Checks**: Each backend service (`service-v1` and `service-v2`) maintains its own **health checks**, ensuring unhealthy instances in the canary group do not take down the stable group. * **Low Latency & High Availability**: Traffic shifting happens dynamically at the Google Front End (GFE) / Envoy proxies, avoiding DNS propagation delays. * **Support for Advanced Deployment Patterns**: Readily accommodates partial canary releases, A/B testing, and blue-green rollouts. ### Why This Is Optimal Using `weightedBackendServices` within the load balancer's URL map is the native, recommended pattern for managing canary and blue-green releases on Google Cloud Compute Engine and GKE backend workloads.

StudyCerts

Url Map Weighted Backend Services Canary | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Url Map Weighted Backend Services Canary

Section: Application and infrastructure deployment

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise organization runs a critical e-commerce service behind an external Application Load Balancer on Google Cloud. The development team needs to deploy a major update using a canary deployment strategy.

The deployment strategy must satisfy the following operational requirements:

Direct 5% of production user traffic to the canary backend service (service-v2) to evaluate performance and error rates under real traffic.
Keep 95% of traffic routed to the stable production backend service (service-v1).
Allow the operations team to incrementally increase traffic to service-v2 or instantly revert to 100% on service-v1 without deploying new infrastructure.

Which traffic management configuration should you recommend?

Place both application versions inside the same backend service and adjust the maximum utilization capacity settings of the canary instance group to 5%.

Configure a Pod Disruption Budget (PDB) on the cluster with minAvailable: 95% to prevent the canary version from receiving more than 5% of total requests.

Configure Cloud DNS weighted routing policies to distribute traffic across two distinct external forwarding rule IP addresses pointing to service-v1 and service-v2.

Configure route rules in the load balancer's URL map path matcher that utilize routeAction.weightedBackendServices to assign weight 95 to service-v1 and weight 5 to service-v2.

Professional Cloud Architect

Url Map Weighted Backend Services Canary

Related questions