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 Amazon Data Lifecycle Manager (DLM) to take EBS snapshots every 15 minutes and automate the creation of a new AMI.

  Why it's wrong here

  Amazon Data Lifecycle Manager (DLM) automates EBS snapshot schedules but cannot directly create an AMI; you would need an additional step to register a new AMI from the latest snapshot and then launch an instance from it. Rebuilding an EC2 instance from a snapshot involves creating EBS volumes, attaching them, and initializing the root volume, which can easily push the recovery time beyond the 30-minute RTO even though the 15-minute snapshot schedule satisfies the RPO. Also, a newly launched instance has no pre-configured startup dependencies unless you have orchestrated the full recovery via scripts or CloudFormation, adding further delay and operational risk.

• ✗

  Use AWS Backup to schedule backups every 15 minutes and restore from the latest backup when needed.

  Why it's wrong here

  AWS Backup provides centrally managed backup policies and supports cross-account or cross-region copies, but behind the scenes it still relies on EBS snapshots for EC2 recovery. While a 15-minute backup schedule meets the RPO, restoring an instance requires creating new volumes from those snapshots, attaching them to a new instance, and waiting for the storage to become fully available — steps that typically take longer than 30 minutes when you include validation and reconfiguration of the recovered workload. AWS Backup does not maintain a running replacement in the target region, so it fails the RTO requirement despite offering a more polished backup lifecycle than DLM.

• ✓

  Use AWS Elastic Disaster Recovery (AWS DRS) to continuously replicate the instance to a staging area in another region.

  Why this is correct

  AWS Elastic Disaster Recovery (AWS DRS) continuously replicates block-level changes from the source EC2 instance to a staging area in a second region using a lightweight agent, with typical RPO in the seconds and RTO in the single-digit minutes. DRS maintains a converted, continuously updated copy of the source volumes on low-cost staging instances, so at failover time it simply powers on the target instance using the latest replicated state rather than constructing it from snapshots. This always-ready, continuous replication approach is precisely what is required to meet a 30-minute recovery window while ensuring data loss is limited to a few seconds.

• ✗

  Use an Auto Scaling group with a custom AMI that is updated every 15 minutes by a Lambda function.

  Why it's wrong here

  Creating a new AMI every 15 minutes through a Lambda function is a heavyweight, error-prone process: each AMI creation fully snapshots the root volume, and if any data changes during the snapshot the AMI can be crash-consistent but not application-consistent. Even if the AMI is valid, launching an instance from it only gets you to the state at the moment the AMI was created, so any writes that occur after that point — including database transactions or uploaded files — are lost unless the application is stateless and all state is stored in an external service. Additionally, Auto Scaling groups are designed for elasticity, not precise failover; the group will not automatically launch in a different region, so this approach fails the multi-region disaster recovery requirement while adding significant cost and operational complexity.

Go deeper

Related to this question