A statewide alerts system targets multi-site active-active DR. What implication must the architecture address beyond duplicating web tiers?
Select an answer to reveal the explanation.
Short Explanation
Two pretty front doors aren’t active-active if the filing cabinets fight each other. You need dual-Region data, conflict rules, and global routing. DNS fairy dust or static HTML mirrors won’t keep statewide alerts consistent.
Full Explanation
A statewide alerts system targeting multi-site active-active DR must address dual-Region data replication, conflict handling, and global traffic routing—not merely duplicated web front ends. Two ALBs without a data strategy invite split-brain writes, stale reads, and unclear authoritative state during Regional events. Active-active implies health-checked traffic steering (Route 53, Global Accelerator, or similar) plus an application-aware replication model for alert state.
Claiming no data strategy is needed if two ALBs exist, because DNS alone prevents write conflicts, ignores database and messaging consistency entirely. Asserting that active-active never requires health checks or traffic steering leaves failed Regions still receiving users. Restricting the second Region to static HTML mirrors only is not multi-site active-active for a statewide alerts system that must accept and process writes.
Exam caveat: active-active is more than redundant web tiers—data plane design and global routing are the hard parts examiners expect you to call out. Operational check: define the alerts data replication model and conflict rules, place health checks on both Regions, rehearse traffic shift, and verify read/write behavior when one Region is isolated.