Hosting Public Website Content with Azure Blob Storage

Emmanuel — Sat, 02 May 2026 22:07:55 +0000

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.

From Zero to Secure: Setting Up Azure Storage on My DevOps Journey

Emmanuel — Tue, 21 Apr 2026 12:03:35 +0000

Everyone starts somewhere. The goal was straightforward: Create a secure, cost-effective storage account in Azure using the guided Lab which you can find on Microsoft Learn. Think of it as setting up a digital locker where your data lives safely in the cloud.
Here is what I did, what I learned, and why it matters.

Step 1: Creating a Resource Group

Before building anything, I needed somewhere to put it. In Azure, that's a resource group essentially a logical container that keeps related resources organized and easy to manage. It is a small step, but a foundational one. Good organization now saves headaches later.

Resource group creation in Azure Portal- can be found for searching the portal and selecting it

Step 2: Setting Up the Storage Account

Next came the storage account itself the actual "locker." Azure storage accounts can hold blobs, files, queues, and tables. For this lab, I focused on understanding the configuration options: naming conventions, region selection, and performance tiers.
It is surprisingly satisfying clicking through a wizard and watching a cloud resource come to life.

Storage account created in Azure Portal with a unique name.

Step 3: Locking It Down — Security Settings

This was the most important part. I applied three key security configurations:
• Secure transfer only — enforces HTTPS, rejecting any plain HTTP connections
• Minimum TLS version — set to TLS 1.2 to block outdated, vulnerable protocols
• Shared key access disabled — forces authentication through Azure Active Directory instead of less secure key-based access

These are not optional extras — they are baseline hygiene for any cloud storage setup.

Step 4: Redundancy and Networking

Since this was a training lab, I made practical trade-offs:
• Redundancy: I chose Locally Redundant Storage (LRS), which is the most affordable option, suitable for non-critical data.
• Networking: I kept public network access enabled to allow the lab tasks to run without friction.

In a production environment, I will likely switch to geo-redundant storage and lock down network access to specific virtual networks or private endpoints. But knowing why you'd make that change is exactly what lab like this teaches you.
Redundancy and networking configuration

This lab was not about storing real data — it was about building a mental model. I now understand how to spin up a storage account, apply security best practices, and make informed trade-offs between cost, redundancy, and access control.

If you are just starting out with Azure, I would encourage you to follow along with the hands-on labs. There is no better way to learn than by actually doing.
What is next? I am moving on to Azure networking and virtual machines. Follow along if you are on a similar journey.

DEV Community: Emmanuel

Hosting Public Website Content with Azure Blob Storage

From Zero to Secure: Setting Up Azure Storage on My DevOps Journey