A records system keeps daily Amazon RDS snapshots with a 365-day retention 'just in case,' far beyond the city's documented 7-day recovery policy. What should the architect recommend for backup cost?
Select an answer to reveal the explanation.
Short Explanation
Keeping a year's daily snapshots when policy only asks for a week is paying rent on a storage attic you never visit. Match retention to the 7-day rule and stop funding forever-backups.
Full Explanation
Aligning automated snapshot retention to the city’s documented 7-day recovery policy instead of retaining 365 daily snapshots indefinitely is the correct backup-cost recommendation for the records system. Snapshot storage cost grows with retention length and frequency; keeping a year of daily snapshots when policy only requires a week funds an attic that policy never visits. Keeping 365 daily snapshots forever and disabling lifecycle reviews fails by ignoring documented RPO needs and removing the governance that caps backup spend. Replicating every snapshot to three commercial clouds without encryption fails by multiplying storage cost and creating security/compliance exposure with unencrypted copies. Deleting all snapshots including the last seven days of coverage fails by destroying the recovery window the policy requires. Exam caveat: set RDS automated backup/snapshot retention to documented policy (here seven days); do not keep forever chains, unencrypted multi-cloud sprawl, or zero recent recovery points. Operational check: update automated backup retention to 7 days; inventory manual snapshots older than policy; delete only after confirming no legal hold; enable encryption for remaining copies; and calendar a quarterly backup-retention audit against the city’s records recovery policy.