The tax database requires reliable recovery after corruption or ransomware. Which backup design elements are most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Tax data needs backups on a schedule that matches how much work you can afford to redo, plus encrypted copies that live somewhere else—not forever glued to the same server ransomware just locked. A dusty USB on a desk is a wish, not a design.
Full Explanation
Backup design for municipal tax systems must set frequency to meet recovery point objectives—how much recent work the city can afford to lose—and must keep encrypted copies both protected onsite and stored offsite so ransomware or facility loss cannot destroy every instance. Encryption protects confidentiality if media or cloud objects are stolen; offsite copies break dependency on the production host that attackers often encrypt first.
Never encrypting backups and leaving the only copy permanently attached to the production server invites simultaneous loss of live data and backups in one incident. Backing up once per decade to an unlocked USB on a clerk’s desk fails frequency, confidentiality, and custody. Disabling backups after the first full run to save storage abandons ongoing change protection.
Exam caveat: the 3-2-1 style thinking (multiple copies, varied media, offsite) underlies many exam answers even when not named. Frequency alone is insufficient without offline/offsite and encryption for sensitive tax data.
Operational check: align backup schedules with tax-processing RPO, encrypt backup sets and vault keys separately from the production domain when feasible, verify offsite or immutable copies restore cleanly, and remove forever-mounted backup shares that ransomware can reach as easily as the database.