Cloud Run Multi-Region App with Spanner as Relational Store

Why the Answer Is Correct

Cloud Run is the serverless container platform: you deploy a container image and Google handles node provisioning, patching, scaling, and cluster lifecycle, which directly satisfies the "minimize operational overhead" requirement without asking you to run GKE control planes or node pools. Pairing it with a global external HTTPS load balancer gives a single anycast VIP that routes users to the closest healthy regional Cloud Run backend, delivering multi-region availability for the application tier. Cloud Spanner is a fully managed, horizontally scalable, strongly consistent SQL database that supports synchronous multi-region configurations (for example nam-eur-asia1), so it meets both the "relational database" and "highly available in multiple cloud regions" requirements in one service. Spanner is also the natural answer for a write-heavy workload because write throughput scales out by splitting data across spans rather than being capped by a single primary instance, which is the fundamental limitation of Cloud SQL. Taken together, Cloud Run + global HTTPS LB + Spanner is the only option that satisfies every stated constraint simultaneously.

Why the Other Options Are Wrong

Option A fails on two counts: Cloud SQL HA is regional — its standby lives in a second zone within one region, so true multi-region durability would need cross-region read replicas and manual failover, adding exactly the operational burden the question tells you to avoid; and multi-region GKE clusters require you to operate separate clusters plus ingress/federation logic. Option C proposes Firestore, which is a document (NoSQL) database — multi-region locations do not make it relational, so it violates an explicit requirement regardless of its excellent availability story. Option D proposes Cloud Bigtable, a wide-column NoSQL store designed for analytical/sequential workloads; it does not support joins, foreign keys, or transactions in the relational sense, and Google explicitly positions Bigtable as not a fit for general relational OLTP. Both C and D also saddle you with GKE standard cluster management, contradicting the low-overhead goal.

Community Comment Notes

The single community comment selected B and framed the reasoning exactly as the official Google architecture guidance does, noting "Cloud Run = serverless containers, low ops" and "Global HTTPS Load Balancer = global frontend," then identifying "Spanner = relational database with horizontal scaling and multi-region high availability." That learner's breakdown is consistent with Google's documented positioning of Spanner as the managed relational option for horizontally scaled, multi-region workloads, so the community consensus here aligns with the independent analysis rather than merely being a popularity vote.