DEV Community: Emmanuel

Securing Azure Storage: A Hands-on Guide to Managed Identities, Key Vaults, and Immutability

Emmanuel — Wed, 27 May 2026 14:13:43 +0000

Azure Storage security involves multiple layers of protection
working together. In this guide from Microsoft Learn , we are going to eliminate that risk by configuring a User-Assigned Managed Identity (allowing our app to authenticate without passwords) and leveraging an Azure Key Vault to manage encryption keys securely.

You will learn how to:

Eliminate credential management using Managed Identities
Centralize key management using Azure Key Vault -Protect data from modification using Immutable Blob Storage
Add an extra encryption layer using Encryption Scopes

Who this is for:
Anyone new to Azure security who wants hands-on experience securing cloud storage.

Estimated time: 20–25 minutes

Task Overview:

Create the storage account and managed identity.
Secure access to the storage account with a key vault and key.
Configure the storage account to use the customer managed key in the key vault
Configure a time-based retention policy and an encryption scope.

STEP 01:

Create the storage account and managed identity

In the global Azure search bar, search for and select Storage accounts. Create a storage account for the web app.

Select + Create.
For the Resource group field, click Create new, assign your group a custom name, and select OK..
Provide a Storage account name. Ensure the name is unique and meets the naming requirements.

Click next to move to the Encryption tab.

Check the box for Enable infrastructure encryption.
Notice the warning, This option cannot be changed after this storage account is created. Select Review + Create. Wait for the resource to deploy.

STEP 02:

Provide a managed identity for the web app to use.

Search for and select Managed identities.

Select Create.
Select your resource group.
Give your managed identity a name.
Select Review and create, and then Create.

STEP 03:

Assign the correct permissions to the managed identity. The identity only needs to read and list containers and blobs.

Search for and select your storage account.
Select the Access Control (IAM) blade.
Select Add role assignment (center of the page).

On the Job functions roles page, search for and select the Storage Blob Data Reader role.

On the Members page, select Managed identity.
Select Select members, in the Managed identity drop-down select User-assigned managed identity.
Select the managed identity you created in the previous step.
Click Select and then Review + assign the role.
Select Review + assign a second time to add the role assignment.

Your storage account can now be accessed by a managed identity with the Storage Data Blob Reader permissions.

Secure access to the storage account with a key vault and key

STEP 04:
To create the key vault and key needed for this part of the lab, your user account must have Key Vault Administrator permissions.

In the portal, search for and select Resource groups. By now you know how to search using the Azure portal search bar.
Select your resource group, and then the Access Control (IAM) blade.
Select Add role assignment (center of the page).
On the Job functions roles page, search for and select the Key Vault Administrator role.

On the Members page, select User, group, or service principal.
Select Select members.
Search for and select your user account. Your user account is shown in the top right of the portal.
Click Select and then Review + assign.

Select Review + assign a second time to add the role assignment. You are now ready to continue with the lab.

STEP 05:

Create a key vault to store the access keys.

In the portal, search for and select Key vaults.

STEP 06:

Select Create.
Select your resource group.
Provide the name for the key vault. The name must be unique.
Ensure on the Access configuration tab that Azure role-based access control (recommended) is selected.
Select Review + create.

Wait for the validation checks to complete and then select Create.
After the deployment, select Go to resource. On the Overview blade ensure both Soft-delete and Purge protection are enabled.

STEP 07:
*Create a customer-managed key in the key vault.
*
Customer-managed keys allow organizations to control their own encryption lifecycle instead of relying solely on Microsoft-managed encryption.

In your key vault, in the Objects section, select the Keys blade.
Select Generate/Import and Name the key.
Take the defaults for the rest of the parameters, and Create the key.

Configure the storage account to use the customer managed key in the key vault

Before you can complete the next steps, you must assign the Key Vault Crypto Service Encryption User role to the managed identity.

STEP 08:

Select your resource group, and then the Access Control (IAM) blade.
Select Add role assignment (center of the page).
On the Job functions roles page, search for and select the Key Vault Crypto Service Encryption User role.

STEP 09:

On the Members page, select Managed identity.
Select Select members, in the Managed identity drop-down select User-assigned managed identity.
Select your managed identity.
Click Select and then Review + assign.

Select Review + assign a second time to add the role assignment.

Configure the storage account to use the customer managed key in your key vault.

STEP 10:

Return to your the storage account.
In the Security + networking section,
select the Encryption blade.
Select Customer-managed keys.
Select a key vault and key.

STEP 11:
Select your key vault and key.
Select to confirm your choices.
Ensure the Identity type is User-assigned.
Select an identity.
Select your managed identity then select Add.
Save your changes.

If you receive an error that your identity does not have the correct permissions, wait a minute and try again.

Configure a time-based retention policy and an encryption scope.

The developers require a storage container where files can’t be modified, even by the administrator.

STEP 12:
Navigate to your storage account. In the Data storage section,

Select the Containers blade.
Create a container called hold. Take the defaults. Be sure to Create the container.

Upload a file to the container.

In the Settings section, select the Access policy blade.
In the Immutable blob storage section, select + Add policy. Immutable Blob Storage helps organizations meet compliance requirements and protects against ransomware by preventing data deletion or modification during the retention period.
For the Policy type, select time-based retention.
Set the Retention period to 5 days.
Be sure to Save your changes.

Try to delete the file in the container.
Verify you are notified failed to delete blobs due to policy.

The developers require an encryption scope that enables infrastructure encryption. Learn more about infrastructure encryption.

Navigate back to your storage account.
In the Security + networking blade, select Encryption.
In the Encryption scopes tab, select Add.
Give your encryption scope a name.
The Encryption type is Microsoft-managed key.
Set Infrastructure encryption to Enable.
Create the encryption scope.

Return to your storage account and create a new container.
Notice on the New container page, there is the Name and Public access level.
Notice in the Advanced section you can select the Encryption scope you created and apply it to all blobs in the container.

What You Accomplished

In this guide you successfully implemented four layers of
Azure Storage security:

Managed Identity — your app accesses storage without storing credentials
Key Vault + Customer-Managed Key — you control the encryption keys for your storage data
Immutable Blob Storage — files in your container cannot be modified or deleted during the retention period
Encryption Scope — an additional encryption layer applied at the container level

These security controls work together to protect your data
against unauthorized access, accidental deletion, and
compliance risks.

You have successfully configured an end-to-end cloud security framework for Azure Storage! By leveraging managed identities, safeguarding keys via Azure Key Vault, and setting up time-based immutability parameters, you have built a production-ready, zero-trust storage layer.

How did you customize your configuration? Let me know in the comments section below!

Lock Down Your Cloud Shares: A Beginner’s Guide to Azure Files Security.

Emmanuel — Mon, 25 May 2026 11:32:43 +0000

Cloud storage makes file sharing easy, but it also creates new security risks if access is not controlled carefully.

Take this scenario for instance: Your finance team stores payroll files in the cloud, but a misconfigured setting accidentally exposed them to the public internet last week. This guide shows you how to prevent exactly that.

In this hands-on tutorial, you will learn the basics of securing Azure Storage using practical, layer-by-layer security steps: from automated backups to network-level blockades.

Why storage security matters
Azure Storage is designed to be secure, but the way you configure it determines how much protection your data actually gets.

*Tasks Overview *

Create a storage account specifically for file shares.
Configure a file share and directory.
Configure snapshots and practice restoring files.
Restrict access to a specific virtual network and subnet.

In the portal, search for and select Storage accounts.
Select + Create.

For resource group select Create new. Give your resource group a name- Provide a Storage account name. Ensure the name meets the naming requirements. Storage account names must be 3–24 characters, all lowercase, no spaces or hyphens. Example: exercise42026.
Azure will show a green checkmark if the name is valid and available.

NOTE: Premium = SSD-backed, low-latency storage. Use it when your app needs fast file access. Standard (HDD) is cheaper for less time-sensitive files. ZRS = Zone-Redundant Storage: your data is copied across 3 availability zones in the same region, protecting against a single data center going down.

Set the Performance to Premium.
Set the Premium account type to File shares.
Set the Redundancy to Zone-redundant storage.
Select Review and then Create the storage account.
Wait for the resource to deploy.
Select Go to resource.

Select Go to resource.

Azure Files is like a shared network drive in the cloud — multiple users or VMs can connect and access files simultaneously using the SMB protocol, just like a traditional office file server.

In the storage account, in the Data storage section,

select the File shares blade.
Select + File share and provide a Name.
Review the other options, but take the defaults.
Select Review + create, then Create.

Next Step:

Select your file share and select + Add directory.
Name the new directory finance.
Select Browse and then select the finance directory.
Notice you can Add directory to further organize your file share.
Upload a file of your choosing.

Similar to blob storage, you need to protect against accidental deletion of files. You decide to use snapshots. A snapshot is a read-only copy of your file share captured at a specific point in time like a save point in a video game. If someone accidentally deletes or overwrites a file, you can roll back to the snapshot and restore it. Here is how to create one:

Select your file share.
In the Operations section, select the Snapshots blade.
Select + Add snapshot. The comment is optional.
Select OK.
Select your snapshot and verify your file directory and uploaded file are included.

NEXT: Practice using snapshots to restore a file.

Return to your file share.
Browse to your file directory.
Locate your uploaded file and in the Properties pane select Delete. Select Yes to confirm the deletion.

Select the Snapshots blade and then select your snapshot.
Navigate to the file you want to restore,
Select the file and the select Restore.
Provide a Restored file name.

Verify your file directory has the restored file.
After restoring, go back to Browse in your file share. You should see the restored file listed alongside the original directory as shown in the screenshot above. The restored copy has a new name we provided, so the original is not overwritten.

Configure restricting storage access to selected virtual networks.

The tasks in this section require a virtual network and a subnet to demonstrate perimeter security.
A Virtual Network (VNet) is a private network in Azure — like your office's internal network, but in the cloud. A subnet is a segment within that network.

Search for and select Virtual networks.
Select Create.
Select your resource group. and give the virtual network a name.

Take the defaults for other parameters,
select Review + create, and then Create.
Wait for the resource to deploy.
Select Go to resource.

In the Settings section, select the Subnets blade.
Select the default subnet.
In the Service endpoints section choose Microsoft.Storage in the Services drop-down.
Do not make any other changes.
Be sure to Save your changes.
The storage account should only be accessed from the virtual network you just created.

Return to your files storage account.
In the Security + networking section, select the Networking blade.
Change the Public network access to Enabled from selected virtual networks and IP addresses.
In the Virtual networks section, select Add existing virtual network.
Select your virtual network and subnet, select Add.
Be sure to Save your changes.

Select the Storage browser and navigate to your file share.
Verify the message not authorized to perform this operation. You are not connecting from the virtual network. You should see a 403 error: This request is not authorized to perform this operation. This is expected — it confirms your network restriction is working. Your storage account is now only accessible from inside the virtual network you created.

Did this guide help you? Got stuck at a step or found something that could be explained better?
Drop a comment below I do read every one and I genuinely appreciate the feedback.
If you found this useful, consider sharing it with someone just getting started with Azure. As we all learn faster together.

Azure Blob Storage for Beginners: Private Access, SAS Tokens & Cost Savings Explained

Emmanuel — Tue, 19 May 2026 10:36:32 +0000

In this beginner walkthrough based on the Microsoft Learn guided exercise we configure a private Azure Blob Storage account for internal company documents.

Imagine your company stores HR files, contracts, or financial reports. You need them available 24/7, protected from public access, and cost-efficient to store long-term. That's exactly what this guide sets up.

What we will build:
•A private storage account with GRS redundancy
•A restricted blob container for internal documents
•A time-limited SAS token for partner access
•Automated lifecycle rules to move blobs to Cool tier after 30 days
•Cross-account object replication for public website backup

Overview
The solution uses a single private storage account containing two blob containers: one for internal documents and one named 'backup' that receives replicated content from the public website storage account.

In the portal, search for and select Storage accounts.
Select + Create.

Select the Resource group created in the previous lab.

Set the Storage account name to private. Add an identifier to the name to ensure the name is unique. Tip : Storage account names must be 3–24 characters, all lowercase, no spaces or special characters. Try something like privatecompany2025. Azure will tell you if it's already taken.

Select Review, and then Create the storage account.

Wait for the storage account to deploy, and then select Go to resource.

Configure the appropriate level of redundancy.

In the storage account, in the Data management section, select the Redundancy blade.
Ensure Geo-redundant storage (GRS) is selected.
Refresh the page.

What is GRS? Geo-Redundant Storage automatically copies your data to a second Azure region. So if a data center goes down, your files are still safe and accessible.

Review the primary and secondary location information.
Save your changes.

In the storage account, in the Data storage section, select the Containers blade. Select + Container.
Ensure the name of the container is private.
Ensure the Public access level is Private (no anonymous access).

Why Private? Setting the container to Private means no one can view or download files using just a URL. They need a key or a special token. This is what keeps internal company files away from the public internet. As you have time, review the Advanced settings, but take the defaults. Select Create.

For testing, upload a file to the private container. The type of file doesn’t matter. A small image or text file is a good choice. Test to ensure the file isn’t publically accessible.

Select the container.
Select Upload.
Browse to files and select a file.
Upload the file.
Select the uploaded file.
On the Overview tab, copy the URL.
Paste the URL into a new browser tab.

Verify the file doesn’t display and you receive an error. You should see a ResourceNotFound or 403 (Forbidden) error, this is correct! It confirms your container is properly locked down.

What is a SAS Token? A Shared Access Signature is like a temporary visitor badge. Instead of giving your partner your account password, you generate a special link that expires after a set time and only allows the permissions you choose (e.g., read-only). Once it expires, the link stops working automatically.

An external partner requires read and write access to the file for at least the next 24 hours. Configure and test a shared access signature (SAS).

Select your uploaded blob file and move to the Generate SAS tab- Select Generate SAS token and URL. Copy the SAS URL immediately. Azure will not show it again once you close this panel.Treat it like a password; don't share it publicly. In the Permissions drop-down, ensure the partner has only Read permissions.Verify the Start and expiry date/time is for the next 24 hours or time requested.

Copy the Blob SAS URL to a new browser tab.
Verify you can access the file. If you have uploaded an image file it will display in the browser as you have seen in the screenshot. Other file types will be downloaded.

Configure storage access tiers and content replication.

To save on costs, after 30 days, move blobs from the hot tier to the cool tier. Hot vs Cool Storage: Azure charges you based on how often data is accessed. Hot tier is for files you access frequently, faster but pricier. Cool tier is for files you rarely touch — slower but cheaper. Lifecycle rules automate the switch so you don't have to do it manually.

Return to the storage account.
In the Overview section, notice the Default access tier is set to Hot. In the Data management section, select the Lifecycle management blade. Select Add rule.Set the Rule name to movetocool.
Set the Rule scope to Apply rule to all blobs in the storage account.
Select Next.Ensure Last modified is selected.Set More than (days ago) to 30.In the drop-down select Move to cool storage.

As you have time, review other lifecycle options in the drop-down.
Add the rule.The public website files need to be backed up to another storage account.

In your storage account, create a new container called backup. Use the default values. Refer back to Lab 02a we did if you need detailed instructions.

Navigate to your publicwebsite storage account. This storage account was created in the previous exercise. If you don't already have a public storage account, create one using the same steps in Step 1 above, and name it publicwebsite. Create a container inside it called public and upload any file to it.

In the Data management section, select the Object replication blade. Select Create replication rules.
Set the Destination storage account to the private storage account.
Set the Source container to public and the Destination container to backup. Once done you can click create.

That's it — we've successfully concluded that the necessary steps needed to create a redundant storage account.

Great work! Here is what you have built:

Feature What It Does

GRS Storage Account - Keeps data safe across regions.
Private Container - Blocks public internet access.
SAS Token Grants time -limited partner access Lifecycle
Rule - Saves cost by moving old data to Cool tier Object Replication Auto - backs up your public website files.

Next steps: When you have time you could Explore Azure RBAC(https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) to control who in your team can manage storage, or try Azure Key Vault to manage SAS keys securely.

I did truly appreciate any insights or additions that could help enhance this article!

How to Deploy an Ubuntu Linux VM in Azure

Emmanuel — Sat, 16 May 2026 21:44:39 +0000

We will use the Azure Portal (GUI) to launch an Ubuntu Linux Virtual Machine (VM).

Note: Azure charges by the minute while your VM is running. Don't forget to delete everything at the end so you pay nothing (or just pennies).

Step 1: Create Your Resource Group
Think of a Resource Group as a folder that will hold your VM and all its related parts. Creating it first keeps things organized.

Create a Resource Group:

Click + Create a resource in the top left corner.

Type "Resource Group" in the search bar and select it.

Click Create.

Name it MyLinuxLab_RG

Select a Region close to you (e.g., East/West US)

Click Review + create → Create

Quick Definition: A Region is the physical location of the data center where your cloud resources will live.

Step 2: Create the Ubuntu Linux VM
Now that your folder (Resource Group) is ready, let's build the actual Linux computer.

Basics Tab:

Resource Group: Select MyLinuxLab_RG from the dropdown

Virtual Machine Name: Ubuntu-Lab-01

Region: Choose the same region you used for your Resource Group

Availability Options: Leave as "No infrastructure redundancy required" (fine for learning)

Image: Confirm it says Ubuntu Server 22.04 LTS (or newer)

Size: Choose Standard_B2s — it's cost-effective and perfect for learning or the default.

Administrator Account:

Authentication type: Select password

Username: azadmin (or a name you'll remember)

Quick Definition: SSH (Secure Shell) is the secure "door" that lets you type commands into your Linux VM from your own terminal. The key pair is like a digital lock and key.

Inbound Port Rules: Under "Public inbound ports," ensure Allow selected ports is checked Http Port 80 and SSH (22) is selected as we move forward we will learn more together.

Click Review + create → wait for the green "Validation passed" message → Click Create

Note: Don't worry if you see yellow warnings — those are usually fine. Look for the green checkmark.

To ensure that your terminal section does not go off. Click the IP address ensure you extend the time under networking.

Step 3:
Click Connect which would enable you remotely login to the Linux VM:

For windows you would need to open/launch Powershell and For Mac you would open/launch Terminal and run the ID and Ip given.
Now you see my powershell on my windows prompting for Password.

Next: We would login in as a root user which is the same as an administrator in Windows.
"sudo su" and run "apt update" which is to ensure that the latest update is installed.

Step 4: We would install the ntp package - also know as the package manager. "ntp install nginx"

This shows we did login in successfully and we can also remotely login using other options.

Step 5:
Remember to delete.

If this help you in any way kindly share. If you did like to spice up this beginner guide in the comment section I did love that.

How to Create a Windows 10 Virtual Machine in the Azure Portal (No CLI Needed)

Emmanuel — Wed, 13 May 2026 23:00:52 +0000

In this guide, we are going to bypass the command line entirely (that is the CLI — Command Line Interface, like PowerShell or Bash). We will use the Azure Portal (GUI) to launch a Windows 10 Virtual Machine (VM) in about 7 minutes.

Cost Note: Azure charges by the minute while your VM is running. Delete everything at the end and your cost will be minimal or zero, especially if you are on a free trial.

A Virtual Machine (VM) is a computer that runs inside another computer — entirely in the cloud. You access it remotely just like a normal PC.

Phase 1: The Setup

Sign In: Log into the Azure Portal.
Create a Resource: Click the + Create a resource button in the top left.

Resource Group: Click "Create new" and name it any name for example MyVMGroup. Virtual Machine Name: Name it DevOps-Lab-01. Region: Select the one closest to you (e.g., East US).

When finish go to the resource group you just created and open it.

Next Select the Service search bar: Type "Windows 10" in the search bar and select the Windows 10 option or the "consumer editions" or "Pro."

Quick Definition: A Region is simply the physical location of the data center where your virtual computer will live.

Phase 2: Configuration & Identity

Size: Choose Standard_B2s. It's cost-effective and perfect for learning.

The "Size" selection window showing the B2s option and its estimated monthly cost. Ensure you check the Run with Azure spot discount

This lets Azure use spare capacity to run your VM at a lower cost. It is perfect for learning because we are not running anything critical.

*7. Administrator Account: *

Enter a username and
A strong password.

⚠️ Important: Save these! You will need them to "log in" to your computer later.

*Inbound Port Rules: * Under "Public inbound ports," ensure Allow selected ports is checked and RDP (3389) & Http (80) is selected.

Review + Create: Skip the other tabs for now. Click the blue Review + Create button at the bottom.

The Deployment

Confirm: Azure will run a validation check. Look for the green "Validation passed" message. Then click Create.

Phase 3: Connecting via Remote Desktop (RDP)
Once the deployment is complete, click Go to resource.

Click the Connect button at the top left and select RDP.

Click Download RDP File. This file is your "digital key."
Open the downloaded file and click Connect.
Enter the Username and Password you created in Phase 2.
The Certificate Warning: A box will pop up saying the identity cannot be verified. This is normal! Click Yes.

VM running live.

You have just deployed a real cloud computer from scratch no command line needed.

What You Just Learned:
Azure Term : What It Actually Means
Resource Group: A folder for your cloud project
Region: Which data center your VM lives in
VM : A computer that runs inside another computer entirely in the cloud.
RDP: The remote "screen share" protocol
VM Size: How much CPU/RAM your lab computer gets

Next Step: Don't Forget to Clean Up!
When you are finished testing, delete your Resource Group to avoid any unnecessary charges:

Go to Resource groups in the Azure Portal.
Find MyVMGroup.
Click Delete resource group and type the name to confirm.

The Resource Group page showing the "Delete resource group" button and the confirmation text box.

If you found this helpful, kindly share it with someone else starting their DevOps journey. If you are on the same path, I did love to hear how your experience went — drop a comment or reach out.

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.