A city backup process writes unencrypted snapshots to the same account that runs production workloads, with no isolated copy for ransomware recovery. What secure backup redesign should architects implement?
Select an answer to reveal the explanation.
Short Explanation
Backups that live next to production without a lock are like spare house keys under the same doormat attackers already flipped. Encrypt them and park a copy in a separate account. Ransomware resilience is about distance and keys, not hope.
Full Explanation
Unencrypted snapshots kept only in the same account as production leave a city backup process unable to survive account compromise or ransomware that deletes local recovery media. Encrypting backups with KMS and replicating or copying them to an isolated backup account—commonly with AWS Backup—creates recovery media that survives production-account failure. That redesign works because secure backups require confidentiality, integrity, and isolation, not merely local snapshot existence. Keeping unencrypted snapshots in production and deleting CloudTrail to hide restore activity fails on encryption, isolation, and auditability. Storing the only backup copy on an administrator laptop synced over personal cloud storage fails conceptually as unmanaged, noncompliant recovery for municipal systems. Disabling backups during fiscal year-end because ransomware risk is “theoretical” fails risk governance when attackers preferentially target backup deletion. Exam caveat: isolated copies still need restore testing and least-privilege access to the backup account—backups that cannot be restored within RTO are theater. Operational check: enable AWS Backup with KMS CMKs, copy critical vaults to an isolated account, run a restore drill for a sample database volume, and verify CloudTrail records backup and restore APIs.