A customer-facing database must stay available during monthly operating system and database patching, which currently requires a two-hour outage window. Which configuration allows patching with only a brief interruption?
Select an answer to reveal the explanation.
Short Explanation
High availability is like a relay team: one runner can step off the track for a break while the other keeps going. You patch the standby, hand the baton over, then patch the old primary. Backups and snapshots help you undo a bad patch, but they don't keep you running during it.
Full Explanation
High availability is designed to keep a service running through planned and unplanned component outages. With a cluster or a set of synchronized replicas that supports failover, patching becomes a rolling operation: the DBA patches the secondary node while the primary serves traffic, fails over so the patched node becomes primary, which causes only a brief interruption while connections move, then patches the former primary and optionally fails back. Each node is offline only while it is not serving clients. Patching during the backup window does nothing for availability; a backup runs alongside normal activity, and patching still takes the database offline for the full duration. Taking a full backup before patching is good practice for recovery, but restoring onto a second server only after a delay is a recovery plan, not continuous availability, and it would mean a much longer outage. A storage snapshot provides a fast rollback point if the patch fails, but the database is still offline for the entire patch, so the outage window is unchanged. Exam caveat: high availability addresses uptime within a site or region, while disaster recovery addresses loss of a site; the two complement each other. Operational check: during the next patch cycle, record the client-visible interruption at failover and confirm both nodes are on the same version afterward.