Study guide
Technical reference and lesson notes
Purpose of This Lesson
This lesson demonstrates how Amazon S3 Versioning changes object update and deletion behavior. The key operational goals are to preserve earlier object states, roll back overwritten content, understand version IDs, and distinguish a normal delete from a permanent deletion of a specific version.
Key Concepts
Enabling S3 Versioning
S3 Versioning is enabled at the bucket level through the bucket’s Properties and Bucket Versioning settings. Once enabled, uploading a new object with the same key does not replace the previous data in the version history. Instead, S3 stores the new content as another version.
Versioning is not retroactive in the same way as newly uploaded versions. Objects uploaded before versioning was enabled can appear with a null version ID. A later upload of the same key receives a version ID, creating a versioned history alongside the earlier null-version object.
Updating an Object
In the example, index.html initially displayed “I love coffee.” After versioning was enabled, uploading an updated index.html containing “I really love coffee” created a second version. S3 served the newest version by default, so refreshing the website displayed the updated text.
The Show versions view exposes the version IDs and makes the historical states visible. Without this view enabled, the bucket appears to contain only the current logical object for each key.
Rolling Back an Overwrite
To restore an earlier version of an overwritten object:
- Enable Show versions.
- Identify the desired older version.
- Permanently delete the newer version that is currently active.
- Confirm the permanent deletion operation.
Deleting the newer version exposes the prior version again. Permanently deleting a specific version is disruptive and cannot be undone through the demonstrated workflow.
Delete Markers
When versioning is enabled and an object is deleted normally, S3 adds a delete marker rather than immediately removing the underlying object version. The delete marker becomes the current version from the normal object-listing perspective, so the object appears to be gone and requests for it can return a 404 response.
The prior object data remains visible when Show versions is enabled. To restore it, permanently delete the delete marker. Once the marker is removed, the previous object version becomes current again.
S3 Versioning Operations and Behavior
Normal Delete Versus Permanent Version Delete
The action depends on whether a specific version is selected:
- Normal delete with versions hidden: Adds a delete marker. The underlying object version remains in the bucket’s version history.
- Delete of a selected version with versions shown: Permanently deletes that version. This is a disruptive, irreversible operation in the demonstrated console workflow.
- Permanent deletion of a delete marker: Removes the marker and makes the previous object version available again.
A normal delete therefore changes what is served as the current object, while a permanent delete removes a particular version from the version history.
Website Consequences
The website reads the current visible version of the object key. After a new index.html version is uploaded, the updated page is served. After a delete marker is added to coffee.jpg, the image is unavailable and a forced browser refresh shows the missing object. Removing the delete marker restores the earlier image.
Browser caching can obscure changes during testing. The demonstration used a forced refresh, such as Command-Shift-R, to verify the current S3 result.
Exam- or Assessment-Relevant Takeaways
- Versioning is configured at the bucket level.
- Uploading the same key after versioning is enabled creates a new version rather than eliminating the historical state.
- Objects uploaded before versioning was enabled may have a null version ID.
- The console’s Show versions control is required to inspect version IDs, old versions, and delete markers.
- Deleting a specific version is a permanent delete and cannot be undone through the demonstrated operation.
- A normal delete on a versioned bucket creates a delete marker.
- A delete marker hides the prior object version from normal access but does not remove that prior version.
- Permanently deleting the delete marker restores the previous object version.
- When diagnosing an apparently missing object, inspect the bucket with versions shown before assuming the data was permanently removed.
Tool / Feature Decision Guide
| Situation | Appropriate action | Result |
|---|---|---|
| You need historical copies of overwritten objects | Enable bucket versioning before making the update | Future uploads of the same key are stored as additional versions |
| You need to inspect prior states or version IDs | Turn on Show versions | Version IDs, null versions, and delete markers become visible |
| You need to undo an overwrite | Select and permanently delete the newer version | The previous version becomes current |
| You want an object to disappear from normal access while preserving its prior version | Perform a normal delete with versioning enabled | S3 adds a delete marker |
| You accidentally deleted an object normally | Show versions and permanently delete the delete marker | The prior object version is exposed again |
| You need to remove one exact historical version | Select that version and permanently delete it | That version is irreversibly removed by the demonstrated operation |
Common Traps / Misconceptions
- Misconception: Versioning replaces the original object with the new upload. Uploading the same key creates another version after versioning is enabled.
- Misconception: A normal delete removes all copies. In the demonstrated versioned-bucket behavior, it creates a delete marker and leaves the prior object version available in version history.
- Misconception: A delete marker is the object data. It is a marker that becomes the current version and hides the underlying object from normal access.
- Misconception: Every object has a regular version ID after enabling versioning. Objects uploaded before enablement can retain a null version ID.
- Misconception: Showing only normal objects proves that data is gone. The object or its historical versions may still be present when Show versions is enabled.
- Misconception: Permanent deletion is a reversible rollback method. Permanently deleting a selected version is disruptive and cannot be undone through the demonstrated workflow.
- Misconception: A browser refresh always proves the latest storage state. Cached content may require a forced refresh when validating website changes.
Real-World Engineer / Analyst Notes
Treat version deletion as a high-risk operation. Before permanently deleting a version, confirm the bucket, object key, and exact version ID; the console’s normal object view does not provide enough context for that decision.
For an apparently missing object, first inspect the versioned view. A delete marker often explains why a key returns 404 even though an earlier data version remains stored. Restoration in this lesson is performed by removing the delete marker, not by re-uploading a replacement file.
When testing website behavior, distinguish S3 state from browser state. Use a forced refresh after changing or restoring an object so cached page or image content does not lead to an incorrect conclusion.
Quick Reference Summary
- Enable versioning from the bucket’s Properties.
- New uploads of an existing key create new versions.
- Pre-versioning objects may show a null version ID.
- Use Show versions to inspect history and delete markers.
- Permanently deleting a newer version can roll an object back to its prior version.
- A normal delete adds a delete marker rather than immediately deleting the prior data version.
- Permanently deleting the delete marker restores the prior object.
- Permanent deletion of a selected version is disruptive and cannot be undone through the demonstrated workflow.
- Force-refresh a browser when validating object changes in a website.
Flashcards
Q: A bucket contains an existing index.html, and versioning has just been enabled. What happens when the same key is uploaded with revised content?
A: S3 stores the revised upload as a new version instead of eliminating the earlier state. The new version is served as the current object.
Q: Why might an object uploaded before S3 Versioning was enabled have a null version ID?
A: It predates versioning enablement. The later versions can have version IDs while the earlier object remains associated with a null version ID.
Q: Which console control is needed to inspect old versions and delete markers?
A: Enable Show versions in the bucket’s object view. This reveals version IDs, including null versions and delete-marker entries.
Q: You need to roll an overwritten webpage back to its prior content. What operation does the demonstrated workflow use?
A: Show versions, select the newer version, and permanently delete it. The previous version then becomes current.
Q: What is the decisive difference between a normal delete and deleting a selected version in a versioned bucket?
A: A normal delete adds a delete marker, while deleting a selected version permanently removes that specific version. The latter is disruptive and cannot be undone through the demonstrated operation.
Q: A versioned coffee.jpg returns 404, but the team believes the image existed earlier. What should you inspect first?
A: Turn on Show versions and look for a delete marker. The prior image version may still exist underneath the marker.
Q: How can the prior coffee.jpg be restored after a normal delete?
A: Permanently delete the delete marker. Removing the marker exposes the previous object version again.
Q: What does a delete marker do to the normal view of a versioned object?
A: It becomes the current version and makes the object appear deleted from the normal object perspective, even though an earlier object version remains in version history.
Q: When is permanent deletion the wrong first response to an apparently missing object?
A: When the object may have been normally deleted in a versioned bucket. Inspect versions first, because a delete marker may be hiding recoverable data.
Q: Why can a browser test incorrectly suggest that an S3 update did not work?
A: Cached page or image content can remain in the browser. A forced refresh, such as Command-Shift-R in the demonstration, helps validate the current object state.
Q: What happens to an object uploaded before versioning when the same key is uploaded after enablement?
A: The older object can remain as a null-version entry, while the new upload receives a version ID and becomes the current version.
Q: You want to remove only one historical object state, not merely hide the key. Which action is appropriate?
A: Show versions, select the exact version, and permanently delete it. Verify the version ID carefully because this operation is disruptive.
Practice Questions
Question 1
An engineer uploads a revised index.html to a bucket after enabling Versioning. The website now displays the revised text, but the engineer wants to return to the earlier text. Which approach best matches the demonstrated behavior?
A. Disable Versioning and refresh the browser
B. Delete the object while versions are hidden
C. Show versions and permanently delete the newer index.html version
D. Delete the bucket and recreate it
Correct answer: C. The newer version is the current object. Permanently deleting that specific version exposes the earlier version.
Question 2
A user deletes coffee.jpg from a version-enabled bucket using the normal delete action. The object disappears from the normal listing, but the data must be recovered. What is the best next step?
A. Upload an unrelated image with the same name
B. Enable Show versions and permanently delete the delete marker
C. Permanently delete every version of coffee.jpg
D. Disable browser caching only
Correct answer: B. The normal delete created a delete marker. Removing that marker restores the prior object version.
Question 3
While auditing a bucket, an analyst sees that older objects have a null version ID, while a recently updated object has multiple version IDs. What is the most likely explanation?
A. The older objects were uploaded before Versioning was enabled
B. The newer object was uploaded to a different AWS account
C. Null IDs indicate permanent deletion
D. Version IDs are assigned only to image files
Correct answer: A. Objects uploaded before versioning enablement may retain null version IDs; later uploads receive version IDs.
Question 4
A website tester refreshes a page after restoring an S3 object, but the old missing-image result remains visible. What should the tester do before concluding that restoration failed?
A. Permanently delete the restored object again
B. Turn off Versioning
C. Perform a forced browser refresh
D. Upload the object under a different extension
Correct answer: C. The demonstration uses a forced refresh to avoid relying on cached page or image content.
WordPress Metadata
Suggested Slug:
s3-versioning-delete-markers-and-object-rollback
Meta Description:
Learn how Amazon S3 Versioning handles overwrites, null version IDs, delete markers, permanent deletion, and object rollback.
Tags:
Amazon S3, S3 Versioning, AWS Certified Data Engineer, object storage, delete markers, version IDs, data recovery, bucket operations, AWS console, troubleshooting