A company runs its order database in a single cloud region. Management wants the database to keep serving orders if one data center in that region loses power, and the standby must stay close enough for synchronous commits with low latency. Which design best meets these requirements?
Select an answer to reveal the explanation.
Short Explanation
Think of a multizone region as one city with several independent power grids. You put your standby across town, not in the next rack, so one blackout can't take both, yet it's close enough that synchronous commits stay fast. The trap is going far away: another region survives the outage too, but synchronous writes over hundreds of miles make every commit crawl.
Full Explanation
A multizone region (MZR) contains several availability zones, each a physically separate facility with independent power, cooling and networking, joined by low-latency links. Placing the primary in one zone and a synchronous standby in another removes the data center as a single point of failure while keeping round-trip times short enough that waiting for the standby's acknowledgment adds little to commit time. If one zone loses power, the standby is promoted with no committed data lost. Putting both nodes on separate hosts in the same zone protects against a server failure but not against the facility-wide power loss the scenario describes, because both hosts share the zone's infrastructure. Synchronous replication to a distant region does survive the outage, but every commit must wait for a long-distance round trip, which violates the low-latency requirement; distant regions are normally served by asynchronous geo-replication for disaster recovery instead. Hourly snapshots kept in the same zone are neither high availability nor safe from the outage, since they are lost with the zone and restoring them takes time and loses up to an hour of data. Exam caveat: MZR protects against a zone failure, not against loss of the whole region. Operational check: confirm the two nodes report different zone identifiers and run a planned failover test to measure promotion time.