A county ERP team wants a cost-aware multi-Region DR design that keeps a minimal core warm in a second Region and scales out only when disaster strikes. Which pattern is that?

Pilot light DR—keeping a minimal core such as a cross-Region database replica and golden AMIs in the standby Region, then scaling compute out on failover—matches a county ERP team’s cost-aware multi-Region design. The pattern works because the expensive application tier stays mostly off until disaster day, while critical data replication and machine images remain pre-positioned so recovery is faster than pure backup/restore. When failover is declared, the county scales ECS/EC2 and load balancers from those golden artifacts, promotes or points applications at the DR data tier, and brings ERP online without having paid for continuous full production capacity in two Regions. That balance is the Associate-level intent of pilot light.

Active-active with equal production capacity in both Regions for every ERP transaction path fails by concept because it maximizes availability and cost with continuous dual serving, which contradicts the cost-aware minimal-core requirement. Backup and restore only, with zero resources or replicas pre-positioned in any second Region, fails because it lacks the warm minimal core that distinguishes pilot light and typically lengthens RTO beyond what a prepared replica/AMI posture provides. Labeling single-AZ or even Multi-AZ RDS in one Region as multi-Region DR fails because Multi-AZ is an Availability Zone HA feature inside one Region; it does not place a DR core in a second Region.

Exam caveat: pilot light RTO depends on automation quality—manual AMI hunting and quota surprises can erase the theoretical advantage over backup/restore. Operational check: keep the ERP replica lag monitored, store launch templates/AMIs in the DR Region, pre-approve EC2/ELB quotas, and run a game day that scales the app tier from pilot light to a defined ERP capacity target within the documented RTO.