Get Your CertGoogle Cloud Professional Cloud ArchitectPlayCompete
‹ All Google Cloud Professional Cloud Architect questions

GCP Professional Cloud Architect Practice Question 10: Multi Region Failover Load Balancing

Google Cloud Professional Cloud Architect · Test 1 · question 10 of 10

Reliability & Operationshard

Users in Europe reported a 40-minute outage of a public web tier last quarter even though an identical, healthy deployment was running in us-central1 the whole time; operators had to edit DNS records by hand and many browsers kept resolving to the failed region afterwards. The web tier is stateless and containerized, sessions live in Memorystore, and the business now requires a single public hostname, automatic regional failover in well under a minute, and no dependence on clients honouring DNS time-to-live values.

What should the architect change?

Select one answer
Show answer and explanation

Answer:

  • A. Front regional backend services in both regions with one global external Application Load Balancer on a single anycast IP address, letting health checks drain an unhealthy region and capacity settings overflow traffic to the other

A global external Application Load Balancer publishes one anycast IP address advertised from Google's edge worldwide, so the client always resolves the same address and DNS plays no part in failover. A single backend service can hold backends in multiple regions; Google Front Ends steer each request to the closest healthy backend with capacity, and when health checks mark a region's backends unhealthy the load balancer stops sending traffic there within seconds. Because the tier is stateless and session state already lives in Memorystore, requests can be served from either region without further change. This satisfies every constraint: one hostname, sub-minute automatic failover, and no reliance on client DNS behaviour.

Option B reproduces the outage that was just experienced. DNS-based failover moves the decision to resolvers and browsers, both of which cache aggressively and frequently ignore short TTLs (which is exactly why users stayed pinned to the failed region), and a 300-second TTL cannot deliver sub-minute recovery even when honoured.

Option C protects against zone failure only. Autohealing replaces unhealthy instances and multi-zone spread survives a zonal outage, but a regional outage or a bad regional dependency takes the whole site down, and the business explicitly asked for regional failover.

Option D uses the wrong load balancer class. The cross-region internal Application Load Balancer does provide multi-region failover, but it is internal: its forwarding rule takes a private address reachable from within the VPC and connected networks, so it cannot serve users on the public internet.

Reference: External Application Load Balancer overview

Practice Test 1 ›

Study guides for Google Cloud Professional Cloud Architect