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
Logical corruption from a damaged schema deploy is not healed by Multi-AZ failover. The standby mirrors the primary’s logical state, including the bad migration, so failing over simply promotes the same corruption. Architects must use point-in-time restore or equivalent backups to recover to a time before the bad deploy. High availability protects against infrastructure failure; backups and PITR protect against operator and application mistakes that replicate to standbys in a municipal database.
Forcing Multi-AZ failover immediately because the standby “always holds a pre-corruption logical copy” is false for synchronous HA standbys that apply the same commits. Deleting all snapshots so the corrupt schema becomes the only source of truth destroys recovery options when courts or finance need yesterday’s clean data. Disabling automated backups to speed future deploys removes the PITR capability the city will need the next time a migration goes wrong.
Exam caveat: Multi-AZ is not protection from bad writes; PITR and backups are the answer for logical corruption questions on SAP-C02. Operational check: ensure automated backups and PITR retention cover the municipal database, practice restoring to a timestamp before a simulated bad migration in a nonprod clone, and keep deploy runbooks that pause backup deletion during release windows.