Google ACE Practice Question: An application architect is comparing Cloud SQL…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud SQL with one primary instance and cross-region read replicas

  Why it's wrong here

  Cloud SQL's cross-region read replicas reproduce your schema in other regions, but replication is asynchronous. A read routed to a replica may be arbitrarily stale, and all writes still hit the single primary in its home region, so users on other continents experience multi-hundred-millisecond write round-trips. This gives you low-latency reads at the cost of weak read consistency, and no improvement to write availability or write latency.

• ✓

  Cloud Spanner multi-region configuration

  Why this is correct

  Cloud Spanner is a fully managed relational database that synchronously replicates data across regions, using TrueTime and Paxos to deliver external consistency for reads and writes. A multi-region configuration can be placed in the three required continents, allowing strongly consistent transactions to commit with lower latency than a single primary and letting local read replicas serve fresh data. It supports ANSI SQL and ACID transactions, so the existing e-commerce application can keep its relational schema.

• ✗

  Cloud Firestore in multi-region mode

  Why it's wrong here

  Cloud Firestore multi-region mode is a document database, not a relational one. It lacks SQL joins, foreign-key constraints, and the rich multi-table transaction patterns used to manage normalized inventory, orders, and SKU relationships in an e-commerce platform. Even with strong consistency for documents, you would have to rearchitect your transactional inventory logic into denormalized documents, adding application complexity and risking consistency bugs under concurrency.

• ✗

  Cloud SQL with Cloud Memorystore caching layer for reads

  Why it's wrong here

  Cloud Memorystore is an in-memory Redis/Memcached cache, so adding it in front of Cloud SQL only accelerates reads that hit the cache. The cache is eventually consistent unless you enforce complex cache invalidation, and a stale stock count can trigger overselling; meanwhile every write and cache-miss read still hits the single primary. This is a read-scaling patch, not a solution for strong, low-latency writes across three continents.

Go deeper

Related to this question