Recover S3 Data with Versioning

Recover overwritten and deleted S3 files with versioning and lifecycle rules.

Introduction

30 Second Summary

A single contract can pass through several revisions before everyone agrees on the final wording. When an earlier copy disappears, a business can lose the evidence it needs to resolve a dispute.

In this project, you will build a private document vault with Amazon S3 that exposes the damage from an accidental overwrite. S3 Versioning gives you the recovery path, while S3 Lifecycle controls the storage trade-off.

What You'll Build

You'll download a rejected contract from your vault, trace its version history, then bring the approved content back as the current document.

By the end of this project, you'll have:

A private contract vault where downloading contract.txt returns Status: APPROVED. Its secure defaults keep public access blocked.
A tested recovery runbook that exposes the overwrite failure. It also restores approved content from protected version history.
An architecture decision record that defends the recovery design across security, resilience, performance, and cost. It explains why noncurrent versions expire after 7 days.
Secret Mission: Delete contract.txt, diagnose its delete marker, and recover the approved version without re-uploading it.

Are there any prerequisites?

You need an AWS account plus a Mac with TextEdit.

This is Project 1 of the SAA-C03 scenario-lab sequence.

Before We Start

A recovery design starts with a clear business risk. This step commits you to protecting the fictional contract before any cloud work begins.

Set Up a Safe AWS Workspace

Before Amazon S3 stores the fictional contract, the lab needs a known identity. Controlled test data also keeps real information out of the exercise.

Routine work in the AWS Management Console should use a non-root administrative identity. Root credentials stay reserved for root-only tasks.

In this step, get ready to:

Confirm a non-root administrative identity for routine console work.
Create two non-sensitive contract test files in TextEdit.
Open Amazon S3 to General purpose buckets.

Confirm your AWS identity

Your signed-in identity determines which credentials perform each console action. A non-root administrator gives you the required access while protecting the root account from routine use.

Sign in to the AWS Management Console using the credentials you currently have.
Inspect the signed-in identity details in the console header.
Choose the tab that matches the identity you see.

✔️ I'm using a non-root admin identity

Your console identity identifies an AWS IAM user or an Identity Center user with administrative access. This is the working identity for the lab.

Continue using the current identity for routine console tasks.
Keep your root credentials reserved for root-only tasks.
Leave root access keys uncreated.

Good. Your routine lab work now uses a non-root identity.

ⓧ I'm signed in as root

This branch uses your root session only long enough to establish safer daily access. It does not require a root access key.

Use the console search bar to open AWS IAM Identity Center.
Start the quick-start path for an administrative user.
Create a user for routine administrative work when prompted.
Choose Predefined permission set.
Select AdministratorAccess.

Why Use an Administrative Permission Set?

The permission set gives the new user the administrative access required for this lab. Your root identity remains reserved for tasks that specifically require it.

Open the invitation message for the new user.
Activate the new user from the invitation.
Sign out of the root session.
Return to AWS through the AWS access portal.
Sign in to the AWS Management Console with the new administrative identity.
Confirm the console header identifies the non-root identity.
Leave root access keys uncreated.

Your root credentials are now out of the routine workflow. The new administrative identity is ready for the lab.

Can't Reach the Console With Your Non-Root Identity?

Return to AWS IAM Identity Center if the invitation did not arrive.
Confirm that the user was created with the correct email address.
Confirm that AdministratorAccess was assigned if the access portal does not offer the AWS Management Console.

Help me confirm my AWS identity setup.

Create two safe contract files

The two files model the contract before the incident and after the accidental overwrite. Using synthetic status values keeps personal data out of the lab.

Each document uses plain text so its contents stay simple to inspect after every upload or download.

Press Cmd+Space to open Spotlight.
Type TextEdit and press Enter.
Choose File from the menu bar.
Choose New.
Choose Format from the menu bar.
Choose Make Plain Text.
Create the approved test version by entering this content in the blank document:

Status: APPROVED

What Does This File Represent?

The approved file represents the contract before the data-loss incident. It becomes the known-good content that the company needs to protect.

Choose File from the menu bar.
Choose Save.
Enter contract-v1.txt as the file name.
Select Desktop as the save location.
Click Save.
Confirm that the window title shows contract-v1.txt.
Confirm that the document shows Status: APPROVED.

Saved the Approved File as Rich Text?

Check whether the window title ends in .rtf.
Choose Format if the document is using rich text.
Choose Make Plain Text.
Save the document again as contract-v1.txt.

Help me save contract-v1.txt as plain text.

The second file represents the unwanted replacement content. Keeping its status visibly different makes the overwrite easy to diagnose.

Choose File from the TextEdit menu bar.
Choose New.
Choose Format from the menu bar.
Choose Make Plain Text.
Create the rejected test version by entering this content in the blank document:

Status: REJECTED

What Does This File Represent?

The rejected file represents the accidental replacement that causes the incident. Its matching future object key makes the overwrite realistic.

Choose File from the menu bar.
Choose Save.
Enter contract-v2.txt as the file name.
Select Desktop as the save location.
Click Save.
Confirm that the window title shows contract-v2.txt.
Confirm that the document shows Status: REJECTED.

Does the Rejected File Look Wrong?

Check that the file name is contract-v2.txt.
Check that the content uses REJECTED in uppercase.
Choose Make Plain Text from the Format menu if the file ends in .rtf.

Help me fix contract-v2.txt in TextEdit.

✔️ Awesome, I've got everything!

Keep both test files open in TextEdit for the final workspace check.

ⓧ I'd like to double check the full code

Compare contract-v1.txt with this reference:

Status: APPROVED

Approved File Check

The file contains one line. Its status is the approved baseline.

Compare contract-v2.txt with this reference:

Status: REJECTED

Rejected File Check

The file contains one line. Its status is the rejected replacement.

Open Amazon S3 and verify your workspace

The General purpose buckets page confirms that your working identity can reach the storage service. This check creates no S3 resources.

Switch back to the browser tab containing the AWS Management Console.
Open the Amazon S3 console.
Choose General purpose buckets from the navigation area.

Before you check, what should prove that your workspace is ready without creating an S3 resource?

Confirm that the Amazon S3 page heading shows General purpose buckets.
Switch to the open contract-v1.txt document in TextEdit.
Confirm that contract-v1.txt shows Status: APPROVED.
Switch to the open contract-v2.txt document in TextEdit.
Confirm that contract-v2.txt shows Status: REJECTED.

You'll see General purpose buckets in Amazon S3. In TextEdit, the two contract files show their distinct status values.

That's your safe starting point ready. The console is reachable through a non-root working identity. Your synthetic contract files are prepared for the incident lab.

Can't See General Purpose Buckets?

Confirm that your browser is still signed in with the non-root administrative identity.
Return through the AWS access portal if your Identity Center session ended.
Use the official Amazon S3 console link again if another AWS service is open.

Help me reach General purpose buckets in Amazon S3.

Keep the AWS account menu closed before taking your evidence screenshots.

Your identity and test data are ready. Next, you'll create the private document vault that holds the approved contract.

Build a Private Document Vault

Your safe AWS workspace is ready. Your two test files give this lab controlled data.

This step creates the first working Amazon S3 vault. The baseline stays unversioned while the secure storage defaults remain intact.

In this step, get ready to:

Create a private general purpose bucket in a nearby AWS Region.
Verify the bucket's ownership controls.
Prove the vault returns the approved contract.

Create the general purpose bucket

A bucket is the container that stores your objects. Its name must be unique within the AWS partition.

Creating a cloud bucket can feel risky because S3 storage and requests are billable. This guide-scale lab costs less than $1 when you use the small test files from earlier.

Choose Create bucket from General purpose buckets.
Choose a nearby AWS Region.

The creation form now shows the Region where Amazon S3 will store your bucket. This Region cannot be changed after creation.

Enter saa-recovery-lab-<unique-suffix> as the bucket name.
Leave Bucket Versioning disabled.
Keep Object Ownership set to Bucket owner enforced.
Keep Block Public Access at its default with all four settings enabled.
Keep default encryption set to Server-side encryption with Amazon S3 managed keys (SSE-S3).
Choose Create bucket.

You should see saa-recovery-lab-<unique-suffix> in the bucket list. That is the storage foundation for your recovery lab.

Can't create the bucket?

Change the unique suffix if another AWS account already uses your chosen bucket name.
Use only lowercase letters, numbers, periods, or hyphens in the bucket name.
Confirm that the bucket name begins with a letter or number.

Ask for help with the creation problem: Why can't I create my Amazon S3 general purpose bucket?

Confirm the private security defaults

Private storage depends on several controls working together. Checking them now establishes the security baseline before any document enters the bucket.

Select saa-recovery-lab-<unique-suffix> from the bucket list.
Choose the Properties tab.
Confirm that Bucket Versioning shows disabled.
Confirm that Default encryption shows Server-side encryption with Amazon S3 managed keys (SSE-S3).
Choose the Permissions tab.
Confirm that Object Ownership shows Bucket owner enforced.
Confirm that all four Block Public Access settings are enabled.
Confirm that no public bucket policy has been added.

You have confirmed that the bucket is private. New uploads also inherit the bucket's SSE-S3 encryption setting.

How Do These Defaults Protect the Vault?

Bucket owner enforced disables ACLs. This keeps object ownership under the bucket owner.

Block Public Access keeps the bucket from becoming publicly accessible through common policy or ACL paths.

SSE-S3 encrypts every new upload with keys managed by Amazon S3. AWS provides this base encryption level without an additional encryption charge.

Upload the approved contract

An object key is the stored object's unique name inside a bucket. The console first uses the local filename, so you will rename the uploaded object to contract.txt.

Return to the Objects tab.
Choose Upload.
Choose Add file.
Select the existing contract-v1.txt file.
Choose Open in the file picker.
Choose Upload.

You should see a success message after the upload finishes. The object list now contains contract-v1.txt.

Return to the Objects list.
Select the checkbox beside contract-v1.txt.
Open the Actions menu.
Choose Rename object.
Enter contract.txt in the New object name box.
Choose Save changes.

You should now see contract.txt in the object list. The original S3 key contract-v1.txt no longer appears.

What Did Amazon S3 Store?

Amazon S3 stores the file under the object key contract.txt. Bucket Versioning is disabled, so its version ID is null.

The bucket's default encryption applies SSE-S3 to the object. The public-access controls keep the object private.

Before you retrieve it, which status do you expect TextEdit to show? Hold that prediction for the check.

Select contract.txt in the object list.
Choose Download.
Open the downloaded contract.txt file in TextEdit.

You should see Status: APPROVED in TextEdit. Your private vault can now return the exact approved content you stored.

Don't See the Approved Contract?

Confirm that the S3 object list contains contract.txt.
Confirm that you uploaded contract-v1.txt instead of contract-v2.txt.
Repeat the download after selecting the checkbox beside contract.txt.

Get help tracing the object you retrieved: Why doesn't my downloaded S3 object show Status: APPROVED?

Your private baseline is working. Next, you will test what the vault loses when the same object key is replaced.

Reproduce the Data-Loss Incident

Your private Amazon S3 vault already holds the approved contract. Now you can test how that design behaves when a replacement reaches the same key.

An unversioned overwrite is the incident this step reproduces. You will inspect the object list. You will then confirm the surviving content.

In this step, get ready to:

Upload the rejected contract under the existing object key.
Inspect the key with Show versions enabled.
Document the surviving object's status.

Overwrite the approved contract

In the Amazon S3 console, an upload uses the local filename as its object key. Renaming the uploaded v2 file lets the replacement write target contract.txt.

Return to the Objects list for saa-recovery-lab-<unique-suffix>.
Choose Upload.
Choose Add file.
Select contract-v2.txt in the file chooser.
Choose Open.
Choose Upload.
Return to the bucket's Objects list.

You should see contract.txt beside contract-v2.txt. Both objects exist because their keys differ.

Before you make the names collide, which content do you think contract.txt will hold?

Select the checkbox beside contract-v2.txt.
Open the Actions menu.
Choose Rename object.
Enter contract.txt in the New object name box.
Select Copy source settings under Additional copy settings.
Choose Save changes.

The list now shows only contract.txt. You have created the exact overwrite condition the scenario needs.

Still see two objects?

Repeat the rename if contract-v2.txt remains in the object list.
Check that New object name contains contract.txt.
Refresh the object list after the rename finishes.

Help me troubleshoot the rename.

Inspect the version history

Version history reveals whether the earlier approved object survived the identical-key write. This is the recovery evidence your architecture decision needs.

Before you switch on version history, how many recoverable versions do you expect the shared key to show?

Turn on Show versions above the object list.

You will see one contract.txt entry. Its Version ID is null.

You have now exposed the incident exactly as intended. The bucket has no older approved entry to select.

Why is the version ID null?

The null version ID shows that the object was stored while the bucket was unversioned. S3 Versioning was disabled during the overwrite.

The rejected upload became the only object under this key. The earlier approved content has no recoverable version.

Confirm and record the incident

The version list shows the missing history. Downloading the surviving object confirms which business content remains.

Before you download the surviving object, which status should match the only entry you just inspected?

Select the only contract.txt entry.
Choose Download.
Open the newest contract.txt download in TextEdit.

You will see Status: REJECTED. The downloaded content matches the only version shown in the bucket.

Still seeing approved content?

Open the newest downloaded object from your browser's downloads list.
Check that Show versions still displays one contract.txt entry.
Confirm that the entry's Version ID is null.

Help me check the downloaded contract.

Switch back to TextEdit.
Create a new document for the incident result.
Enter this exact incident result: Unversioned overwrite reproduced: contract-v2.txt replaced contract.txt, the only version ID is null, Status: REJECTED is current, and the earlier approved content cannot be recovered.

You reproduced the data-loss incident. Your evidence now connects the identical-key write to the missing approved content.

Your incident record now captures the missing history. Next, you'll add a guardrail that preserves future versions.

Enable the Recovery Guardrail

Your overwrite test proved that the unversioned bucket cannot recover the approved contract. The rejected content is now the only available copy.

S3 Versioning retains object versions when the same key is overwritten. This creates the recovery history that the scenario needs.

In this step, get ready to:

Enable versioning on your private document vault.
Audit the bucket's security defaults during the propagation period.
Start an architecture decision record in TextEdit.

Enable S3 Versioning

Versioning begins protecting new writes after the setting propagates. The existing contract.txt object keeps its null version ID because Amazon S3 does not rewrite objects that already exist.

Switch back to the AWS Management Console from earlier.
Select the Properties tab for saa-recovery-lab-<unique-suffix>.
Choose Edit under Bucket Versioning.
Select Enable.
Choose Save changes.
Start a 15-minute timer immediately after saving.
Avoid uploads or deletes until the timer finishes.

That recovery control is now enabled. It needs time to propagate before you test it with another write.

Why Wait Before Testing?

AWS recommends waiting 15 minutes after enabling versioning for the first time. Writes or deletes during this interval can encounter inconsistent results while the setting propagates.

The timer protects the next recovery test from a timing issue. You can use the wait to inspect the bucket's existing controls.

Did the Setting Fail to Save?

Return to Properties if the page moved back to the object list.
Choose Edit under Bucket Versioning.
Select Enable before choosing Save changes again.

Help me troubleshoot why S3 Versioning did not save on my bucket.

Audit the bucket during propagation

Version history protects recoverability. The bucket's ownership, public-access, and encryption controls protect the same document from unintended access.

Select the Permissions tab while the timer runs.
Confirm Object Ownership still shows Bucket owner enforced.
Confirm ACLs remain disabled.
Confirm all four Block Public Access settings remain enabled.
Confirm the bucket policy section has no public policy.
Return to the Properties tab.
Confirm Default encryption still shows SSE-S3.

Solid work. Your recovery control preserves the private security defaults that were already protecting the bucket.

Start the architecture decision record

An architecture decision record connects the business failure to the control you selected. It also captures the alternatives that provide weaker operational protection.

Switch back to TextEdit from earlier.
Choose File from the menu bar.
Choose New.
Choose Format from the menu bar.
Choose Make Plain Text.

What Does the Record Capture?

The record links the accidental overwrite to a design requirement. It gives you a concise explanation of why the selected control fits the scenario.

Manual copies depend on consistent user behavior. Versioning applies recovery history to repeated object keys at the storage layer.

Type these headings with one heading on each line: Requirement, Failure observed, Candidate services, Decision, Rejected alternatives, Security, Resilience, Performance, Cost, Cleanup.
Explain under Decision that S3 Versioning retains object versions for recovery from accidental overwrites.
Explain under Rejected alternatives that versioning is more direct and reliable than asking users to rename files or maintain manual copies.
Choose File from the menu bar.
Choose Save.
Enter architecture-decision-record.txt as the file name.
Choose a local folder where you can find the record later.
Select Save.

Let the timer reach zero before continuing.

Before you check, do you expect enabling versioning to replace the existing null version or leave it intact?

Return to the Amazon S3 bucket in the console.
Select the Properties tab.
Confirm Bucket Versioning shows Enabled.
Return to the bucket's object list.
Use Show versions to confirm that contract.txt still has version ID null.

You'll see Enabled under Bucket Versioning. Your timer has also reached zero without an upload or delete.

The existing contract.txt entry still shows version ID null. Its rejected content remains the pre-versioning baseline.

What Did You Prove?

Versioning protects future object changes after it is enabled. It does not recreate the approved content that the unversioned overwrite already removed.

Your next protected upload creates the first recoverable version history. That is where the guardrail becomes visible.

Your bucket is ready for a protected overwrite test. Next, you will create recoverable versions and prove that the approved contract can return.

Recover Versions and Control Costs

Your Amazon S3 bucket now uses S3 Versioning for future uploads. The rejected null version still records the original overwrite incident.

This step creates recoverable history for contract.txt. You will prove recovery by removing only the rejected current version.

Every retained version is a complete object that consumes storage. S3 Lifecycle gives that recovery window a clear cost boundary.

In this step, get ready to:

Create two protected versions of the same object key.
Restore the approved contract by deleting the rejected version.
Control noncurrent-version storage costs with S3 Lifecycle.

Create protected object versions

Each upload to an existing key receives a new version ID. Earlier versions remain in the object's history.

Return to the object listing in your saa-recovery-lab-<unique-suffix> bucket.
Repeat the upload workflow from earlier to upload contract-v1.txt under object key contract.txt.
Turn on Show versions.

You should see a new contract.txt entry with a non-null version ID. The rejected pre-versioning object remains below it with version ID null.

Repeat the upload workflow to upload contract-v2.txt under object key contract.txt.
Reload the object listing.

You should now see three contract.txt entries. The two post-versioning uploads have distinct non-null version IDs.

The latest rejected upload is current. The original rejected object remains in history with version ID null.

Don't see three versions?

Confirm Bucket Versioning still shows Enabled on the Properties tab.
Check that both new uploads used the object key contract.txt.
Reload the object listing after turning on Show versions.

Help me diagnose missing S3 object versions. You can also share a redacted screenshot in the NextWork community if your console differs.

Restore the approved contract

The latest rejected upload is the current version. Permanently deleting that exact version exposes the approved version beneath it.

This deletion permanently removes only the selected rejected version. The approved version remains available in the version history.

Before you delete it, ask yourself which remaining version S3 will make current.

Open the newest non-null contract.txt entry that came from contract-v2.txt.
Choose Versions.
Select the current rejected version's Version ID.
Choose Delete.
Enter permanently delete in the confirmation field.
Choose Delete objects.

The rejected non-null version is gone. The approved non-null version is now current.

Return to the bucket's object listing.
Turn off Show versions.
Select contract.txt.
Choose Download.
Open the downloaded contract.txt in TextEdit.

You should see Status: APPROVED. That proves the earlier approved version has become current again.

You have completed the recovery test. Your bucket can now reverse an accidental overwrite without requiring another copy of the approved file.

Still seeing the rejected status?

Turn on Show versions to confirm the newest rejected non-null version was removed.
Check that you deleted the version uploaded from contract-v2.txt.
Download the current object again after reloading the listing.

Help me identify the correct version to delete.

Finalize the recovery design

A lifecycle rule gives noncurrent versions a seven-day recovery window. Versions that expire through the rule are permanently deleted.

This boundary limits ongoing storage growth. Expired noncurrent versions cannot be recovered.

Return to the Management tab in your bucket.
Choose Create lifecycle rule.
Enter expire-noncurrent-after-7-days as the rule name.
Choose This rule applies to all objects in the bucket.
Acknowledge I acknowledge that this rule applies to all objects in the bucket.
Choose Permanently delete previous versions of objects.
Enter 7 under Days after objects become noncurrent.
Finish creating the lifecycle rule.

You should see expire-noncurrent-after-7-days listed as enabled. It applies to every object in the bucket.

Don't see the enabled rule?

Confirm the rule name is expire-noncurrent-after-7-days.
Check that the all-objects acknowledgement is selected.
Confirm 7 appears under Days after objects become noncurrent.

Help me troubleshoot my S3 lifecycle rule.

The console now proves the operational design. Your architecture decision record captures why the design balances recovery with cost.

What should the decision record capture?

Decision: use private Amazon S3 with S3 Versioning plus a noncurrent-version lifecycle rule.
Security: retain Bucket owner enforced Object Ownership.
Security: retain Block Public Access.
Security: retain SSE-S3 default encryption.
Recovery result: deleting the current rejected version by version ID restored the earlier approved version.
Cost: each retained version is a complete object that consumes storage.
Lifecycle: noncurrent versions are permanently deleted after 7 days.
Cleanup: empty or delete the versioned bucket when the lab is no longer needed.

Switch back to architecture-decision-record.txt in TextEdit from earlier.
Complete the existing sections using the decision points above.
Save architecture-decision-record.txt.

Your record should now explain the recovery result. It should also state that expired noncurrent versions cannot be recovered.

The build is complete. One last check confirms the object content before a second check confirms the lifecycle state.

Before this final check, ask yourself which status the current object should contain.

Return to the bucket's object listing.
Confirm Show versions is off.
Select contract.txt.
Choose Download.
Open the downloaded file in TextEdit.

You should see Status: APPROVED in the downloaded file.

Return to the Management tab.

You should see the enabled expire-noncurrent-after-7-days rule listed. The rule permanently deletes noncurrent versions seven days after they become noncurrent.

That closes the loop. Your vault restores approved content within a defined noncurrent-version retention policy.

Secret mission

Recover an Apparently Deleted Object

Delete contract.txt to recreate an apparent data-loss incident. Diagnose its version history. Recover the approved content without uploading the file again.

Clean Up Your Resources

Your private Amazon S3 recovery lab still uses billable storage for the current and noncurrent versions of contract.txt. Decide whether to keep the lab, empty its objects for later reuse, or remove it entirely.

Cost warning

AWS describes charges from its guide-scale S3 getting-started examples as minimal and less than $1. The current object remains billable until you remove it.

The S3 Lifecycle rule permanently deletes noncurrent versions after 7 days. The current object stays in the bucket until you remove it.

Pause or Delete prevents the current object from continuing to consume storage.

Resources you used:

One private Amazon S3 general purpose bucket named saa-recovery-lab-<unique-suffix> with S3 Versioning enabled.
Two retained versions of contract.txt: the current approved version and the historical null version containing rejected content.
The enabled expire-noncurrent-after-7-days lifecycle rule attached to the bucket.
The local contract-v1.txt, contract-v2.txt, and architecture-decision-record.txt files.

Keep everything running

No action is needed. This option fits if you want to keep practising overwrite recovery and delete-marker recovery.

Leave the saa-recovery-lab-<unique-suffix> bucket in place.
Retain the current and noncurrent versions of contract.txt for future recovery practice.
Let the expire-noncurrent-after-7-days rule permanently remove noncurrent versions after 7 days.
Keep contract-v1.txt, contract-v2.txt, and architecture-decision-record.txt on your Mac.
Budget for ongoing S3 storage and request charges.

Pause - I'll come back to this later

Pausing this lab means removing the stored object data while preserving the empty bucket and its configuration for later reuse.

Emptying a versioned bucket is permanent. The evidence download comes first.

In the AWS Management Console, return to the saa-recovery-lab-<unique-suffix> bucket.
Turn on Show versions.
Select each version of contract.txt that you want to keep.
Choose Download for each selected version.
Keep contract-v1.txt, contract-v2.txt, and architecture-decision-record.txt as your local evidence.

Your downloaded versions preserve the object contents before the cloud copies are removed.

Return to General purpose buckets.
Select saa-recovery-lab-<unique-suffix>.
Choose Empty.
Enter saa-recovery-lab-<unique-suffix> in the confirmation field.
Choose Empty to remove every object version and delete marker.
Monitor Empty bucket: Status until the operation completes.

You should see the empty operation complete. The bucket remains listed under General purpose buckets with no object versions.

The bucket remains ready for reuse with Versioning and its lifecycle rule configured. Future storage and requests are billed by usage.

Delete - I don't want to use this again

This option removes the cloud resources and local files created for the lab.

This path is irreversible. The status checks keep each permanent action visible.

Return to General purpose buckets in Amazon S3.
Select saa-recovery-lab-<unique-suffix>.
Choose Empty.
Enter saa-recovery-lab-<unique-suffix> in the confirmation field.
Choose Empty to remove every object version and delete marker.
Monitor Empty bucket: Status until the operation completes.

You should see confirmation that the bucket is empty. Its object history is now permanently removed.

Return to General purpose buckets.
Select saa-recovery-lab-<unique-suffix>.
Choose Delete.
Enter saa-recovery-lab-<unique-suffix> in the confirmation field.
Choose Delete bucket.
Search the bucket list for saa-recovery-lab-<unique-suffix>.

You should see no matching bucket. That closes the cloud side of the lab, including the object history and lifecycle rule.

Use macOS file search to locate contract-v1.txt, contract-v2.txt, and architecture-decision-record.txt.
Move each matching file to the Trash.
Empty the Trash.
Search for the three filenames again.

You should see no remaining local copies of the three project files.

Nice Work!

You did it! You completed the first scenario lab in this SAA-C03 sequence. Your private Amazon S3 recovery lab proves that approved contract content can survive overwrites and apparent deletion.

You've learned how to:

Build a private document vault with blocked public access, disabled ACLs, bucket-owner control, and default encryption.
Reproduce an unversioned overwrite that replaced approved contract content. Use S3 Versioning to restore an earlier version.
Control version-storage costs with an S3 Lifecycle rule that expires noncurrent versions after 7 days. Capture the security, resilience, performance, and cost trade-offs in an architecture decision record.
Secret Mission: Recover contract.txt after a normal delete by diagnosing its delete marker. Remove only that marker to make the approved version visible again.

Ready to quiz yourself?