Hosting Public Website Content with Azure Blob Storage

ABOUT THIS LAB
I am currently on my devops path, and honestly I do have a long way to go. And yes this lab prepard you for the AZ-104 exam, Lab 02a from Microsoft Learn was one of those sessions that looks simple first until you hit a permission wall you did not expect like I did. Here is the full walkthrough, including the gotcha that tripped me up.

The objective of this lab is to configure an Azure Storage account that can host public-facing content such as images, videos, and documents while supporting high availability, soft delete protection, and blob versioning.

TASK 01 Creating the Storage Account
The first task is to create a storage account that can tolerate a regional outage. The key decision here is redundancy level.
For a public website that needs to stay online even if an Azure region goes down, Read-access Geo-redundant Storage (RA-GRS) is the right call. It replicates data to a secondary region and makes that copy readable so content stays available during a primary region incident.

Storage account name = publicwebsite[your-unique-id]
Redundancy = RA-GRS (Read-access geo-redundant)
Region = Your nearest Azure region

Storage account Basics tab — name, region, redundancy selection

TASK 02 Configuring Public Access — And the Error I Hit
This is where things got interesting for me. The lab requires enabling anonymous access so that anyone with the file’s URL can view it no Azure credentials required.
There are two separate levels where this needs to be enabled: the storage account level, and the individual container level. Miss either one and you will get an error.

Step 1: In the storage account’s Configuration blade, set Allow blob anonymous access to Enabled.

Configuration blade — ‘Allow blob anonymous access’ toggled to Enabled

⚠ THE ERROR I HIT
After enabling the setting, I immediately navigated to the container and tried changing its Public access level to Blob.

THE FIX
I forgot to click Save at the top of the Configuration blade before navigating away. And this is one thing we really have to pay attention to.
Azure does not auto-save configuration changes. Once I went back, saved properly, and returned to the container the access level change went through without issue.

Error message when attempting to change container access level before saving

Container access level successfully changed to ‘Blob’ after saving

TASK 03 Uploading Content & Testing Public Access
With the container named public and access set to Blob, I uploaded a sample image file. Then I copied the blob’s URL from the portal and pasted it into a browser window no Azure sign-in, no SAS token. The image loaded immediately-because anonymous blob access was enabled at both the storage account and container levels, the file became publicly accessible through its direct blob URL.

• Navigate to the container → Upload a file
• Click the uploaded blob → copy the URL from the properties pane
• Open an incognito browser window → paste the URL → image loads publicly_

Uploaded a sample file to the container

browser showing the image loaded via the public blob URL

TASK 04 Enabling Soft Delete
Soft delete is Azure’s recycle bin for blobs. When enabled, deleted blobs is not immediately removed they enter a deleted state and remain recoverable for a configurable retention period. I did set the retention to 21 days, then tested it. Note, the count starts from the day you set it so you would see 20 instead of 21.

• Deleted the uploaded file from the container
• Toggled ‘Show deleted blobs’ — the file reappeared, marked as deleted
• Clicked Undelete — the file was instantly restored

Data Protection blade — Blob soft delete enabled, 21 days retention

Show deleted blobs’ toggled — deleted blob visible with strikethrough indicator.

TASK 05 Enabling Blob Versioning
Soft delete protects against deletion. Blob versioning protects against overwriting. When versioning is on, every time a blob is updated, Azure automatically retains the previous version. You can promote any past version back to current at any time.
I tested it by uploading an updated version of the same file. Under Show deleted blobs, the original version appeared as a previous version entry fully restorable.

Blob versioning = Enabled

Versioning settings — Enabled, tracking versions when blobs are overwritten

What I Learned
This lab gave me a much better understanding of how Azure Storage handles public access, redundancy, and data protection. The biggest lesson for me was realizing that Azure configurations often depend on multiple settings working together — especially when dealing with permissions and public access.

Key Takeaways
Lesson Detail
Order matters Account-level anonymous access must be saved before container-level access can be changed.
RA-GRS resilience Geo-redundant storage keeps content available even during a primary region outage.

Two-level access gates Anonymous access has both an account-level and a container-level gate. Both must be configured independently.
Soft delete + versioning Soft delete covers accidental deletions. Versioning covers accidental overwrites. Use both together.

Have you run into the same “forgot to save” trap in Azure? Or found a smarter way to structure blob storage for static sites? Drop a comment I did love to hear how others are approaching this.