Q: An AWS S3 bucket holding company financial reports suffered a ransomware attack. An attacker gained access, enabled AWS KMS encryption using their own key (which they control), and locked out your access to read the files because you don't have access to their KMS key to decrypt it. How do you architect the bucket to prevent this entirely?

Standard S3 versioning is not enough here, as the attacker could maliciously encrypt the latest version *and* delete previous versions.

• Enable S3 Versioning and Object Lock on bucket creation.
• Configure a default retention period (e.g., 7 years) in Compliance Mode.

To mathematically prevent ransomware and ensure immutability, we must implement S3 Object Lock in Compliance Mode. When a file is written under Compliance Mode, it becomes WORM (Write Once, Read Many). Absolutely *no one*, not even the AWS Account Root User, can delete or modify the object version until the retention period expires. If an attacker uploads an encrypted version over the file, the previous completely unencrypted version is perfectly preserved, locked, and fully recoverable because the attacker is physically blocked by the AWS control plane from deleting it.