Cloud SQL gives you two distinct mechanisms for keeping a database resilient and performant, and the Professional Cloud Architect exam expects you to know exactly when each one applies. High availability protects against zone failures. Read replicas scale read traffic. They are not interchangeable, and conflating them is one of the easiest ways to lose points on a database design question.
When you enable High Availability mode on a Cloud SQL instance, you create a failover replica that lives in a different zone from the primary. The replication between the primary and the failover replica is synchronous. That word matters. Synchronous replication means every write to the primary is acknowledged only after the failover replica has also written it, so the two instances stay in lockstep with no data loss during a failover event.
If the zone hosting the primary goes down, Cloud SQL automatically promotes the failover replica and your application keeps running with minimal downtime. You do not orchestrate the failover yourself, and you do not lose committed transactions in the process.
The placement rule is straightforward. The failover replica needs to be in a different zone from the primary, or in a different region entirely. Same-zone redundancy defeats the entire point, because a zone outage would take both instances down at once.
Read replicas solve a completely different problem. They are copies of the primary database that exist to absorb read traffic so the primary can focus on writes. If your application is read-heavy, pointing all your SELECT queries at the primary forces it to compete with itself for resources. Adding read replicas lets you spread that load across multiple instances and improve both availability and scalability for reads.
The replication here is asynchronous, not synchronous. The primary acknowledges writes before they have propagated to the replicas, which means there is a small but real delay before a change shows up on a read replica. For most application patterns this is fine, but you cannot use a read replica to read your own writes immediately after committing them.
The other limitation worth memorizing for the Professional Cloud Architect exam is that Cloud SQL read replicas must live in the same region as the primary. You cannot use them to serve low-latency reads to users on another continent the way you can with Spanner or with a globally distributed system. If a question asks about cross-region read scaling on Cloud SQL specifically, read replicas are not the answer.
The trap I see candidates fall into is treating these as alternatives to the same problem. They are not. If the requirement is durability and minimal downtime during a zone failure, the answer is High Availability mode with a synchronous failover replica. If the requirement is scaling read throughput or offloading reporting queries from the primary, the answer is read replicas with asynchronous replication.
Many production deployments use both at once. You run the primary in HA mode for resilience, and you attach read replicas in the same region for query load distribution. The Professional Cloud Architect exam will sometimes describe a scenario that calls for both, and recognizing that the two features address different requirements is what lets you pick the right combination.
My Professional Cloud Architect course covers Cloud SQL high availability and read replicas alongside the rest of the databases material.
