Google ACE Practice Question: A team's Cloud SQL for PostgreSQL instance is…

Answer analysis

Option-by-option breakdown

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

• ✗

  Delete old records from the database to free space — no instance changes needed

  Why it's wrong here

  Deleting old records merely marks the space as reusable inside PostgreSQL; the disk footprint is not returned to Cloud SQL until a VACUUM (or VACUUM FULL) reclaims it, and even then the filesystem may not shrink. Running heavy delete/VACUUM operations against a production instance consumes I/O and can hold locks, which is slow and risky when the storage is already at 90%. The fastest safe fix is a direct storage increase, not a data cleanup that could take hours and still leave the instance full.

• ✓

  Increase storage capacity using `gcloud sql instances patch --storage-size=[NEW_SIZE]` without downtime

  Why this is correct

  Cloud SQL supports online storage increases without an instance restart or downtime. Running `gcloud sql instances patch [INSTANCE_NAME] --storage-size=[NEW_SIZE]` modifies the persistent disk capacity in place, and the instance continues serving reads and writes during the operation. This directly resolves the immediate capacity alarm for a production database, making it the correct first response among the options.

• ✗

  Create a new larger Cloud SQL instance and migrate data with Cloud Database Migration Service

  Why it's wrong here

  Creating a new instance and migrating with Database Migration Service introduces significant downtime for data synchronisation and cutover, whereas the scenario demands the *fastest safe action*—which is a direct storage resize on the existing instance. This option is tempting because Database Migration Service is designed for zero-downtime migrations between environments, making it correct when moving to a different region or major version upgrade, but here the bottleneck is disk capacity, not architectural change.

• ✗

  Enable automatic storage increase and wait — Cloud SQL will expand the disk retroactively

  Why it's wrong here

  Enabling automatic storage increase configures Cloud SQL to grow the disk in the future when storage reaches the configured threshold, but it does not retroactively expand an already-full disk. If the instance is currently at 90% capacity with an alert, you still need to perform a manual storage increase to relieve the immediate pressure. This setting is a preventive measure to apply after resizing manually, not a substitute for the immediate fix.

Go deeper

Related to this question