Google ACE Practice Question: On-call and receive a PagerDuty alert: `Cloud SQL…

Answer analysis

Option-by-option breakdown

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

• ✗

  Restart the Cloud SQL instance to clear all connections and queries.

  Why it's wrong here

  Restarting a Cloud SQL instance forcibly drops all sessions and rolls back transactions, but it only provides a temporary reset: after the instance returns, whichever client or scheduled job reissues those same full-table-scan queries will immediately consume CPU again. It also induces several minutes of complete unavailability, far more disruptive than selectively killing the few problematic backends, and it fails to alter the missing indexes that are the root cause, so the next execution plan still does a Seq Scan.

• ✓

  Terminate the long-running table scan queries immediately, then add indexes on the frequently queried columns as the root cause fix.

  Why this is correct

  Use pg_stat_activity to identify the specific backend PIDs running the long table scans, then execute SELECT pg_terminate_backend(pid) to kill only those queries and restores the CPU headroom instantly without affecting other sessions. After that, create indexes on the columns used in the WHERE and JOIN clauses — preferably with CREATE INDEX CONCURRENTLY on PostgreSQL to avoid locking writes — so the optimiser can use Index Scan instead of Seq Scan, fixing the root cause. This combination yields immediate relief and a sustainable prevention of recurrence.

• ✗

  Increase Cloud SQL's CPU to a larger machine type to handle the current load.

  Why it's wrong here

  Increasing to a larger machine type can mask the symptom by providing more CPU cores to absorb the poor query plans, but the full table scans still read and filter every row, so the new capacity will quickly be saturated again under the same workload. Vertical scaling also incurs additional cost and potential connection interruption during the reconfiguration, while a simple index addition would lower the per-query cost by orders of magnitude and permanently remove the inefficiency.

• ✗

  Reduce `max_connections` to prevent new connections from adding load.

  Why it's wrong here

  Lowering max_connections merely caps the number of concurrent sessions, so new legitimate client requests are rejected even though the existing runaway queries continue to consume CPU using the old connections; it does not stop or slow down any query already executing. It also makes the instance less available during high use, and in Cloud SQL a max_connections change may require an instance restart, making the situation worse. The real solution is to terminate the offending queries and add indexes, not to refuse admission to healthy traffic.

Go deeper

Related to this question