SOA-C02 Reliability and Business Continuity Practice Question

A SysOps administrator notices that an RDS instance's storage is nearly full. The instance uses General Purpose SSD (gp2) storage. The administrator needs to increase storage with minimal downtime. Which action should be taken?

⚠ Common exam trap

Candidates often confuse storage auto-scaling (which is a preventive measure) with the immediate need to increase storage, or they mistakenly believe that deleting data will instantly free up space on an RDS instance, ignoring the filesystem and volume-level allocation behavior.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Modify the RDS instance to increase the allocated storage size

Modifying the RDS instance to increase the allocated storage size is the correct action because RDS for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server supports dynamic storage scaling with minimal downtime. When you modify the allocated storage for a gp2 volume, RDS performs the modification in the background, and the instance remains available during the process, though you may experience a brief performance impact. This directly addresses the near-full storage condition without requiring a full outage.

Answer analysis

Option-by-option breakdown

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

✓
Modify the RDS instance to increase the allocated storage size
Why this is correct
Use the AWS Management Console, CLI (modify-db-instance), or API to increase AllocatedStorage on the existing RDS DB instance. RDS performs the storage expansion online, so the database remains available during the modification, and this immediately gives InnoDB/MyISAM or other engine files additional space. This is the correct immediate remediation because it directly addresses the current storage-full condition.
✗
Enable storage auto-scaling
Why it's wrong here
Enabling StorageAutoScaling on the RDS instance only governs future growth by letting RDS add storage when free space falls below a threshold, using a MaximumAllocatedStorage limit you define. If the volume is already 100% full and writes are failing, the automatic scaling policy may not engage quickly enough—or at all—because the database is in a storage-full state. It is a preventive measure, not a recovery action, so it does not resolve the current outage.
✗
Delete old data to free up space
Why it's wrong here
Attempting to delete rows while the DB instance is storage-full is often counterproductive because DELETE operations generate transaction log and undo/redo overhead that itself consumes space; with RDS you may not even have room to run the delete. In addition, reclaiming space does not release the underlying volume allocation for many engines due to fragmentation or tablespace behavior, leaving the same allocated-size ceiling. It also offers no protection against future growth and is not a durable operational fix.
✗
Convert the storage type to Provisioned IOPS
Why it's wrong here
Converting the instance to Provisioned IOPS (io1/io2/io3) changes the EBS-backed storage class and lets you define IOPS, but the AllocatedStorage size remains untouched—it does not add gigabytes. If the allocated storage is exhausted, a higher IOPS class still has no free disk space, and you will remain in the storage-full state. Provisioned IOPS is a performance optimization, not a capacity expansion, so it is irrelevant to this issue.

Go deeper

SOA-C02 Reliability and Business Continuity Practice Question

Why each option matters

Option-by-option breakdown

Related to this question