Google ACE Practice Question: A Cloud SQL production instance experiences a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Increase the Cloud SQL instance's max_connections database flag to 10,000

  Why it's wrong here

  Raising the max_connections database flag to 10,000 merely raises the ceiling; it does not reduce the number of connections being opened, nor does it mitigate the cost of each connection. PostgreSQL spawns a backend process for every connection, and even if the limit is increased, high connection counts consume significant memory and can cause lock contention, performance degradation, or even instance crashes. Additionally, Cloud SQL may reject or limit such a high flag value, and this approach treats the symptom rather than fixing the underlying connection proliferation problem.

• ✓

  Deploy a connection pooler (e.g., PgBouncer) between the microservices and Cloud SQL

  Why this is correct

  A connection pooler like PgBouncer sits between the microservices and Cloud SQL, multiplexing many client connections over a small set of persistent database connections using transaction-level pooling. For example, thousands of microservice connections can be served by just tens of actual PostgreSQL connections, keeping the database well under max_connections and reducing per-connection memory overhead. This directly addresses the root cause of connection proliferation and is the correct fix because it lowers the true connection count Cloud SQL must manage.

• ✗

  Enable Cloud SQL HA — the standby will handle the connection overflow

  Why it's wrong here

  Cloud SQL High Availability provisions a standby instance in a different zone, but that standby is passive and never accepts client connections during normal operation. It exists solely for automatic failover when the primary becomes unavailable; it does not serve traffic or share the connection load. Therefore, enabling HA does not increase the maximum concurrent connections or prevent the connection overflow from exhausting the primary's limits before any failover would occur.

• ✗

  Add a read replica — microservices can connect to the replica instead of the primary

  Why it's wrong here

  A read replica is an asynchronous copy of the primary and can only serve read-only queries; it cannot accept write traffic. Microservices that need to write must still connect to the primary, and if connection exhaustion is caused by write-heavy traffic or connection churn on the primary, the replica does nothing to reduce the number of active sessions there. Even for read traffic, you still need to explicitly route connections to the replica—simply adding one won't reduce the primary's connection count unless your microservices actually use it.

Go deeper

Related to this question