A regional library consortium wants a database in another cloud region that continuously receives changes so failover is much faster than restoring from nightly backups. Which approach matches that need?
Select an answer to reveal the explanation.
Short Explanation
A warm standby is like a spare engine already turning over in the other garage. Updates keep flowing, so failover is not a rebuild from last night's box of parts. That continuous feed is why it beats backup-only recovery for speed.
Full Explanation
Replication to a warm standby continuously or near-continuously applies changes to a secondary database in another region so failover can be much faster than reconstituting from nightly backups. For a regional library consortium, that pattern keeps a usable, recently consistent copy ready when the primary region fails, shortening citizen-facing downtime for catalog and account services compared with tape or nightly-restore timelines.
Shipping encrypted tapes to the remote region once per quarter creates a cold, stale recovery point unsuitable for fast failover. Keeping a powered-off cold image that is never updated until disaster day leaves a large data gap and long bring-up time. Relying on infrastructure-as-code templates without any data copy rebuilds empty infrastructure, not the library database contents patrons need.
Exam caveat: warm standby implies ongoing replication and a running or readily promotable secondary; hot/warm/cold describe readiness and cost, not merely "another region exists." Also distinguish asynchronous replication lag from RPO.
Operational check: verify replication health and lag against the consortium’s RPO, rehearse promoting the standby and redirecting application connection strings or DNS, and document failback. Confirm encryption, access controls, and regional placement still meet library privacy policies after failover.