This chapter covers Amazon S3 Versioning and MFA Delete, two critical features for data protection and resilience. Understanding these features is essential for the SAA-C03 exam, as they appear in questions about data durability, disaster recovery, and security best practices. Approximately 5-10% of exam questions touch on S3 data protection mechanisms, including versioning and MFA Delete. By the end of this chapter, you will understand how versioning works at the object level, how to enable and manage it, and how MFA Delete adds an extra layer of security.
Jump to a section
Imagine a public library where patrons can borrow and return books. Normally, if someone returns a book, the old record is simply overwritten. But the library decides to keep a complete history of every version of every book ever checked out—like a time machine for each book. This is S3 versioning. Now, consider a special 'permanent collection' that cannot be removed from the library. To delete a book from this collection, you need two keys: one from the librarian and one from the library director. The librarian's key is like your AWS credentials; the director's key is like a physical MFA token. The director must personally approve the deletion by presenting their token. Without both keys, the book stays forever. In S3, MFA Delete works similarly: to permanently delete a version or suspend versioning, you must provide a one-time code from a hardware MFA device. This prevents accidental or malicious deletion of critical data, even if your AWS credentials are compromised. The library's checkout system logs every action, just as S3 logs all operations with versioning enabled.
What is S3 Versioning?
Amazon S3 Versioning is a means of keeping multiple variants of an object in the same bucket. When you enable versioning on a bucket, S3 preserves every object creation, update, and deletion as a separate version. This protects against accidental overwrites and deletions, and provides a built-in backup for recovery.
Why Use Versioning?
The primary use cases are: - Data protection: Recover from accidental overwrites or deletions. - Backup and archive: Retain historical versions for compliance or rollback. - Lifecycle management: Automate transition or expiration of old versions.
Versioning is a prerequisite for other S3 features like Lifecycle policies, replication, and MFA Delete.
How Versioning Works Internally
When you upload an object to a bucket with versioning enabled, S3 assigns a unique version ID to the object. If you upload another object with the same key, S3 does not overwrite the original; instead, it creates a new version with a new version ID. The original version remains accessible via its version ID.
Version ID: A string generated by S3. You cannot specify it; it is automatically assigned. Example: ydla3hGJkF9kL7a6
Null version: Objects uploaded before versioning was enabled receive a version ID of null. This helps maintain backward compatibility.
Delete marker: When you delete an object, S3 does not remove the object. Instead, it adds a delete marker, which is a placeholder that hides previous versions. The delete marker itself has a version ID.
Enabling Versioning
Versioning is enabled at the bucket level. You can set it via AWS Management Console, AWS CLI, or SDK.
- States: - Suspended: Versioning is disabled. New uploads do not create multiple versions. Existing versions remain. - Enabled: Versioning is active. Each upload creates a new version. - Once enabled, you cannot disable versioning completely. You can only suspend it. Suspension means new objects do not get version IDs, but existing versions remain and are still accessible.
Key Behavior and Timers
Versioning is applied to all objects in the bucket. You cannot enable versioning for individual objects.
Versioning is irreversible in the sense that you cannot go back to a non-versioned state. Once enabled, you can only suspend.
There is no timer for versioning itself. It is always on once enabled.
Lifecycle rules can expire noncurrent versions after a specified number of days (e.g., 30 days).
MFA Delete
MFA Delete is an optional security feature that requires multi-factor authentication to permanently delete an object version or to change the versioning state of a bucket.
- What it protects: - Permanently deleting a version (i.e., deleting a specific version ID). - Suspending or enabling versioning on the bucket. - What it does NOT protect: - Creating a delete marker (which hides versions but does not permanently erase them). - Overwriting an object (which creates a new version). - Reading or listing objects.
How MFA Delete Works
To perform a protected operation, you must include the x-amz-mfa header in your request. The header value is the concatenation of your MFA device's serial number and the current one-time code. For example:
x-amz-mfa: arn:aws:iam::123456789012:mfa/device-name 123456The code is generated by a hardware or virtual MFA device. The AWS CLI supports MFA Delete via the --mfa parameter.
Enabling MFA Delete
MFA Delete can only be enabled by the AWS account root user or a user with the appropriate permissions (e.g., s3:PutBucketVersioning with MFA condition). To enable it:
Enable versioning on the bucket.
Use the AWS CLI or SDK to set the MFA Delete configuration.
Example CLI command:
aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam::123456789012:mfa/device-name 123456"Interaction with Related Technologies
Lifecycle Policies: Lifecycle rules can expire current or noncurrent versions. However, if MFA Delete is enabled, you cannot permanently delete a version via lifecycle (lifecycle does not support MFA).
Replication: Versioning is required for S3 replication. Replication replicates all versions, including delete markers.
Object Lock: Versioning is required for Object Lock. Object Lock provides Write Once Read Many (WORM) protection, independent of MFA Delete.
Logging: S3 server access logs record version IDs for all requests.
Permanent Deletion vs. Delete Marker
Delete marker: A placeholder that hides previous versions. It is NOT a permanent deletion. You can delete the delete marker to restore the object.
Permanent deletion: Deleting a specific version ID. This action is irreversible. MFA Delete protects this action.
Cost Implications
Each version counts as a separate object, incurring storage costs.
Lifecycle policies can help manage costs by expiring old versions or transitioning them to cheaper storage classes (e.g., S3 Glacier).
Security Considerations
Root user only: Only the AWS account root user can enable MFA Delete. However, any user with the s3:PutBucketVersioning permission can suspend versioning if MFA Delete is not enabled.
MFA Delete is a bucket-level setting. It applies to all objects in the bucket.
MFA Delete does not prevent accidental overwrites. Overwrites create new versions; the old version remains.
Exam Relevance
For SAA-C03, focus on:
The difference between delete marker and permanent deletion.
That MFA Delete protects only permanent deletions and versioning state changes.
That versioning is required for replication and Object Lock.
That once enabled, versioning can only be suspended (not disabled).
That MFA Delete requires the root user or a user with explicit permissions and MFA.
Enable Versioning on Bucket
First, you must enable versioning on the S3 bucket. You can do this via the AWS Management Console by selecting the bucket, going to the Properties tab, and under Bucket Versioning, clicking Enable. Alternatively, use the AWS CLI: `aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled`. Once enabled, any subsequent PUT or DELETE operations on objects will create versions. Existing objects before versioning receive a null version ID.
Upload Object Creates Version
When you upload an object to a versioned bucket, S3 assigns a unique version ID. For example, uploading `file.txt` creates version `abc123`. If you upload the same key again, S3 creates a new version `def456`. Both versions are stored separately. You can access a specific version by specifying its version ID in GET requests. Without a version ID, S3 returns the latest version.
Delete Object Creates Delete Marker
When you delete an object from a versioned bucket, S3 does not remove the object. Instead, it creates a delete marker with a new version ID. This marker hides all previous versions. To restore the object, you delete the delete marker. If you perform a permanent delete (specifying a version ID), that version is removed forever. MFA Delete can protect this action.
Enable MFA Delete on Bucket
MFA Delete can only be enabled by the root user or a user with `s3:PutBucketVersioning` and MFA condition. You must provide the MFA serial number and a one-time code. Example CLI: `aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam::123456789012:mfa/device-name 123456"`. Once enabled, any attempt to permanently delete a version or change versioning state must include a valid MFA code.
Attempt Permanent Deletion with MFA
To permanently delete a version when MFA Delete is enabled, you must include the `x-amz-mfa` header. For example, using AWS CLI: `aws s3api delete-object --bucket my-bucket --key file.txt --version-id abc123 --mfa "arn:aws:iam::123456789012:mfa/device-name 654321"`. If the MFA code is missing or invalid, the request fails with AccessDenied. This prevents unauthorized permanent deletions.
In enterprise environments, S3 Versioning and MFA Delete are often deployed together to protect critical data. Consider a financial services company that stores transaction logs in S3. They enable versioning to retain a history of all log entries, allowing auditors to review past versions. They also enable MFA Delete on the bucket to prevent any permanent deletion of logs, even if an employee's credentials are compromised. This ensures compliance with regulatory requirements like SEC Rule 17a-4.
Another scenario is a healthcare organization using S3 for medical imaging. Versioning allows them to keep multiple versions of patient scans, enabling radiologists to compare current and previous images. MFA Delete is enabled to prevent accidental or malicious deletion of patient data, which could violate HIPAA. The organization configures lifecycle policies to transition old versions to S3 Glacier after 90 days to reduce costs.
A common misconfiguration is enabling versioning but forgetting to set up lifecycle policies. Over time, storage costs skyrocket because every upload creates a new version that never expires. For example, a DevOps team might upload a configuration file hundreds of times a day, accumulating thousands of versions. Without lifecycle rules to expire noncurrent versions after a reasonable period, costs become unsustainable.
Another issue is misunderstanding MFA Delete scope. Some engineers believe MFA Delete protects against all deletions, but it only protects permanent deletions and versioning state changes. If an attacker gains access and creates a delete marker, the data is hidden but not destroyed. However, if the attacker also has MFA access, they could permanently delete versions. Therefore, MFA Delete should be combined with strong IAM policies and monitoring.
In production, MFA Delete is typically enabled only on buckets with critical, immutable data. Operations teams must have a process for requesting MFA codes from authorized personnel. This adds friction but provides strong protection. For less critical buckets, versioning alone may suffice.
The SAA-C03 exam tests S3 Versioning and MFA Delete under Domain 2: Resilient Architectures, Objective 2.4: 'Design resilient storage.' Specifically, you need to understand versioning as a data protection mechanism and MFA Delete as a security control.
Common wrong answers include: - 'MFA Delete prevents all deletions from the bucket.' This is false. MFA Delete only prevents permanent deletions (deleting a specific version ID) and changes to versioning state. Creating a delete marker (which hides the object) is not protected. - 'Once versioning is enabled, it cannot be suspended.' This is false. You can suspend versioning, but you cannot disable it entirely. Suspension means new uploads do not create versions, but existing versions remain. - 'Versioning is required for cross-region replication.' This is true, but many candidates think it is optional. Replication requires versioning to track changes. - 'MFA Delete can be enabled by any user with s3:PutBucketVersioning permission.' This is false. Only the root user can enable MFA Delete. However, a user with the permission can suspend versioning if MFA Delete is not enabled.
Key numbers and terms to remember:
Version IDs are automatically generated strings (e.g., ydla3hGJkF9kL7a6).
The x-amz-mfa header is used for MFA Delete requests.
MFA Delete is a bucket-level setting, not object-level.
Lifecycle policies can expire noncurrent versions after a specified number of days.
Edge cases:
If you delete an object without specifying a version ID, S3 creates a delete marker. This is not protected by MFA Delete.
If you suspend versioning, existing versions are still accessible. Any new uploads without a version ID are stored as null version.
You can permanently delete a delete marker to restore the object. This action is protected by MFA Delete if enabled.
To eliminate wrong answers, focus on the mechanism: MFA Delete protects operations that permanently remove data or change versioning state. If the operation does not permanently remove data (like creating a delete marker), MFA Delete does not apply.
Versioning is disabled by default; must be explicitly enabled per bucket.
Once enabled, versioning cannot be disabled; only suspended.
MFA Delete protects permanent version deletions and versioning state changes only.
MFA Delete requires the root user to enable; other users need MFA in requests.
Delete markers hide objects but do not permanently delete them.
Lifecycle policies can expire noncurrent versions to manage costs.
Versioning is required for S3 Replication and Object Lock.
MFA Delete does not protect against overwrites or delete marker creation.
These come up on the exam all the time. Here's how to tell them apart.
S3 Versioning
Keeps multiple versions of objects.
Allows overwrites and deletes (with delete markers).
Required for replication and MFA Delete.
Can be suspended but not disabled.
Costs storage for each version.
S3 Object Lock
Provides WORM protection (write once, read many).
Prevents object deletion or overwrite for a specified retention period.
Requires versioning to be enabled.
Can be in governance or compliance mode.
Prevents permanent deletion even by root user during retention.
Mistake
MFA Delete protects against accidental overwrites.
Correct
False. Overwrites create a new version; the old version remains. MFA Delete only protects permanent deletions and versioning state changes.
Mistake
Once versioning is enabled, it cannot be suspended.
Correct
False. You can suspend versioning, but you cannot disable it entirely. Suspension means new objects do not get version IDs, but existing versions remain.
Mistake
MFA Delete can be enabled by any IAM user with s3:PutBucketVersioning permission.
Correct
False. Only the AWS account root user can enable MFA Delete. Other users can suspend versioning if MFA Delete is not enabled.
Mistake
Versioning is automatically enabled on all S3 buckets.
Correct
False. Versioning is disabled by default. You must explicitly enable it.
Mistake
Deleting an object from a versioned bucket permanently removes it.
Correct
False. Without specifying a version ID, deletion creates a delete marker that hides the object. The object remains and can be restored by deleting the marker.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A delete marker is a placeholder object that hides all previous versions of an object. It is created when you delete an object without specifying a version ID. The object is not permanently removed; you can restore it by deleting the delete marker. A permanent deletion occurs when you delete a specific version ID. That version is gone forever. MFA Delete protects permanent deletions but not the creation of delete markers.
Yes, but only if versioning is already enabled on the bucket. MFA Delete requires versioning. You can enable MFA Delete using the AWS CLI or SDK, but only the AWS account root user can set `MFADelete=Enabled`. Once enabled, any subsequent permanent deletion or versioning state change requires MFA.
Existing objects receive a version ID of `null`. They remain as the only version of that object. Any future uploads with the same key will create new versions with unique IDs. The null version can be overwritten or deleted like any other version.
No. Lifecycle policies operate independently and do not support MFA. If a lifecycle rule is configured to permanently delete noncurrent versions, those deletions will occur without MFA. MFA Delete only protects direct API calls that include the MFA header.
Yes. Both hardware and virtual MFA devices are supported. The MFA code must be generated by the device and included in the request. The device must be assigned to the IAM user making the request (or to the root user).
To restore an object that has been deleted (i.e., a delete marker exists), you must delete the delete marker. You can do this by specifying the version ID of the delete marker in a DELETE request. This removes the marker and makes the object visible again.
Each version is charged as a separate object for storage. If you upload many versions, costs can increase significantly. Use lifecycle policies to transition old versions to cheaper storage classes (e.g., S3 Glacier) or expire them after a certain period.
You've just covered S3 Versioning and MFA Delete — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?