A parks-and-recreation registration app still uses a single-AZ Amazon RDS instance. An AZ impairment would take citizen payments offline with no tested failover. Which reliability remediation should the team implement first?
Select an answer to reveal the explanation.
Short Explanation
One AZ is one blown fuse away from angry parents who cannot sign kids up for summer camp. Flip the database to Multi-AZ and actually practice the failover—paper plans do not cash checks.
Full Explanation
A parks-and-recreation registration app on single-AZ Amazon RDS would lose citizen payments during an AZ impairment with no tested failover. Converting to Multi-AZ RDS, documenting and rehearsing failover, and verifying the application reconnects within the registration RTO is the first reliability remediation. That change works because Multi-AZ provides synchronous standby failover for infrastructure AZ loss, which single-AZ cannot offer, and rehearsal proves the app layer actually recovers. Adding a second reader in the same AZ only and treating it as full DR fails because same-AZ readers share the failure domain and readers are not automatic writer failover. Turning off automated backups to reduce failover complexity fails conceptually by sacrificing recoverability while solving nothing about AZ loss. Snapshotting annually to Glacier Flexible Retrieval and stopping there fails RTO for online payments and is not a substitute for Multi-AZ. Exam caveat: Multi-AZ is not multi-Region; if RTO/RPO require Regional independence, plan cross-Region separately after Multi-AZ basics are sound. Operational check: enable Multi-AZ, run a controlled failover in a maintenance window, time app reconnection against the registration RTO, fix connection-pool retry settings if needed, and record evidence for the reliability review.