Google ACE Practice Question: A financial application requires a relational…

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 a read replica in a different zone

  Why it's wrong here

  A Cloud SQL read replica in a different zone is designed to offload read traffic, not to serve as a failover target. The replica uses asynchronous replication, which can lag behind the primary, causing potential data loss if promoted. Promotion is a manual operation — you must initiate it, update connection strings, and handle the transition, whereas high availability requires zero manual intervention and preserves the same instance endpoint.

• ✓

  Cloud SQL with High Availability (HA) configuration

  Why this is correct

  Cloud SQL with High Availability (HA) configuration is the correct choice because it automatically provisions a standby instance in a different zone within the same region and uses synchronous replication to keep it current. When the primary fails, Cloud SQL detects the outage and automatically promotes the standby, typically within seconds, and the public IP address remains the same so existing applications can reconnect without code changes. This gives you a simple, managed, zone-redundant solution that meets the requirement for automatic failover with no application-level logic.

• ✗

  Cloud Spanner multi-region instance

  Why it's wrong here

  Cloud Spanner is a globally distributed, horizontally scalable NewSQL database with synchronous replication across regions, designed for worldwide consistency and 99.999% availability. For a single application that only needs protection against a zone-level failure, deploying a multi-region Spanner instance is an extreme overprovisioning in both cost and operational complexity. The question's requirement is for a single Cloud SQL application's high availability, and Spanner is not a drop-in replacement for Cloud SQL's relational API and tooling.

• ✗

  Two separate Cloud SQL instances with application-level failover logic

  Why it's wrong here

  Two separate Cloud SQL instances with application-level failover logic means your application must detect primary failure, promote the secondary, and handle replication lag or data inconsistency manually. Cloud SQL does not automatically replicate data between two standalone instances unless you configure external replication, so you must build and manage a custom data sync mechanism. This approach reintroduces the very complexity and risk of split-brain that a managed HA solution eliminates, and it does not provide the same automated health checking and failover guarantees.

Go deeper

Related to this question