A regional online bookmaker runs its punter-facing wagering platform in a single public cloud region in Sydney. The chief risk officer has set a recovery time objective of fifteen minutes and a recovery point objective of one minute for the wagering service, because a regional outage during a major race meeting would expose the firm to refund liabilities and reputational harm within a single hour. The current architecture replicates database snapshots to a second region every six hours, and application servers in the second region are powered off until needed. The security architect must propose the site resiliency model that most directly satisfies the stated RTO and RPO without overspending on an unnecessary tier. Which site resiliency design should she recommend?
- ARetain the current cold site model in the second region and improve runbook automation so engineers can power on the standby instances and restore the six-hour snapshot within the fifteen-minute window during an incident.
- BAdopt an active-active hot site across two regions with synchronous database replication, traffic served from both regions through a global load balancer, and automated health checks that withdraw an unhealthy region from rotation within seconds. Correct
- CMove to a warm site in the second region with pre-provisioned but idle application instances, daily database restores, and a documented manual cutover that the team rehearses each quarter.
- DKeep the production region as is and rely on a cloud provider service level agreement plus regional autoscaling to absorb any regional disruption without a documented site resiliency model.
Why A is wrong: A cold site keeps standby capacity powered off and relies on restoring point-in-time backups, which is appealing because it is the cheapest tier and the team is already familiar with it; however, the six-hour snapshot cadence cannot meet a one-minute RPO no matter how fast engineers act, and provisioning, starting and configuring instances during an incident is almost never compatible with a fifteen-minute RTO.
Why B is correct: An active-active hot site keeps full production capacity running in both regions and shares live traffic between them, so a regional failure is absorbed by the surviving region without a cold start; synchronous replication keeps the standby data within seconds of the source, which is the only one of the offered designs that can credibly meet a fifteen-minute RTO and a one-minute RPO for a high-value betting workload.
Why C is wrong: A warm site shortens recovery compared with cold standby because compute is already provisioned, which is tempting given the team's preference for manual cutovers it can audit; even so, daily restores cannot satisfy a one-minute RPO, and a manual cutover is unlikely to complete within fifteen minutes once detection, paging and validation are included.
Why D is wrong: Leaning on the provider SLA and autoscaling is attractive because it appears to remove operational burden, yet an SLA is a commercial credit mechanism rather than a recovery control, and autoscaling inside a failed region cannot help when the region itself is unavailable, so neither the RTO nor the RPO is actually engineered.