Cloud SQL has two kinds of replica that sound similar but do completely different jobs. Read replicas exist to take read load off the primary. Failover replicas exist so the database keeps running when the primary fails. The Associate Cloud Engineer exam tests both, and the trick is recognizing which one a scenario is describing. This article covers what each is for, how they differ, and how to tell them apart on the exam.
It does not cover the deep details of Cloud SQL replication internals, every configuration option, or how to size replicas for production. The goal is the working understanding the Associate Cloud Engineer exam expects.
A read replica is a copy of the primary Cloud SQL instance that handles read queries. The primary still does all the writes. The replica receives those writes asynchronously and serves SELECT queries to clients.
This is useful when your application is read-heavy. A reporting dashboard, a product page that gets a lot of traffic, anything where the same data is being read many times. Instead of slamming the primary with reads, you point read traffic at one or more replicas. The primary stays free to handle writes, and your read capacity scales horizontally with the number of replicas.
Two limitations matter. First, read replicas in Cloud SQL must be in the same region as the primary. You cannot put a read replica in a different region for cross-region read scaling. Second, replication is asynchronous, which means there is a brief lag between a write hitting the primary and the data being visible on the replica. For most applications this is fine. For a workload that needs to read its own writes immediately, asynchronous replication can be a problem.
A failover replica is a copy of the primary that exists specifically to take over if the primary goes down. It is not for serving reads in normal operation. It sits there, kept in sync, waiting.
The replication for a failover replica is synchronous. Writes are committed to both the primary and the failover replica before they are acknowledged to the application. This is what makes the failover safe. If the primary dies, no committed data is lost, because every committed write also exists on the failover replica.
The failover replica is placed in a different zone, or sometimes a different region, from the primary. When the primary fails, Cloud SQL promotes the failover replica to be the new primary. The application reconnects, and operation resumes. There is a brief window of unavailability during the failover, but the database comes back without manual intervention.
Read replicas: asynchronous replication, same region as primary, used for serving reads to scale read capacity.
Failover replicas: synchronous replication, different zone or region from primary, used for high availability and disaster recovery, not for serving reads in normal operation.
The replication mode is the cleanest tell. Asynchronous means read replica. Synchronous means failover replica.
The exam scenarios for this topic break into two recognizable patterns.
If you see a question about a read-heavy workload, a reporting database that is overloading the primary, or scaling read capacity, the answer is read replicas. The phrasing usually mentions reads explicitly, like "the team wants to offload SELECT queries from the primary."
If you see a question about high availability, surviving a zone outage, disaster recovery, or keeping the database available during a failure, the answer is a failover replica or HA configuration. The phrasing usually mentions availability or recovery explicitly.
The exam sometimes tries to mix them up. A scenario might say "we need to handle more read traffic AND survive a zone outage." That is two separate problems. The right answer adds both kinds of replica, or uses an HA configuration plus separate read replicas.
In current Cloud SQL terminology, you usually do not configure a failover replica directly. You enable "high availability" on the instance, and Cloud SQL provisions and manages the standby replica behind the scenes. Functionally it is the same thing as a failover replica, just packaged. The exam can use either term, so recognize both.
gcloud sql instances create my-replica \
--master-instance-name=my-primary \
--region=us-central1 \
--tier=db-n1-standard-2The master-instance-name flag is what makes this a read replica of an existing primary instead of a new standalone instance.
Read replicas scale reads, asynchronously, in the same region. Failover replicas keep you up during outages, synchronously, across zones. They are not interchangeable, and the Associate Cloud Engineer exam tests them as separate features that solve separate problems. If the question is about read load, pick read replicas. If the question is about availability or recovery, pick failover or HA.
My Associate Cloud Engineer course covers Cloud SQL replication, backup, and PITR together in the Cloud SQL section, including the scenarios where Spanner is the better answer instead.
