Protecting object storage from accidental loss
data durability and recovery design.
enable versioning, MFA delete or object lock, cross-region replication, and least-privilege policies.
What's really being asked
The interviewer wants you to separate built-in durability from protection against the real threats: human mistakes, buggy code, and malicious actors.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Why is a service's advertised eleven-nines durability insufficient protection for critical object data?
- a.Durability is only achieved with cross-region replication enabled
- b.Durability figures only apply to data under one gigabyte
- c.It guards against hardware loss, not accidental deletion, corruption, or malicious removalCorrect
- d.It expires after the first ninety days of storage
Why? this is the answer
Eleven-nines durability addresses physical media failure, but a human or buggy process can still delete or overwrite objects. Versioning and object lock, not the durability number, protect against those threats.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #object-storage
- #versioning
- #object-lock
- #data-protection
- #replication
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles