Protect Azure Blob Storage

Protect, recover, tier, and manage Azure Blob Storage data for AZ-104.

Introduction

30 Second Summary

A quarterly finance report can be overwritten or deleted in seconds. Without recovery controls, one mistake can erase the only trusted copy.

In this project, you will build a protected Azure Blob Storage lab for a fictional finance team. The lab takes you from visible data loss to a working recovery process.

What You'll Build

You'll open a recovered quarterly report in Microsoft Azure Storage Explorer with its protected history ready for an AZ-104 demonstration.

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

A repeatable AzCopy upload that moves quarterly-report.txt from your Mac into a private container for inspection.
A visible recovery demonstration showing how blob versioning preserves overwritten content while soft delete restores deleted data.
A Cool-tier test blob with an enabled lifecycle management rule for aging data.
Secret Mission: Delete the entire reports container before recovering its blobs within the retention window.

Are there any prerequisites?

You'll need a Mac plus a Microsoft account with permission to create resources and role assignments in an Azure subscription. Step 1 confirms that access before setting up every required tool.

Before We Start

This first checkpoint locks in the finance-report data you are protecting before any hands-on work begins. You will connect each lab task to an administrator's responsibility to recover reports after accidental overwrites or deletions.

Prepare Your Azure and Mac Tooling

Your protected finance-report lab depends on a working Azure subscription plus local tools that can transfer data safely. A missing subscription or mismatched Mac package would stop the lab before the first report reaches Azure Blob Storage.

In this step, you will confirm your cloud access through the Azure portal. You will also prepare the Mac tools used to upload reports and inspect their recovery states.

In this step, get ready to:

Confirm an enabled Azure subscription in the Azure portal.
Verify the active subscription through Azure Cloud Shell.
Prepare the local runtime, inspection tool, and transfer tool.

Confirm Azure access

An enabled subscription gives the storage lab somewhere to run. Azure Cloud Shell provides the Azure CLI inside your browser.

Press Cmd+Space to open Spotlight Search.
Type Safari into Spotlight Search.
Press Enter to open Safari.
Visit the Azure portal.
Sign in with the Microsoft account you plan to use for the lab.
Search for Subscriptions in the portal search bar.
Select Subscriptions from the search results.

Choose the tab that matches what you see on the subscriptions page.

✔️ An enabled subscription appears

Select the enabled subscription you want to use for this lab.
Find the subscription ID on its overview page.
Record the value here: your subscription ID.

ⓧ No enabled subscription appears

Account creation can involve identity or payment verification. Microsoft controls this external process.

Visit the official Azure free services page.
Complete the Azure account flow shown by Microsoft.
Return to the Azure portal after the subscription becomes available.
Search for Subscriptions in the portal search bar.
Select the enabled subscription you created.
Find the subscription ID on its overview page.
Record the value here: your subscription ID.

Cloud Shell can use an ephemeral session without creating a storage account. The temporary session keeps this setup focused on the lab resources.

Select Cloud Shell from the top navigation of the Azure portal.
Select Bash if you are asked to choose a shell.
Select No storage account required for an ephemeral session in the Getting started pane.
Select the subscription that matches your subscription ID.
Select Apply to start Cloud Shell.
Check the managed Azure CLI version by running this command:

az version

What Does This Command Check?

The command prints the Azure CLI version available in Cloud Shell. It also lists the CLI's dependent libraries.

Choose the tab that matches the result printed by Cloud Shell.

✔️ I see the required CLI version

The output shows Azure CLI 2.91.0 or later. Your managed CLI is ready for the lab.

ⓧ I see an older CLI version

Microsoft manages the Azure CLI version inside Cloud Shell. A fresh session may connect you to the current managed environment.

Close the current Cloud Shell session.
Select Cloud Shell from the portal navigation again.
Select Bash as the shell.
Run the version check again after the prompt becomes ready.

Still Seeing an Older Version?

Cloud Shell updates are controlled by Microsoft. Use help me check my Cloud Shell CLI version if a fresh session still shows an older release.

ⓧ The command is unavailable

The Cloud Shell session may still be starting. It may also be using the other shell environment.

Wait until the Cloud Shell prompt accepts input.
Use the environment selector to switch to Bash.
Run the version check again in the Bash session.

Azure CLI Still Unavailable?

The managed Bash environment should include Azure CLI. Use help me restore Azure CLI access in Cloud Shell if the command remains unavailable.

Confirm the active subscription by running this command:

az account show

What Does This Command Confirm?

The command returns details for the default subscription. Its subscription ID should match your subscription ID.

Your cloud access is now anchored to the subscription you will use throughout the lab.

Seeing the Wrong Subscription?

Confirm that you selected the lab subscription when starting Cloud Shell. Use help me align my portal and Cloud Shell subscriptions if the IDs remain different.

Install the Storage Explorer prerequisites

Microsoft Azure Storage Explorer needs a matching .NET Runtime on macOS. The required package architecture depends on your Mac processor.

Package matching is a bit fiddly because Apple silicon uses ARM64 while Intel Macs use x64.

Select the Apple menu in the corner of your screen.
Select About This Mac.
Find the value beside Chip or Processor.
Record the result here: apple silicon or intel.
Press Cmd+Space to open Spotlight Search.
Type Terminal into Spotlight Search.
Press Enter to open macOS Terminal.
Check the installed runtimes by running this command:

dotnet --list-runtimes

What Does This Command Check?

The command lists the .NET runtimes installed for the active architecture. A command-unavailable result means the runtime still needs to be installed.

Choose the tab that matches the output from Terminal.

✔️ I see the required runtime

The output includes Microsoft.NETCore.App 10.0.13. Keep this runtime installed for Storage Explorer.

ⓧ I see an older runtime

The required runtime can sit alongside an older runtime. Install the package that matches your Mac.

Visit the official .NET 10 download page.
Find .NET Runtime 10.0.13.
Download the macOS Arm64 installer if apple silicon or intel records Apple silicon.
Download the macOS x64 installer if apple silicon or intel records Intel.
Open the downloaded installer package.
Complete the installation prompts shown by macOS.

ⓧ The dotnet command is unavailable

Your Mac needs the matching runtime before Storage Explorer can launch. Install the package for your processor architecture.

Visit the official .NET 10 download page.
Find .NET Runtime 10.0.13.
Download the macOS Arm64 installer if apple silicon or intel records Apple silicon.
Download the macOS x64 installer if apple silicon or intel records Intel.
Open the downloaded installer package.
Complete the installation prompts shown by macOS.

Confirm the required runtime by running the check again:

dotnet --list-runtimes

What Should the Second Check Prove?

The output should include Microsoft.NETCore.App 10.0.13. This proves the matching .NET Runtime is ready.

Storage Explorer is also version-pinned for this lab. Choose the tab that matches the app currently available on your Mac.

✔️ The required app is installed

Keep Microsoft Azure Storage Explorer 1.46.0 installed. You will launch it after this check.

ⓧ An older app is installed

Install the required package over the older release. Choose the package that matches your processor architecture.

Visit the official Storage Explorer release page.
Find Microsoft Azure Storage Explorer 1.46.0.
Download the ARM64 macOS package if apple silicon or intel records Apple silicon.
Download the x64 macOS package if apple silicon or intel records Intel.
Open the downloaded package.
Complete the installation prompts shown by macOS.

ⓧ Storage Explorer is not installed

Install the package that matches the .NET Runtime architecture. Matching architectures prevent runtime launch errors.

Visit the official Storage Explorer release page.
Find Microsoft Azure Storage Explorer 1.46.0.
Download the ARM64 macOS package if apple silicon or intel records Apple silicon.
Download the x64 macOS package if apple silicon or intel records Intel.
Open the downloaded package.
Complete the installation prompts shown by macOS.

Press Cmd+Space to open Spotlight Search.
Type Microsoft Azure Storage Explorer into Spotlight Search.
Press Enter to launch Storage Explorer.
Confirm that Storage Explorer opens without a runtime error.

The application is now running with its required runtime. The next actions connect it to your lab subscription.

Select View from the Storage Explorer menu bar.
Select Account Management.
Select Add an account....
Select Subscription as the connection type.
Complete the Microsoft sign-in flow.
Select the subscription matching your subscription ID.
Select Apply.
Confirm that the selected subscription appears in the navigation pane.

That fiddly desktop setup is complete. Storage Explorer can now inspect the same subscription managed through Cloud Shell.

Storage Explorer Not Opening?

Confirm that the Storage Explorer package matches your Mac processor. Confirm that the runtime check includes Microsoft.NETCore.App 10.0.13.

Use help me diagnose a Storage Explorer runtime problem if the application still reports a runtime problem.

Install AzCopy

AzCopy moves files between your Mac and Azure Storage. Adding its dedicated folder to your shell PATH makes the command available from any directory.

Return to macOS Terminal.
Check the available AzCopy version by running this command:

azcopy --version

What Does This Command Check?

The command prints the installed AzCopy version when Terminal can find the executable. A command-unavailable result means the archive still needs to be placed on your shell path.

Choose the tab that matches the result from Terminal.

✔️ The required version is ready

The output shows AzCopy 10.32.8. Keep its executable in a dedicated folder named azcopy inside your Mac home folder.

Use Finder to locate the folder containing the azcopy executable.
Move the executable into a dedicated azcopy folder inside your Mac home folder if needed.

ⓧ I see an older version

Replace the older executable with the pinned release for this lab. Download the archive that matches your processor architecture.

Visit the official AzCopy release page.
Download azcopy_darwin_arm64_10.32.8.zip if apple silicon or intel records Apple silicon.
Download azcopy_darwin_amd64_10.32.8.zip if apple silicon or intel records Intel.
Open the downloaded archive to extract it.
Create a dedicated folder named azcopy inside your Mac home folder with Finder.
Move the extracted executable into the dedicated azcopy folder.

ⓧ The azcopy command is unavailable

Install the portable binary that matches your Mac. Its dedicated folder remains available for later troubleshooting logs.

Visit the official AzCopy release page.
Download azcopy_darwin_arm64_10.32.8.zip if apple silicon or intel records Apple silicon.
Download azcopy_darwin_amd64_10.32.8.zip if apple silicon or intel records Intel.
Open the downloaded archive to extract it.
Create a dedicated folder named azcopy inside your Mac home folder with Finder.
Move the extracted executable into the dedicated azcopy folder.

Your shell profile stores locations that Terminal searches for commands. The next command adds the dedicated AzCopy folder to that search path.

Add the dedicated AzCopy folder to your shell path by running these commands:

echo 'export PATH="$HOME/azcopy:$PATH"' >> ~/.zshrc
source ~/.zshrc

What Do These Commands Do?

The first command adds the dedicated folder to .zshrc.
The second command reloads the shell profile in the current Terminal session.

Before the final check, predict which AzCopy information Terminal should display when the shell path is working.

Display the AzCopy command list by running this command:

azcopy -h

What Should Terminal Display?

Terminal should print the AzCopy command list. This proves the executable is available through your shell path.

Confirm the exact AzCopy version by running this command:

azcopy --version

What Should the Version Check Show?

The output should report AzCopy 10.32.8. This confirms that Terminal found the pinned executable.

AzCopy Still Not Found?

Confirm that the azcopy executable sits directly inside the dedicated home-folder directory. Confirm that .zshrc contains the matching path entry.

Use help me fix my AzCopy path on macOS if Terminal still cannot find the command.

Before the end-to-end check, predict the three signals that prove your cloud CLI, local transfer tool, and desktop explorer are ready.

Return to the Azure Cloud Shell session in Safari.
Recheck the Azure CLI version by running this command:

az version

What Should the CLI Check Show?

Cloud Shell should print Azure CLI 2.91.0 or later. This confirms that the managed CLI is available.

Recheck the active subscription by running this command:

az account show

What Should the Account Check Show?

The account details should contain your subscription ID. This proves Cloud Shell is using the lab subscription.

Return to Microsoft Azure Storage Explorer.
Confirm that the application remains open without a runtime error.
Confirm that the lab subscription remains visible in the navigation pane.

You now have every layer working together. Cloud Shell manages Azure while Storage Explorer and AzCopy handle data from your Mac.

✔️ Awesome, I've got everything!

Your Azure access and Mac tools are ready. Keep Storage Explorer plus the dedicated AzCopy folder available for the next step.

ⓧ I'd like to double check the full setup

Compare your environment with the required end state:

AzCopy version 10.32.8 is extracted to a dedicated local folder. It is available on the macOS shell PATH. It is validated with azcopy -h.
Azure Cloud Shell is accessible while you are signed in to the Azure portal. Azure CLI is available. The active subscription is confirmed with az account show.
The enabled subscription is selected in the Azure portal. The same subscription is active in Azure Cloud Shell. The same subscription is connected in Microsoft Azure Storage Explorer.
The matching .NET Runtime 10.0.13 is installed.
Microsoft Azure Storage Explorer 1.46.0 is installed. It launches successfully. It is signed in. It is connected to the lab subscription.

Your tooling is ready. Next, you will create the deliberately unprotected storage account and upload its first finance report.

Create the Storage Account and First Blob

Your Azure tools are ready. The finance report now needs a visible home in Azure Blob Storage.

This step creates an intentionally unprotected baseline. You will finish with the first report readable from your Mac through Azure.

In this step, get ready to:

Create the lab resource group plus its deliberately unprotected storage account.
Grant your identity blob data access before creating a private container.
Upload the first finance report with AzCopy.

Create a deliberately unprotected lab account

The Azure portal organizes related resources inside a resource group. A general-purpose v2 storage account supports the blob protection features you will test later.

This baseline uses LRS to keep one local-region copy set. Its recovery controls stay disabled so the next step can expose the data-loss risk.

Switch back to the Azure portal in Safari.
Enter Resource groups in the portal search bar.
Select Resource groups from the results.
Select Create from the resource group toolbar.
Select the subscription you confirmed earlier.
Enter rg-az104-storage-lab in the Resource group field.

The form now ties the lab resource group to your active subscription.

Select East US in the Region field.
Select Review + create.
Select Create after validation passes.

You should see rg-az104-storage-lab in the resource group list with East US as its location.

Enter Storage accounts in the portal search bar.
Select Storage accounts from the results.
Select Create from the storage account toolbar.
Select the subscription you confirmed earlier.
Select rg-az104-storage-lab in the Resource group field.

The storage account now belongs to the resource group you created.

Enter a unique account name matching az104blob<initials><digits> in the Storage account name field.
Select East US in the Region field.

Why must the account name be unique?

Azure Storage account names become part of a public service address. The name must contain 3 to 24 lowercase letters or numbers.

Replace the pattern markers with your initials plus a few digits. Keep the final name because you will use it in several commands.

Select Standard for Performance.
Select Locally-redundant storage (LRS) for Redundancy.

The Basics page now shows a Standard account with local redundancy.

Select Hot for the default access tier.
Open the Advanced tab.
Enable Require secure transfer for REST API operations.
Disable Allow enabling anonymous access on individual containers.

The account now requires encrypted transport. It also blocks anonymous container access.

Select TLS 1.2 as the minimum TLS version.
Open the Data protection tab.
Turn off Blob soft delete.
Turn off Container soft delete.

The two deletion recovery windows are now disabled for the baseline.

Turn off Enable versioning.
Open the Encryption tab.
Select Microsoft-managed keys for the encryption type.
Select Review + create.

What protects the stored data?

Microsoft-managed encryption protects the account data at rest. Azure manages the encryption keys for this lab.

The disabled recovery controls affect deletion history plus overwrite history. They do not disable encryption.

Keep the lab small

Creating this account starts usage-based Azure Storage charges. This lab uses LRS plus tiny text files to keep usage low.

Confirm the review page shows Standard performance.
Confirm the review page shows LRS redundancy.
Confirm the review page shows the Hot default access tier.
Select Create after validation passes.
Select Go to resource when deployment finishes.

The account Overview page should show your recorded storage account name inside rg-az104-storage-lab.

Storage account name unavailable?

Add more lowercase digits to the end of the name. Keep the total length within 24 characters.

Use the new available name everywhere this project shows the az104blob<initials><digits> value.

Ask for help if Azure still rejects the name: help me create a valid Azure Storage account name.

Grant data access and create the container

Owning the storage account does not automatically grant access to blob data. Azure RBAC gives your signed-in Microsoft Entra ID identity the required data role.

The role applies only at this storage-account scope. A private blob container will hold the finance report.

Return to Azure Cloud Shell from earlier.
Prepare the role assignment by copying this command into Cloud Shell without running it:

az ad signed-in-user show --query id -o tsv | az role assignment create --role "Storage Blob Data Contributor" --assignee @- --scope "/subscriptions/<subscription>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>"

What does this command do?

The first command finds the object ID for your signed-in user. The pipe passes that ID into the role assignment command.

The Storage Blob Data Contributor role allows your identity to create containers plus write blob data. The scope limits that permission to one storage account.

Replace <subscription> with the subscription ID you confirmed earlier.
Replace <resource-group> with rg-az104-storage-lab.
Replace <storage-account> with az104blob<initials><digits>.
Run the completed command in Cloud Shell.

Cloud Shell should return details for a role assignment at your storage-account scope.

Role access can take time

Azure role assignments can take up to 10 minutes to affect blob data access. A short authorization delay after this command is normal.

Prepare the private container command by copying this template into Cloud Shell without running it:

az storage container create --account-name <storage-account> --name <container> --auth-mode login

What does this command do?

The command creates a blob container through your Microsoft Entra sign-in. The account setting from the previous substep prevents anonymous access.

The --auth-mode login option uses your signed-in identity instead of an account key.

Replace <storage-account> with az104blob<initials><digits>.
Replace <container> with reports.
Run the completed command in Cloud Shell.

The command output should confirm that the reports container was created.

Authorization blocking the container?

Wait up to 10 minutes for the new role assignment to propagate. Run the container command again after the wait.

Confirm the account name matches the storage account in rg-az104-storage-lab.

If access still fails, help me diagnose an Azure Blob data role assignment.

Upload and inspect the report

AzCopy moves the report from your Mac into the private container. Microsoft Azure Storage Explorer gives you a visual check of the uploaded blob.

The local file holds the approved Version 1 content. This exact line becomes the baseline for the overwrite test in the next step.

Return to macOS Terminal from earlier.
Create quarterly-report.txt on your Desktop by opening it in the Nano editor with this command:

nano ~/Desktop/quarterly-report.txt

What does this command do?

Nano opens a plain-text file inside Terminal. It creates quarterly-report.txt on your Desktop when you save.

Type Version 1: approved revenue report as the only line in the file.
Press Ctrl+O to save the file.
Press Return to confirm the filename.
Press Ctrl+X to close Nano.
Read the saved file by running this command:

cat ~/Desktop/quarterly-report.txt

What does this check do?

The command prints the saved file to Terminal. This catches spelling mistakes before the upload.

You should see Version 1: approved revenue report as the complete output.

✔️ Awesome, I've got everything!

Your local report contains the approved Version 1 text. Keep quarterly-report.txt on your Desktop for the next step.

ⓧ I'd like to double check the full code

Compare your complete quarterly-report.txt file with this reference:

Version 1: approved revenue report

This single line is the entire file. Remove any extra text before continuing.

The next command starts an Azure sign-in flow for AzCopy. Your browser may open automatically or Terminal may display sign-in instructions.

Authenticate AzCopy by running this command:

azcopy login

What does this command do?

The command signs AzCopy in through Microsoft Entra ID. AzCopy can then use the blob data role you assigned.

Complete the browser sign-in with the Azure account used for this lab.
Return to macOS Terminal after authentication completes.

Terminal should confirm that AzCopy completed the sign-in process.

Prepare the upload by copying this template into Terminal without pressing Return:

azcopy copy '<local-file-path>' 'https://<storage-account-name>.blob.core.windows.net/<container-name>/<blob-name>'

How does the upload path work?

The first quoted value identifies the report on your Mac. The second quoted value identifies its Blob Storage destination.

The destination combines the storage account hostname with the container name plus the blob name.

Replace <local-file-path> by dragging quarterly-report.txt from your Desktop onto that placeholder in Terminal.
Replace <storage-account-name> with az104blob<initials><digits>.
Replace <container-name> with reports.
Replace <blob-name> with quarterly-report.txt.
Run the completed upload command.

AzCopy should report a successful transfer for one file.

Upload not completing?

Confirm that the local path points to the Desktop copy of quarterly-report.txt.

Check that the destination uses your exact storage account name. Confirm that the container segment is reports.

If authorization fails, repeat azcopy login after the role propagation wait. You can also ask for help with the AzCopy upload.

Before you refresh Storage Explorer, do you expect the private container to remain empty or show the report you transferred? Hold that prediction.

Switch back to Microsoft Azure Storage Explorer from earlier.
Expand the lab subscription in the Explorer panel.
Expand Storage Accounts.
Expand az104blob<initials><digits>.
Expand Blob Containers.
Open the reports container.
Refresh the container view.

You should see quarterly-report.txt in the container. The visible blob proves that your identity can transfer data into the private account.

Select quarterly-report.txt in the container view.
Open the selected blob.

You should read Version 1: approved revenue report in the opened file.

You now have a working path from your Mac into a private Azure container. Next, you will see what happens when this report is overwritten without recovery controls.

Experience Unprotected Data Loss

Your first report is readable in Azure Blob Storage. That proves your local-to-cloud transfer path works.

The account currently keeps no overwrite history. It also has no deletion recovery window. This step puts that configuration under pressure.

In this step, get ready to:

Overwrite the report with incorrect content.
Check whether the original version survived.
Test whether a deleted blob can be recovered.

Overwrite the only copy

An overwrite sends new content to the same blob path. This tests whether the account preserves the content that was there before.

Return to the local quarterly-report.txt file from earlier in the editor you used to create it.
Replace its existing text with Version 2: incorrect revenue report.
Save quarterly-report.txt.

Before you upload the changed file, do you think the old report will remain available somewhere in the blob?

Switch back to macOS Terminal from earlier.
Press the Up Arrow key until the previous AzCopy upload command appears.
Press Enter to upload the changed local file to the same blob path.

You should see AzCopy report a successful transfer.

Switch back to Microsoft Azure Storage Explorer.
Refresh the reports container.
Open quarterly-report.txt.

You should now read Version 2: incorrect revenue report. The Version 1 content is no longer active.

What Happened to Version 1?

AzCopy's copy operation overwrites an existing destination by default. The active blob now holds only the newer local content.

Still Seeing Version 1?

Confirm that you saved the local quarterly-report.txt file before uploading it.
Inspect the destination in your previous upload command. Confirm that it ends with reports/quarterly-report.txt.

Help me troubleshoot why the blob still shows Version 1.

Check for missing version history

The successful overwrite proves that the live content changed. The next question is whether the original content still exists behind that blob.

Switch back to the Azure portal from earlier.
Return to the reports container in your lab storage account.
Select quarterly-report.txt.
Select Versions.

You should see no Version 1 entry. There is no earlier state available to promote or download.

Why Is the History Empty?

Blob versioning was disabled before the overwrite. Azure therefore created no version history for the original report.

Delete the unprotected blob

A deletion tests a different failure path from an overwrite. The container remains in place. The selected blob is removed.

This deletion is deliberate for the lab. Your local Version 2 file remains on your Mac.

Return to the reports container's Overview page.
Select quarterly-report.txt.
Select Delete.
Approve the confirmation dialog.

Before you check, do you think Show deleted blobs will reveal the report?

Return to the reports container's Overview page.
Turn on Show deleted blobs.

You should not see quarterly-report.txt in the container. Your earlier Versions check also showed no previous content to restore.

Why Doesn't the Report Reappear?

Blob soft delete was disabled when the deletion occurred. Azure therefore created no recoverable deleted state.

Seeing the Deleted Report?

Refresh the container's Overview page if the blob still appears as active.
Check the account's Data protection page if the report appears only when Show deleted blobs is enabled.

Help me verify why the deleted report is recoverable.

You have now seen the exact data-loss failure this lab was designed to expose. Next, you will add recovery controls before rebuilding the report.

Add Protection and Recover the Report

Your last test exposed the risk inside an unprotected Azure Blob Storage account. The approved report disappeared because the account had no recovery window or overwrite history.

You will add a seven-day recovery window through blob soft delete and container soft delete. You will preserve report history through blob versioning.

Azure Cloud Shell applies the protection settings. The Azure portal gives you a visible way to prove each recovery path.

In this step, get ready to:

Enable seven-day soft delete protection.
Delete and recover a test blob.
Restore the approved report from version history.

Enable seven-day recovery windows

Soft delete retains deleted data for a defined period. Separate settings cover individual blobs and complete containers.

Record your storage account name here: az104blob<initials><digits>.
Switch back to Azure Cloud Shell from earlier.
Apply both seven-day retention settings by running these commands:

az storage account blob-service-properties update --account-name [[STORAGE_ACCOUNT="az104blob<initials><digits>"]] --resource-group rg-az104-storage-lab --enable-delete-retention true --delete-retention-days 7
az storage account blob-service-properties update --enable-container-delete-retention true --container-delete-retention-days 7 --account-name [[STORAGE_ACCOUNT="az104blob<initials><digits>"]] --resource-group rg-az104-storage-lab

What do these commands protect?

The first command retains deleted blobs for seven days.
The second command retains deleted containers for seven days.
Both settings cover deletions that happen after the commands succeed.

Before you inspect the account, do you expect both deletion recovery settings to show a seven-day retention period?

Read the active blob-service configuration by running this command:

az storage account blob-service-properties show --account-name [[STORAGE_ACCOUNT="az104blob<initials><digits>"]] --resource-group rg-az104-storage-lab

What does this check prove?

This command reads the current protection configuration from the storage account. It confirms whether both retention settings reached Azure successfully.

You should see deletion retention enabled for blobs with a value of seven days. You should also see container deletion retention enabled with a value of seven days.

Protection settings not enabled?

Check that the storage account name matches the account inside rg-az104-storage-lab.
Confirm that each update command completed before you checked the properties.
Ask your subscription administrator for permission if Azure rejects the configuration change.

Help me troubleshoot the retention settings.

Delete and undelete a test blob

The new recovery window needs a safe test object. A small note proves that deletion recovery works without putting the report at risk.

Use a text editor on your Mac to create recovery-note.txt in the folder that contains quarterly-report.txt.
Enter Recovery note: soft delete test as the file content.
Save recovery-note.txt.
Record the file's absolute path here: /Users/yourname/path/to/recovery-note.txt.
Switch back to macOS Terminal from earlier.
Upload the note with AzCopy by running this command:

azcopy copy '[[LOCAL_RECOVERY_NOTE_PATH="/Users/yourname/path/to/recovery-note.txt"]]' 'https://[[STORAGE_ACCOUNT="az104blob<initials><digits>"]].blob.core.windows.net/reports/recovery-note.txt'

What does this upload do?

AzCopy sends the local note to the private reports container. The destination stores it as recovery-note.txt.

Return to the reports container in the Azure portal.
Refresh the container's Overview page.

You should see recovery-note.txt as an active blob. The upload gives you a disposable object for the recovery test.

Select recovery-note.txt.
Select Delete.
Confirm the deletion when the portal asks.

Before you reveal deleted blobs, do you think the note now has a recovery path?

Toggle Show deleted blobs on the container's Overview page.

You should see recovery-note.txt listed as deleted. Its presence proves that soft delete captured the deletion.

Open the deleted recovery-note.txt blob.
Select Undelete on its Overview tab.
Return to the reports container.
Refresh the container.

That recovery worked. You should see recovery-note.txt as an active blob again.

Deleted note not visible?

Confirm that Show deleted blobs is turned on for the reports container.
Check that you deleted recovery-note.txt after enabling blob soft delete.
Refresh the container after selecting Undelete.

Help me recover the deleted note.

Build recoverable report history

Versioning records earlier blob states when new content replaces them. Promoting an earlier state restores its content while keeping the later states in history.

Switch back to Azure Cloud Shell from earlier.
Enable versioning for the storage account by running this command:

az storage account blob-service-properties update --resource-group rg-az104-storage-lab --account-name [[STORAGE_ACCOUNT="az104blob<initials><digits>"]] --enable-versioning true

What changes when versioning is enabled?

Later overwrites create version history for the report. An earlier state can become current again without removing the states that followed it.

Return to the storage account's Data protection page in the Azure portal.
Refresh the page.

You should see versioning enabled. Blob soft delete and container soft delete should each show a seven-day retention period.

The report now needs an approved starting state. The next overwrite creates the incorrect state without destroying that starting point.

Return to the text editor you used for the recovery note.
Open the local quarterly-report.txt file.
Replace the file's contents with Version 1: approved revenue report.
Save quarterly-report.txt.
Record the file's absolute path here: /Users/yourname/path/to/quarterly-report.txt.
Switch back to macOS Terminal.
Recreate the approved report by running this command:

azcopy copy '[[LOCAL_REPORT_PATH="/Users/yourname/path/to/quarterly-report.txt"]]' 'https://[[STORAGE_ACCOUNT="az104blob<initials><digits>"]].blob.core.windows.net/reports/quarterly-report.txt'

How does this upload help?

This upload recreates quarterly-report.txt after its permanent deletion. The approved content becomes the first protected state in the new report history.

Switch back to Microsoft Azure Storage Explorer from earlier.
Refresh the reports container.
Open quarterly-report.txt.

You should see Version 1: approved revenue report. The approved report is active again.

Return to quarterly-report.txt in your text editor.
Replace the file's contents with Version 2: incorrect revenue report.
Save quarterly-report.txt.
Switch back to macOS Terminal.
Overwrite the remote report by running this command:

azcopy copy '[[LOCAL_REPORT_PATH="/Users/yourname/path/to/quarterly-report.txt"]]' 'https://[[STORAGE_ACCOUNT="az104blob<initials><digits>"]].blob.core.windows.net/reports/quarterly-report.txt'

Why is this overwrite recoverable?

AzCopy overwrites the current destination by default. Versioning retains the approved state as an earlier version instead of discarding it.

Your local file now contains Version 2: incorrect revenue report. The recovery action changes the current Azure blob without changing that local file.

Before you inspect the history, do you expect the approved content to remain available as an earlier version?

Return to the reports container in the Azure portal.
Select quarterly-report.txt.
Open the Versions tab.

You should see the approved Version 1 state in the version history. The incorrect Version 2 state remains current until you promote the earlier entry.

Select the Version 1 entry.
Select Make current version.

Before the final check, which report text do you expect to open as the current content?

Switch back to Microsoft Azure Storage Explorer.
Refresh the reports container.
Open quarterly-report.txt.

You should see Version 1: approved revenue report as the current content. Promoting the earlier version restored the approved report.

Return to the report's Versions tab in the Azure portal.
Refresh the version list.
Confirm that the Version 2 state remains in the prior history.
Return to the storage account's Data protection page.

You should see blob soft delete enabled for seven days. You should also see container soft delete enabled for seven days.

The same page should show versioning enabled. These three settings confirm that deletion recovery and overwrite recovery are active.

Version 1 not current?

Confirm that versioning was enabled before both report uploads.
Open the Versions tab for quarterly-report.txt.
Select the approved entry before choosing Make current version.

Help me promote the approved report version.

Your storage account now protects deleted data and overwrite history. Next, you'll control access tiers for aging blobs through a lifecycle rule.

Control Storage Tiers and Lifecycle

Your finance report can now survive deletion and overwrites in Azure Blob Storage. The next challenge is controlling how storage behaves as data ages.

Recovery controls protect data. Administrators use access tiers and lifecycle management to match storage behavior to how frequently that data is used.

In this step, get ready to:

Upload a tiny blob for the tiering demonstration.
Move the demonstration blob to the Cool access tier.
Create an enabled lifecycle rule for aging archive data.

Create a tiny tiering target

A small text file gives you a low-volume target for testing tier changes. You will place it under the virtual path reports/archive/ so the lifecycle rule can target that path later.

Switch back to macOS Terminal from earlier.
Create tier-demo.txt on your Desktop by running this command:

printf "AZ-104 tier demo\n" > ~/Desktop/tier-demo.txt

What Does This Command Do?

The printf command produces one short line of text. The > operator writes that text to tier-demo.txt on your Desktop.

Confirm the local file exists by running this command:

ls ~/Desktop/tier-demo.txt

What Does This Check Do?

The ls command checks the exact file path. A matching path confirms that the upload source exists.

You should see tier-demo.txt listed under your Desktop path.

Can't Find the Local File?

Confirm that the command uses ~/Desktop/tier-demo.txt exactly. Run the creation command again if the file path is missing.

Help me troubleshoot this missing tier demo file.

The local file is ready. AzCopy can now upload it directly to the private reports container.

Enter the full path to your local file here: /Users/your-name/Desktop/tier-demo.txt.
Enter your storage account name here: az104blob<initials><digits>.
Upload the file to reports/archive/tier-demo.txt by running this command:

azcopy copy '[[LOCAL_FILE_PATH="/Users/your-name/Desktop/tier-demo.txt"]]' 'https://[[STORAGE_ACCOUNT_NAME="az104blob<initials><digits>"]].blob.core.windows.net/reports/archive/tier-demo.txt'

What Does This Upload Do?

The azcopy command uses the copy subcommand to transfer the local file. The destination URL stores it as reports/archive/tier-demo.txt.

Your existing Microsoft Entra sign-in authorizes the transfer. The storage account key stays out of the workflow.

Switch back to Microsoft Azure Storage Explorer from earlier.
Refresh the reports container.
Open the archive virtual folder.

You should see tier-demo.txt in the archive path. That upload gives your lifecycle rule a real blob to target.

Upload Missing From the Archive Path?

Refresh the reports container after the transfer completes. Confirm that the destination URL ends with reports/archive/tier-demo.txt.

Repeat the existing AzCopy sign-in from earlier if authorization has expired.

Help me troubleshoot this AzCopy upload.

Inspect the Cool tier

The account still uses Hot as its default access tier. A manual tier change lets you confirm how Azure reports a different tier on one blob.

Cool Tier Billing

The demonstration file is deliberately tiny to limit stored volume. A Cool-tier blob deleted, overwritten, or moved before 30 days is subject to a prorated early deletion charge.

Return to the reports container in the Azure portal from earlier.
Open the archive virtual folder.
Select tier-demo.txt.
Select Change tier.
Choose Cool as the target tier.
Select Save.

Before you refresh the blob properties, which access tier do you expect Azure to report?

Refresh the properties for tier-demo.txt.

You should see the access tier reported as Cool.You now have visible proof that one blob can use a different tier from the account default.

Still Seeing the Hot Tier?

Refresh the selected blob after saving the tier change. Confirm that you changed archive/tier-demo.txt inside the reports container.

Help me troubleshoot this blob tier change.

Add an automatic lifecycle rule

A lifecycle rule applies storage actions when matching data reaches a specified age. A prefix filter limits this rule to blobs under the archive path.

Return to your storage account in the Azure portal.
Select Data management.
Select Lifecycle management.
Select List View.
Select Add a rule.

How Will This Rule Stay Focused?

Azure lifecycle prefixes begin with the container name. The prefix reports/archive/ matches blobs under the archive path inside reports.

Other blobs in the container remain outside this rule. Your recovered finance report keeps its existing tier.

Enter move-archive-to-cool as the rule name.
Turn on the rule's enabled setting.
Scope the rule to Block blobs.
Select Base blobs.
Set the base-blob action to move matching blobs to Cool after 30 days without modification.
Select Filter set.
Enter reports/archive/ as the prefix filter.
Select Add.

When Will the Rule Run?

Azure Storage runs lifecycle policies periodically. The first execution can take up to 24 hours to start.

That delay is expected. The enabled rule in List View is the success check for this lab.

Before your final check, which two settings should prove that manual tiering and automatic lifecycle management are configured?

Return to the properties for archive/tier-demo.txt from earlier.
Confirm that its access tier is Cool.
Return to Lifecycle management from earlier.
Select List View.
Confirm that move-archive-to-cool appears as an enabled rule.

You should see archive/tier-demo.txt in the Cool tier. You should also see the enabled move-archive-to-cool rule in List View.

Lifecycle Rule Missing or Misconfigured?

Confirm that you selected Add after entering the rule settings. Check that the rule name is exactly move-archive-to-cool.

Verify that the prefix includes the container name as reports/archive/. Confirm that the base-blob action uses a 30-day threshold.

Help me troubleshoot this Azure lifecycle rule.

Your storage lab now demonstrates both a manual Cool-tier change and an automated policy for aging archive data.You have completed the account's protection and lifecycle configuration.

Secret mission

Recover the Entire Container

An accidental container deletion can remove every report from the active list at once. You will recover the private reports container within seven days after deliberately deleting it. Microsoft Azure Storage Explorer will prove that the container's complete state survived.

Clean Up Your Resources

Azure Blob Storage uses usage-based billing. You can keep the lab for more practice. You can also remove its data or delete every Azure resource.

Cost warning

Stored volume affects Azure Blob Storage cost. Storage operations also affect cost.

Data transfer influences the bill. Your redundancy choice influences it too.

Deleting the Cool-tier blob before 30 days can create a prorated early deletion charge. Overwriting it or moving it can create the same charge.

Choose Pause or Delete if you have finished the lab.

Resources you used:

Azure resource group rg-az104-storage-lab in East US.
Standard general-purpose v2 storage account az104blob<initials><digits> with LRS.
Private blob container reports.
Recovered blob recovery-note.txt.
Current blob quarterly-report.txt with its report version history.
Cool-tier blob archive/tier-demo.txt.
Enabled lifecycle management rule move-archive-to-cool.
Storage-scoped Azure RBAC role assignment for your signed-in Microsoft Entra identity.

Keep everything running

No action needed. Choose this if you plan to reuse the storage lab for more AZ-104 practice.

Keep rg-az104-storage-lab active with its storage account.
Keep the recovered reports container available for more recovery tests.
Monitor your Azure usage because storage activity remains billable.
Keep the local tools installed for future labs.

Pause - I'll come back to this later

Remove the lab data while preserving the storage account for reuse. Your account configuration stays in place.

Switch back to the Azure portal from earlier.
Select the storage account az104blob<initials><digits>.
Select Lifecycle management under Data management.
Select List View.
Select move-archive-to-cool.
Select Delete.

The lifecycle rule no longer appears in List View.

Switch back to Microsoft Azure Storage Explorer from earlier.
Select the active reports container.
Delete every blob plus every listed version inside reports.
Confirm each deletion prompt.

The active reports view no longer lists the lab blobs.

Future data remains billable. Future storage operations remain billable too.

Delete - I don't want to use this again

Remove every Azure resource from this lab when you no longer need it. Your local tools stay installed on the Mac.

Switch back to Azure Cloud Shell from earlier.
Confirm the permanent deletion when Azure CLI prompts you.
Start resource-group deletion by running this command:

az group delete --name rg-az104-storage-lab --no-wait

What does this command do?

The az group delete command removes the named resource group. Its contained storage account goes with it.

The storage data goes with the account. The lifecycle rule goes too.

The scoped role assignment is also removed. The --no-wait flag lets Azure finish the deletion asynchronously.

Return to the Azure portal from earlier.
Refresh the resource-group list after Azure finishes the deletion.

You should no longer see rg-az104-storage-lab. That's the cloud cleanup complete.

Nice Work!

You did it! You built a protected Azure Blob Storage lab that turns report loss into a tested recovery workflow.

You've learned how to:

Create a Standard general-purpose v2 storage account with LRS. Protect the account with Microsoft-managed encryption. Require secure transfer with a minimum of TLS 1.2. Store finance files in a private reports container.
Grant blob data access with Microsoft Entra authorization through Azure RBAC. Upload the report with AzCopy. Inspect the uploaded data with Microsoft Azure Storage Explorer.
Experience irreversible report loss while protection is disabled. Restore deleted data with blob soft delete. Promote earlier content with blob versioning. Protect the whole container with container soft delete. Move a tiny blob to the Cool tier. Target aging archive data with lifecycle management.
Secret Mission: Delete the private reports container. Recover it within its seven-day retention window. Confirm that its blobs and report version history survive.

Ready to quiz yourself?