GCP Professional Cloud Architect Practice Question 1: Global Transactional Database Choice
Google Cloud Professional Cloud Architect · Test 1 · question 1 of 10
A payments company is designing the ledger behind a new global wallet product. Balance updates arrive from users in North America and Europe and must be strongly consistent worldwide; a transfer must never be visible as committed in one region and missing in another. The schema is relational, the team wants to keep writing SQL with joins and secondary indexes, write throughput is expected to outgrow what a single primary instance can absorb, and the business has signed off on a 99.999% availability target for the ledger.
Which data platform should the architect choose?
Show answer and explanation
Answer:
Spanner is the only Google Cloud database that combines a relational model and SQL with horizontal write scaling and external consistency, a guarantee stronger than serializability, in which the commit order observed by clients matches real time even across continents. Multi-region and dual-region instance configurations carry a 99.999% availability SLA (regional configurations are 99.99%). The documented trade-off is exactly the one the stem accepts: multi-region gives faster reads in more places at the cost of a small increase in write latency, because the write quorum spans regions. Each multi-region configuration has a default leader region holding the leader replicas, and that leader can be moved to reduce latency for a write-heavy workload.
Option A does not meet the requirement. Cloud SQL cross-region replicas are asynchronous read replicas; they lag the primary, so a promoted replica can lose committed transactions, and all writes still funnel through one regional primary that cannot be scaled out horizontally.
Option B gives up the two things the stem insists on. Bigtable is a wide-column NoSQL store with no SQL joins or multi-row ACID transactions across arbitrary rows, and multi-cluster routing is explicitly eventually consistent; the replication that makes failover automatic is what breaks the "never visible in one region and missing in another" requirement.
Option D is a strong PostgreSQL engine but has the same topology limit as A: a single writable primary cluster with asynchronous cross-region replicas. It scales reads globally, not writes, and does not offer the 99.999% tier the business asked for.
Reference: Spanner instance configurations