A Cloud SQL read pool is a collection of read replicas used to distribute read workloads across multiple instances. It redirects read-only traffic away from the primary instance to reduce the load there, and it does this through a single read endpoint rather than asking the application to track each replica individually. The Professional Cloud Database Engineer exam tends to test how this differs from connecting to standalone read replicas, so it is worth being precise about what the pool actually provides.
The starting point is an application that sends read queries to the database. Those reads land on a single read endpoint, which serves as the entry point for the entire pool and has a fixed IP address. From there the traffic enters the read pool, where it is distributed across several read replicas. Each of those replicas stays synchronized with the primary instance. The primary continues to handle all incoming writes, and the read traffic is offloaded to the pool so the primary is not serving those queries.
Two properties of this setup matter most. The first is that connections are balanced across the pool nodes automatically, so you do not have to manage traffic distribution yourself or build your own logic to spread queries across replicas. The second is that everything is exposed through one read endpoint with a fixed IP. That gives the application a consistent target regardless of how many replicas are in the pool, so the connection string does not change as the pool grows or shrinks.
A single read replica also offloads reads from the primary, but the application connects to that replica directly at its own address. If you add more replicas to scale further, the application has to know about each one and decide how to split traffic between them. A read pool removes that work. The pool presents one endpoint, and the connection balancing across the underlying replicas happens for you. On the exam, when a scenario describes wanting to scale read capacity while keeping a single, stable connection target and without writing custom distribution logic, the read pool is the configuration that matches.
It is also worth keeping the roles straight. The primary instance is where writes go. The replicas in the pool are read-only and stay in sync with the primary. The read endpoint is the address the application uses for reads, and it is what routes a given connection to one of the replicas. Keeping those three pieces distinct, the primary, the pool of replicas, and the single read endpoint in front of them, is usually enough to answer the questions in this area correctly.
Our Professional Cloud Database Engineer course covers Cloud SQL read pools alongside read replicas and high availability, with practice questions that drill these distinctions.
