Google ACE Practice Question: A Cloud SQL instance's disk is at 95% capacity

Answer analysis

Option-by-option breakdown

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

• ✗

  Take a snapshot of the instance, create a new larger instance from the snapshot, then update the connection string.

  Why it's wrong here

  Taking a snapshot and creating a new larger instance requires a period of downtime while the new instance is provisioned and the connection string is updated, which violates the "no downtime" requirement. This approach is tempting because it is a standard method for resizing a Cloud SQL instance when brief maintenance is acceptable, and it would be correct if the stem allowed a scheduled outage.

• ✓

  Increase the disk size via the Cloud SQL console or `gcloud sql instances patch` — this occurs with no instance restart.

  Why this is correct

  Cloud SQL supports increasing the configured disk size without restarting the instance, either through the Cloud Console or the `gcloud sql instances patch INSTANCE --storage-size=NEW_SIZE` command. This online operation allocates additional persistent storage while the instance continues serving traffic, directly resolving the disk-full condition and satisfying the no-downtime requirement. Remember that storage size can only be increased, not decreased, so choose the new size based on projected growth.

• ✗

  Delete old database tables to free up space.

  Why it's wrong here

  Deleting database tables is a destructive application-level change that can cause irrecoverable data loss and may require application code modifications or a maintenance window. Even if you delete rows, Cloud SQL does not automatically shrink the underlying persistent disk, so the allocated capacity remains the same and the disk-full condition is not resolved. The only operational fix that keeps the instance available and preserves data is an online disk resize.

• ✗

  Switch the instance to SSD storage, which has higher throughput and allows more writes.

  Why it's wrong here

  Switching from HDD to SSD storage changes the disk performance characteristics, not the disk capacity — the instance could still be full after the switch. Cloud SQL does not support in-place storage type changes; you would need to recreate the instance from a backup or export, which introduces downtime and a new connection string. Given the explicit no-downtime requirement, this option fails while also failing to address the actual capacity problem.

Go deeper

Related to this question