SOA-C02 Reliability and Business Continuity Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Add a read replica and use it for read traffic to reduce load on the primary.

  Why it's wrong here

  Adding a read replica offloads SELECT traffic and can alleviate I/O-related performance pressure, but it does nothing to expand the finite storage capacity of the primary instance. The read replica has its own storage, sized identically to the source at creation, so it cannot prevent the primary from reaching its allocated storage limit. Since the problem is a lack of space, replicas only mask the symptom by diverting reads, leaving the write-heavy workload and all stored data still constrained to the original volume.

• ✓

  Modify the RDS instance to increase the allocated storage. Since the instance is Multi-AZ, the modification will be applied with minimal downtime.

  Why this is correct

  Modifying the allocated storage on an existing Multi-AZ RDS for MySQL instance is the correct approach because RDS supports in-place storage scaling without a full rebuild. For Multi-AZ deployments, Amazon performs the modification with a brief, automatic failover to the standby, resulting in typically less than a minute of downtime rather than hours-long migrations. The KEY keyword 'production' and 'minimal downtime' align with RDS's native ModifyDBInstance operation, which can also enable Storage Auto Scaling as a proactive measure, but the immediate fix is to increase the allocated storage to accommodate the data growth.

• ✗

  Create a CloudWatch alarm to notify when storage is low, then manually clean up old data.

  Why it's wrong here

  Creating a CloudWatch alarm for low free storage only alerts you to a problem that will keep recurring if you clean up old data. Manually deleting rows from MySQL releases space inside the database files but does not automatically shrink the underlying Amazon EBS volume, and the freed space is reused only by future writes, not returned to AWS. This approach is also operationally risky and time-consuming, requiring you to identify safe data to purge, run DELETE or archival scripts, and monitor the process, all while the production database continues to grow.

• ✗

  Create a new RDS instance with larger storage and migrate the data using AWS Database Migration Service.

  Why it's wrong here

  Creating a new RDS instance and migrating data with AWS Database Migration Service (DMS) introduces significant downtime and operational overhead, failing the requirement for minimal disruption. RDS for MySQL supports in-place storage modification, which allows for scaling storage on the existing instance with minimal impact. This option is tempting as DMS is a powerful migration tool, but it is primarily designed for heterogeneous database migrations or complex homogeneous scenarios where a new instance is architecturally mandated, not for simple storage expansion of an existing RDS database.

Go deeper

Related to this question