A damaged schema deploy corrupts data in a municipal database. Multi-AZ failover alone does not fix the logical corruption. What should the architect rely on?
Select an answer to reveal the explanation.
Short Explanation
Multi-AZ is a twin that hears the same bad gossip—failover won’t un-speak a broken schema deploy. Point-in-time restore rewinds to before the mistake. Wiping snapshots or turning backups off digs the hole deeper.
Full Explanation
Multi-AZ standby replicas continuously apply the same committed changes as the primary, including erroneous DDL/DML, so failover does not remove logical corruption. Point-in-time restore from automated backups (or tested snapshot restores) recovers to a timestamp before the damaging deploy. Deleting backups or disabling automation removes the remediation path. Architects must pair HA with backup/PITR for human and application errors.