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.

• ✓

  Use the AWS Console to apply the maintenance update immediately; the Multi-AZ configuration will minimize downtime.

  Why this is correct

  Applying the maintenance window update immediately via the AWS Console is correct for a Multi-AZ RDS MySQL instance because RDS orchestrates the engine patch as a rolling operation: it first applies the update to the standby replica, then triggers a DNS failover to promote that updated standby to primary, and finally updates the old primary as the new standby. The failover itself typically completes within 60–120 seconds, and because the standby is already patched, the primary's availability impact is limited to a brief connection drop during the automatic failover. This leverages the Multi-AZ architecture exactly as designed—minimizing downtime without manual intervention or data loss—while keeping the instance fully managed by RDS.

• ✗

  Modify the DB instance to be a Single-AZ deployment, then apply the upgrade.

  Why it's wrong here

  Modifying the DB instance to Single-AZ before applying the upgrade is fundamentally counterproductive because it removes the standby replica that Multi-AZ provides, meaning the instance will have no failover target during the maintenance operation. Without a standby, RDS must patch the single DB instance in place, which requires stopping the database engine and restarting it with the new version—resulting in a full outage for the duration of the maintenance, rather than the brief failover blip of Multi-AZ. Additionally, this change itself triggers a database restart and temporarily removes the high-availability protection that would otherwise guard against hardware failures or crashes during the upgrade window, so it both increases downtime and decreases resilience.

• ✗

  Take a snapshot, restore it as a new instance, and upgrade that instance.

  Why it's wrong here

  Taking a snapshot, restoring it as a new instance, and upgrading that restored instance is incorrect because it creates a separate, independent database environment that is not tied to the original instance's ongoing transactions; any data written to the original primary after the snapshot was taken is permanently absent from the restored copy. The snapshot captures a point-in-time state, so the restored instance will be stale by however much time elapses between the snapshot creation, the restore process, and the upgrade itself, making this approach unsuitable for a production Multi-AZ database that must remain current. Even if you accepted the data loss, you would also need to manually redirect all applications to the new instance's endpoint, manually configure security groups, parameter groups, and monitoring, and the upgrade would still involve downtime during the restore and upgrade phases—making this a longer, riskier, and more complex procedure than simply applying the maintenance update to the existing Multi-AZ instance.

• ✗

  Create a read replica in the same region, upgrade the replica, and promote it.

  Why it's wrong here

  Promoting a read replica after upgrading it is unsuitable for a Multi-AZ instance requiring a planned engine version upgrade. Read replicas are asynchronous; promoting one would result in data loss if the original primary continued receiving writes during the upgrade and cutover. This method is tempting because it is a common strategy to minimise downtime for *major version upgrades* on a *Single-AZ* RDS instance, allowing pre-upgrade testing and a controlled cutover.

Go deeper

Related to this question