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 AWS CloudEndure to continuously replicate the EC2 instances to another Region.

  Why it's wrong here

  AWS CloudEndure (now AWS Elastic Disaster Recovery) is a block-level continuous replication service that maintains a warm standby environment in the target Region, which can meet a 15-minute RPO and often sub-1-hour RTO. However, it requires deploying an agent on each source instance, running staging resources (e.g., replication servers, staging subnets) continuously, and paying per-hour licensing plus the cost of the replicated storage and any test failovers. For this scenario, EBS snapshots every 15 minutes with cross-region copying achieve the same RPO/RTO at a fraction of the operational and financial overhead, making CloudEndure overprovisioned for a simple, cost-conscious DR design.

• ✗

  Use AWS Backup to back up the application data to Amazon S3 every 15 minutes.

  Why it's wrong here

  AWS Backup can schedule resource backups, but backing up 'application data' to Amazon S3 every 15 minutes does not capture the full EC2 instance state—OS, installed patches, configuration, and local ephemeral data—so a failover in the disaster Region would require rebuilding instances from scratch. Moreover, copying application data to S3 is not a native block-level image; you would need a separate orchestration process to restore that data onto new volumes, which is likely to exceed the 1-hour RTO. While S3 offers 11 nines of durability, it is a standalone object store, not a live recovery target for EC2 instances, so this approach fails to provide a comprehensive, automated DR solution.

• ✗

  Take hourly AMIs of the instances and copy them to another Region.

  Why it's wrong here

  Creating AMIs hourly and copying them to another Region gives you a recovery point that is, on average, 30 minutes old, but the requirement is a 15-minute RPO—meaning the maximum acceptable data loss is 15 minutes. An hourly schedule would allow up to 60 minutes of lost changes, which violates the stated RPO. Additionally, AMI creation is a heavier operation than EBS snapshots (it registers an image, and the initial copy may take time), and while you could take AMIs more frequently, EBS snapshots every 15 minutes are more granular and cost-effective because snapshots only store changed blocks, whereas AMIs duplicate the full volume metadata for each image generation.

• ✓

  Take EBS snapshots every 15 minutes and copy them to another Region using cross-region snapshot copy.

  Why this is correct

  EBS snapshots are block-level, incremental backups of your EC2 volumes, so taking them every 15 minutes captures only the changed blocks since the previous snapshot, keeping storage costs low while meeting the 15-minute RPO. Using cross-region snapshot copy asynchronously replicates those snapshots to the DR Region, ensuring you have recent recoverable point-in-time data there without needing to keep duplicate running instances. On failover, you can create new EBS volumes from the latest snapshot, attach them to pre-provisioned or restored EC2 instances, and start the application—comfortably within a 1-hour RTO because snapshot-to-volume creation is fast and the infrastructure can be pre-staged as a stopped AMI or launch template.

Go deeper

Related to this question