A citizen portal needs a faster RTO than pilot light and can afford a scaled-down but always-running copy in another Region. Which DR pattern matches?

Warm standby—operating a scaled-down but always-on copy of the citizen portal stack in the DR Region and scaling up on failover—matches the need for a faster RTO than pilot light while avoiding full active-active cost. The pattern works because critical tiers already run at reduced capacity, so DNS or traffic cutover does not wait to boot an entire environment from a cold minimal core. On disaster declaration, the city scales the DR Auto Scaling groups, database capacity, and related services up to production levels and shifts users, achieving lower RTO than pilot light at higher steady-state cost than backup/restore. That trade-off is exactly what “faster than pilot light, scaled-down always-running copy” describes.

Pilot light with no running application instances until a disaster is declared fails by concept here because the question requires a scaled-down but always-running application copy; pilot light keeps only a minimal core and therefore yields a longer bring-up path. Backup and restore with only weekly snapshots and no pre-deployed compute fails because weekly snapshots may miss tighter RPO needs and the absence of pre-deployed compute stretches RTO well beyond warm standby. Active-active with identical full capacity and active user traffic in both Regions by default fails because that pattern serves production continuously in multiple Regions at full cost, which exceeds the scaled-down standby intent.

Exam caveat: warm standby still needs data replication lag monitoring; a running small app tier with stale data can fail over “fast” to the wrong content. Operational check: keep DR portal instances healthy behind a DR ALB at reduced desired count, automate scale-up runbooks, and time a failover drill from primary unhealthy to DR serving peak-like capacity within the portal’s RTO objective.