Protecting object storage from accidental loss

WHAT THIS TESTS The interviewer wants you to separate built-in durability from protection against the real threats: human mistakes, buggy code, and malicious actors.

A GOOD ANSWER COVERS Start by noting that high durability protects against disk and hardware loss, not against someone deleting or overwriting an object. So layer defenses. Enable versioning, which keeps prior versions when an object is overwritten or deleted, turning a destructive delete into a recoverable delete-marker. Add immutability through object lock or MFA delete, so objects under retention cannot be altered or removed even by an administrator, defending against ransomware and fat-finger deletes. Replicate critical data to a second region or, better, a separate account, isolating the blast radius from a compromised or misconfigured primary. Enforce least-privilege IAM so only a small set of principals can delete, and use lifecycle rules to expire old versions on a schedule rather than letting humans delete manually.

COMMON WRONG ANSWERS Trusting the advertised durability figure as if it prevented accidental deletion. Enabling versioning but granting broad delete permissions that can purge all versions. Replicating within the same account, so one compromised credential affects both copies. Forgetting that without object lock, an attacker with sufficient rights can delete versions too.

LIKELY FOLLOW-UPS How does a delete-marker work with versioning. Object lock governance versus compliance mode. Why replicate to a separate account, not just a region. How do lifecycle rules prevent version sprawl and cost blowup.

ONE CONCRETE EXAMPLE A fintech stores transaction records in an object store with versioning on, object lock in compliance mode for a seven-year retention so nothing can be deleted early, and cross-account replication to a locked-down archive account. IAM grants delete rights to no human, only an automated lifecycle process. When an engineer accidentally overwrites a file, the prior version is intact, and even a compromised admin credential cannot erase the locked records.