Blob Storage, Azure Files and Managed Disks

Interface: Azure portal for resource creation and configuration
Client system: Existing Azure VM running Ubuntu Server 24.04 LTS
Validation date: July 19, 2026
Authentication model: Managed identity for Blob Storage; storage account key for the introductory Azure Files SMB exercise

---

1. Lab objectives

By completing this lab, the student will be able to:

1. Create a general-purpose v2 Azure storage account.
2. Create and use a private Blob Storage container.
3. Enable a system-assigned managed identity on an existing Ubuntu VM.
4. Grant the VM permission to access Blob Storage without storing credentials.
5. Upload, list and download blobs from Ubuntu.
6. Create an SMB Azure file share.
7. Mount the Azure file share on Ubuntu 24.04.
8. Configure the file share to mount after a reboot.
9. Create and attach an Azure managed data disk.
10. Partition, format and permanently mount the disk.
11. Transfer a file across the managed disk, Azure Files and Blob Storage.
12. Validate and safely clean up all lab resources.

---

2. Lab architecture

Azure Portal
    |
    +-- Existing Ubuntu 24.04 VM
    |       |
    |       +-- System-assigned managed identity
    |       +-- /datadrive          -> Azure Managed Disk
    |       +-- /mnt/azurefiles     -> Azure Files SMB share
    |       +-- Azure CLI           -> Azure Blob Storage
    |
    +-- Standard GPv2 Storage Account
            |
            +-- Private blob container: blob-lab
            +-- SMB file share: files-lab

The VM accesses Blob Storage by using Microsoft Entra ID and Azure RBAC. Microsoft recommends Microsoft Entra credentials for Blob Storage data operations, and Azure VMs can authenticate through a managed identity without storing passwords, keys or service-principal secrets.

---

3. Required permissions

The student needs permission to:

• View and connect to the existing VM.
• Modify the VM to enable its managed identity.
• Create a storage account.
• Attach a data disk to the VM.
• Assign an Azure role to the VM’s managed identity.

A role such as Contributor can create and modify resources but does not necessarily allow role assignments. Assigning Azure roles requires Microsoft.Authorization/roleAssignments/write, available through roles such as Role Based Access Control Administrator or User Access Administrator. An instructor can preconfigure the managed-identity role assignment when students do not have this permission.

The VM must also have:

• SSH connectivity.
• Outbound HTTPS access on TCP 443.
• Outbound SMB access on TCP 445 for Azure Files.
• sudo access inside Ubuntu.

---

4. Naming worksheet

Replace these sample values with values assigned by the instructor.

Resource	Lab value
Existing VM	<vm-name>
Resource group	<vm-resource-group>
Azure region	Same region as the VM
Storage account	stlab<initials><digits>
Blob container	blob-lab
Azure file share	files-lab
Managed disk	disk-lab-data-01
File share mount point	/mnt/azurefiles
Managed disk mount point	/datadrive

Storage account names must be globally unique, contain only lowercase letters and numbers, and be between 3 and 24 characters long.

---

Exercise 1: Inspect the existing Ubuntu VM

Step 1.1: Open the VM

1. Sign in to the Azure portal.
2. In the portal search bar, enter Virtual machines.
3. Select Virtual machines.
4. Select the existing Ubuntu 24.04 VM.
5. On the Overview page, record:
   • VM name
   • Resource group
   • Subscription
   • Location
   • Public IP address, when present
   • Virtual network and subnet
6. Confirm that the VM status is Running.

Step 1.2: Connect to Ubuntu

From the VM page:

1. Select Connect.
2. Select Connect via SSH or the SSH option available in the portal.
3. Copy the displayed SSH command.
4. Run it from a terminal that has access to the VM.

Example:

ssh <admin-username>@<vm-public-ip>

Validate the operating system:

cat /etc/os-release
uname -r

Expected result:

NAME="Ubuntu"
VERSION="24.04..."

---

Exercise 2: Create the storage account

This lab uses a Standard general-purpose v2 account. The Preferred storage type selection only customizes the portal guidance; it does not prevent the account from using other supported storage services. Therefore, selecting Azure Files still allows Blob Storage containers to be created in the same GPv2 account.

Step 2.1: Start storage account creation

1. In the Azure portal search bar, enter Storage accounts.
2. Select Storage accounts.
3. Select Create.

Step 2.2: Configure the Basics tab

Enter the following values:

Setting	Value
Subscription	The subscription containing the VM
Resource group	The VM resource group or an instructor-provided lab resource group
Storage account name	Your globally unique name
Region	Same region as the VM
Preferred storage type	Azure Files
Performance	Standard
File share billing	Pay-as-you-go
Redundancy	Locally-redundant storage, or LRS

Using pay-as-you-go allows the same StorageV2 account to host both blobs and an HDD-backed SMB file share. Microsoft currently recommends provisioned v2 for new production Azure Files workloads, but pay-as-you-go remains fully supported and is suitable for a small multipurpose training account.

Step 2.3: Configure the Advanced tab

Use these settings:

Setting	Lab selection
Require secure transfer for REST API operations	Enabled
Allow storage account key access	Enabled
Enable hierarchical namespace	Disabled
Enable SFTP	Disabled
Enable NFS v3	Disabled
Blob access tier	Hot
Enable Managed Identity for SMB	Disabled for the core lab
Require Encryption in Transit for SMB	Enabled

Storage account key access remains enabled because the core Azure Files exercise uses the broadly supported SMB account-key mounting method. Blob Storage will still use managed identity rather than the account key.

Step 2.4: Configure the Networking tab

For a classroom lab, configure:

Setting	Lab selection
Public network access	Enabled
Public network access scope	Enable from all networks
Routing preference	Microsoft network routing

This selection reduces lab failures caused by missing network rules. For production, restrict the storage account through selected virtual networks, private endpoints or another approved network-security model. Azure Storage firewall rules can restrict access by subnet, IP address, resource instance or trusted-service exception.

Step 2.5: Create the account

1. Select Review + create.
2. Wait for validation to succeed.
3. Select Create.
4. After deployment succeeds, select Go to resource.

Validation checkpoint

On the storage account Overview page, confirm:

• Status is available.
• Performance is Standard.
• Redundancy is LRS.
• Account kind is StorageV2.
• Primary location matches the VM region.

---

Exercise 3: Create the Blob Storage container

Step 3.1: Create a private container

1. Open the storage account.
2. Under Data storage, select Containers.
3. Select + Container.
4. Enter:

Setting	Value
Name	blob-lab
Anonymous access level	Private — no anonymous access

5. Select Create.

Containers hold blobs, and the default private access level prevents anonymous public access.

Validation checkpoint

The Containers page should now list:

blob-lab

---

Exercise 4: Enable the VM managed identity

Step 4.1: Enable the system-assigned identity

1. Open Virtual machines.
2. Select the Ubuntu VM.
3. Under Security, select Identity.
4. Select the System assigned tab.
5. Change Status to On.
6. Select Save.
7. Confirm the operation when prompted.

Azure creates a Microsoft Entra service principal tied to the VM’s lifecycle. The credentials are managed by Azure and are not exposed to the student.

Step 4.2: Grant Blob Storage access

1. Return to the storage account.
2. Select Access control (IAM).
3. Select Add.
4. Select Add role assignment.
5. Search for and select:

Storage Blob Data Contributor

6. Select Next.
7. For Assign access to, select Managed identity.
8. Select + Select members.
9. For Managed identity, select Virtual machine.
10. Select the subscription.
11. Select the existing Ubuntu VM.
12. Select Select.
13. Select Review + assign.
14. Select Review + assign again.

The Storage Blob Data Contributor role permits the VM identity to read, write and delete blob data. Role assignments can take several minutes, and Microsoft notes that propagation can take up to approximately 10 minutes.

---

Exercise 5: Install Azure CLI on Ubuntu 24.04

Microsoft’s current Azure CLI installation documentation lists Ubuntu 24.04 as a tested apt-based distribution.

Step 5.1: Check whether Azure CLI is already installed

az version

If the command succeeds, continue to Exercise 6.

Step 5.2: Install prerequisites

sudo apt-get update
sudo apt-get install -y \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg \
  lsb-release

Step 5.3: Add the Microsoft signing key

sudo mkdir -p /etc/apt/keyrings

curl -sLS https://packages.microsoft.com/keys/microsoft.asc \
  | gpg --dearmor \
  | sudo tee /etc/apt/keyrings/microsoft.gpg > /dev/null

sudo chmod go+r /etc/apt/keyrings/microsoft.gpg

Step 5.4: Add the Azure CLI repository

AZ_DIST=$(lsb_release -cs)

echo "Types: deb
URIs: https://packages.microsoft.com/repos/azure-cli/
Suites: ${AZ_DIST}
Components: main
Architectures: $(dpkg --print-architecture)
Signed-by: /etc/apt/keyrings/microsoft.gpg" \
| sudo tee /etc/apt/sources.list.d/azure-cli.sources

Step 5.5: Install Azure CLI

sudo apt-get update
sudo apt-get install -y azure-cli

Validate:

az version

---

Exercise 6: Use Blob Storage from the VM

Step 6.1: Sign in with the VM identity

az login --identity

The --identity option signs Azure CLI in by using the VM’s system-assigned managed identity rather than student credentials or a stored secret.

Step 6.2: Set lab variables

Replace the storage account value:

STORAGE_ACCOUNT="<your-storage-account-name>"
BLOB_CONTAINER="blob-lab"

Check the variables:

echo "$STORAGE_ACCOUNT"
echo "$BLOB_CONTAINER"

Step 6.3: Create a sample file

cat > "$HOME/blob-demo.txt" <<EOF
Azure Blob Storage lab
Source VM: $(hostname)
Created: $(date --iso-8601=seconds)
Authentication: System-assigned managed identity
EOF

Display it:

cat "$HOME/blob-demo.txt"

Step 6.4: Upload the blob

az storage blob upload \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$BLOB_CONTAINER" \
  --name "blob-demo.txt" \
  --file "$HOME/blob-demo.txt" \
  --auth-mode login

The --auth-mode login option tells Azure CLI to authorize the data operation with the signed-in Microsoft Entra identity.

Step 6.5: List the blobs

az storage blob list \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$BLOB_CONTAINER" \
  --auth-mode login \
  --output table

Expected result includes:

blob-demo.txt

Step 6.6: Download the blob

rm -f "$HOME/blob-demo-downloaded.txt"

az storage blob download \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$BLOB_CONTAINER" \
  --name "blob-demo.txt" \
  --file "$HOME/blob-demo-downloaded.txt" \
  --auth-mode login

Compare the original and downloaded files:

cmp "$HOME/blob-demo.txt" "$HOME/blob-demo-downloaded.txt" \
  && echo "Blob upload and download validation passed."

Step 6.7: Verify through the portal

1. Open the storage account.
2. Select Containers.
3. Select blob-lab.
4. Confirm that blob-demo.txt is present.
5. Select the blob and inspect its properties.
6. Optionally download it through the portal.

---

Exercise 7: Create an Azure file share

Step 7.1: Create the SMB share

1. Open the storage account.
2. Under Data storage, select Classic file shares.
3. Select + File share.
4. On the Basics tab, configure:

Setting	Value
Name	files-lab
Access tier	Transaction optimized

5. Open the Backup tab.
6. Clear Enable backup for this temporary lab.
7. Select Review + create.
8. Select Create.

The Azure portal enables backup by default when creating a classic file share. Disabling it avoids creating extra backup resources for this disposable exercise.

---

Exercise 8: Mount Azure Files on Ubuntu

This exercise uses SMB with a storage account key because it is simple and broadly reproducible for an introductory lab. Microsoft recommends identity-based access for production implementations. SMB 3.1.1 is the recommended protocol, and Ubuntu versions newer than 18.04 support the required encrypted SMB capabilities.

Step 8.1: Obtain the portal-generated connection script

1. Open the files-lab file share.
2. Select Connect.
3. Select Linux.
4. Select the storage-account-key authentication option.
5. Use /mnt/azurefiles as the mount location when the portal displays a mount-path field.
6. Select Show script or the equivalent option.
7. Copy the generated Linux script.

The generated script is preferable because it contains the exact storage-account endpoint and current account key for the lab.

Do not include the generated script or storage key in screenshots, reports, source control or chat messages.

Step 8.2: Install the SMB client

On the Ubuntu VM, run:

sudo apt-get update
sudo apt-get install -y cifs-utils netcat-openbsd

Microsoft’s Linux Azure Files guidance requires cifs-utils for SMB mounting.

Step 8.3: Test TCP 445 connectivity

STORAGE_ACCOUNT="<your-storage-account-name>"
FILE_HOST="${STORAGE_ACCOUNT}.file.core.windows.net"

nc -zvw3 "$FILE_HOST" 445

Expected result:

Connection to <storage-account>.file.core.windows.net 445 port succeeded

Azure Files SMB uses TCP port 445. A failed test normally indicates an outbound NSG, firewall, routing or DNS restriction.

Step 8.4: Run the portal-generated script

Paste and run the script copied from the Azure portal.

The script should:

• Create the local mount directory.
• Create a protected credentials file.
• Mount the SMB share.
• Use the storage account as the SMB username.
• Use the storage account key as the SMB password.

Step 8.5: Identify the actual mount point

findmnt -t cifs

If the portal script used the requested location, the output should include:

/mnt/azurefiles

Set a variable for later exercises:

AZURE_FILES_MOUNT="/mnt/azurefiles"

If the portal script used a different location, replace the value above with the displayed mount point.

Step 8.6: Write data to the share

echo "Written from Ubuntu VM $(hostname) at $(date --iso-8601=seconds)" \
  | sudo tee "$AZURE_FILES_MOUNT/from-ubuntu-vm.txt"

List the share:

ls -la "$AZURE_FILES_MOUNT"

Read the file:

cat "$AZURE_FILES_MOUNT/from-ubuntu-vm.txt"

Step 8.7: Verify through the portal

1. Return to the files-lab share.
2. Select Browse.
3. Confirm that from-ubuntu-vm.txt appears.
4. Select or download the file.
5. Confirm that its content matches the VM output.

Step 8.8: Validate persistent mounting

Check whether the portal-generated script added an /etc/fstab entry:

grep -n "$STORAGE_ACCOUNT.file.core.windows.net" /etc/fstab

Before testing, back up the file:

sudo cp /etc/fstab /etc/fstab.before-azure-files-lab

Test all configured mounts without rebooting:

sudo mount -a
findmnt "$AZURE_FILES_MOUNT"

Do not reboot until sudo mount -a completes without errors.

---

Exercise 9: Create and attach a managed disk

Step 9.1: Attach a new data disk

1. In the Azure portal, open the Ubuntu VM.
2. Under Settings, select Disks.
3. Under Data disks, select Create and attach a new disk.
4. Configure:

Setting	Value
Disk name	disk-lab-data-01
Storage type	Standard SSD LRS
Size	4 GiB or the smallest permitted lab size
Encryption	Platform-managed key
Host caching	Leave at the displayed default

5. Select Save.

The portal creates the managed disk and updates the VM configuration. The number of supported data disks depends on the VM size.

---

Exercise 10: Prepare the managed disk in Ubuntu

Important safety warning

Never assume the new disk is /dev/sdc.

Depending on the VM size, Azure managed disks can appear through either a SCSI or NVMe interface. The operating-system disk, temporary disk and data disk can therefore have different device names. Formatting the wrong disk causes data loss.

Step 10.1: Install required utilities

sudo apt-get update
sudo apt-get install -y parted xfsprogs

Step 10.2: List the block devices

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL

Look for a disk that:

• Matches the size selected in the portal.
• Has type disk.
• Has no filesystem.
• Has no partition.
• Has no mount point.

A typical SCSI result might be:

sda      30G disk
├─sda1   29G part ext4 /
sdb      14G disk
└─sdb1   14G part ext4 /mnt
sdc       4G disk

In this example, /dev/sdc is the new disk. /dev/sdb is already mounted and must not be formatted.

A VM using NVMe might instead display a device such as:

nvme0n2   4G disk

Step 10.3: Set the correct device variable

For a SCSI disk:

DISK="/dev/sdc"
PARTITION="${DISK}1"

For an NVMe disk:

DISK="/dev/nvme0n2"
PARTITION="${DISK}p1"

Inspect the selected device again:

lsblk "$DISK"

Continue only when it is unquestionably the new, empty data disk.

Step 10.4: Create a GPT partition

sudo parted "$DISK" \
  --script \
  mklabel gpt \
  mkpart xfspart xfs 0% 100%

Notify the kernel:

sudo partprobe "$DISK"

Verify the partition:

lsblk "$DISK"

Step 10.5: Create an XFS filesystem

sudo mkfs.xfs "$PARTITION"

Microsoft’s current managed-disk examples use GPT and XFS and provide separate partition naming examples for SCSI and NVMe devices.

Step 10.6: Mount the filesystem

sudo mkdir -p /datadrive
sudo mount "$PARTITION" /datadrive

Validate:

findmnt /datadrive
df -hT /datadrive

Step 10.7: Persist the mount in /etc/fstab

Back up the current file:

sudo cp /etc/fstab /etc/fstab.before-managed-disk-lab

Retrieve the filesystem UUID:

DISK_UUID=$(sudo blkid -s UUID -o value "$PARTITION")
echo "$DISK_UUID"

Add the entry only when it is not already present:

grep -q "UUID=$DISK_UUID" /etc/fstab \
  || echo "UUID=$DISK_UUID /datadrive xfs defaults,nofail 1 2" \
  | sudo tee -a /etc/fstab

Using the UUID is safer than using /dev/sdc1 or an NVMe path because device names can change. The nofail option helps prevent a missing data disk from blocking VM startup.

Step 10.8: Test the persistent configuration

cd "$HOME"
sudo umount /datadrive
sudo mount -a
findmnt /datadrive

Create a test file:

echo "Managed disk validation: $(date --iso-8601=seconds)" \
  | sudo tee /datadrive/managed-disk-test.txt

Validate:

sudo cat /datadrive/managed-disk-test.txt
df -hT /datadrive

---

Exercise 11: Integrate all three storage services

This exercise proves that the VM can use the managed disk, Azure Files and Blob Storage together.

Step 11.1: Create evidence on the managed disk

sudo tee /datadrive/storage-lab-evidence.txt > /dev/null <<EOF
Azure storage lab completed
VM: $(hostname)
Timestamp: $(date --iso-8601=seconds)
Source location: Azure Managed Disk mounted at /datadrive
EOF

Allow the current user to read it:

sudo chmod 644 /datadrive/storage-lab-evidence.txt

Step 11.2: Copy the file to Azure Files

sudo cp \
  /datadrive/storage-lab-evidence.txt \
  "$AZURE_FILES_MOUNT/storage-lab-evidence.txt"

Validate:

cat "$AZURE_FILES_MOUNT/storage-lab-evidence.txt"

Step 11.3: Upload the same file to Blob Storage

az storage blob upload \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$BLOB_CONTAINER" \
  --name "storage-lab-evidence.txt" \
  --file "/datadrive/storage-lab-evidence.txt" \
  --auth-mode login

Step 11.4: Validate all three copies

Managed disk:

sha256sum /datadrive/storage-lab-evidence.txt

Azure Files:

sha256sum "$AZURE_FILES_MOUNT/storage-lab-evidence.txt"

Download the blob:

az storage blob download \
  --account-name "$STORAGE_ACCOUNT" \
  --container-name "$BLOB_CONTAINER" \
  --name "storage-lab-evidence.txt" \
  --file "$HOME/storage-lab-evidence-from-blob.txt" \
  --auth-mode login

Blob download:

sha256sum "$HOME/storage-lab-evidence-from-blob.txt"

All three SHA-256 values must be identical.

---

Final validation checklist

Blob Storage

• blob-lab exists.
• Anonymous access is private.
• VM system-assigned identity is enabled.
• VM has Storage Blob Data Contributor.
• az login --identity succeeds.
• Blob upload succeeds.
• Blob list displays the uploaded file.
• Downloaded blob matches the original.

Azure Files

• files-lab exists.
• TCP 445 connectivity succeeds.
• cifs-utils is installed.
• findmnt -t cifs displays the share.
• Ubuntu can create a file on the share.
• The file appears in the portal.
• sudo mount -a succeeds.

Managed Disk

• Managed disk is attached to the VM.
• Correct empty disk device was identified.
• GPT partition exists.
• XFS filesystem exists.
• Disk is mounted at /datadrive.
• /etc/fstab uses the filesystem UUID.
• /etc/fstab includes nofail.
• sudo mount -a succeeds.
• A file can be created and read on the disk.

Integrated validation

• The evidence file exists on the managed disk.
• The evidence file exists in Azure Files.
• The evidence file exists in Blob Storage.
• SHA-256 checksums match.

---

Troubleshooting

Blob command returns AuthorizationPermissionMismatch

Check:

1. The VM’s system-assigned identity is enabled.
2. The role was assigned to the VM managed identity, not to the student.
3. The role is Storage Blob Data Contributor.
4. The role scope includes the storage account.
5. Several minutes have passed since assignment.

Retry:

az logout
az login --identity

Then rerun the blob command. Azure RBAC changes can take up to approximately 10 minutes to propagate.

Blob command returns network or 403 errors

Check:

• Storage account Networking.
• Public network access is enabled for the core lab.
• The VM has outbound HTTPS access.
• The correct storage account name is being used.

TCP 445 test fails

nc -zvw3 "${STORAGE_ACCOUNT}.file.core.windows.net" 445

Check:

• VM NSG outbound rules.
• Azure Firewall or third-party firewall rules.
• User-defined routes.
• DNS resolution.
• Storage account firewall rules.

SMB Azure Files requires TCP 445.

Azure Files mount returns Permission denied

Check:

• The storage account key has not been regenerated.
• Storage account key access remains enabled.
• The credential file contains the correct account name and current key.
• The credential file permissions are 600.
• The share name is exactly files-lab.

The cleanest lab recovery is to reopen the file share’s Connect page and generate a fresh Linux script.

Managed disk does not appear

Run:

lsblk
sudo udevadm settle
lsblk

For SCSI-based VMs:

sudo apt-get install -y lsscsi
lsscsi

For NVMe-based VMs:

sudo apt-get install -y nvme-cli
sudo nvme list

Do not format a device until its size, interface, existing partitions and mount status have been verified.

/etc/fstab validation fails

Restore the appropriate backup:

sudo cp /etc/fstab.before-managed-disk-lab /etc/fstab

Or, for the Azure Files backup:

sudo cp /etc/fstab.before-azure-files-lab /etc/fstab

Then test:

sudo mount -a

Never reboot after changing /etc/fstab until sudo mount -a completes successfully.

---

Cleanup

Important

Do not delete the resource group when it also contains the pre-existing VM or other shared classroom resources.

Step 1: Remove the Azure Files mount

cd "$HOME"
sudo umount "$AZURE_FILES_MOUNT"

Remove the Azure Files entry from /etc/fstab:

sudo nano /etc/fstab

Delete only the line containing:

.file.core.windows.net

Remove the credentials file:

sudo rm -f "/etc/smbcredentials/${STORAGE_ACCOUNT}.cred"

Optionally remove the mount directory:

sudo rmdir "$AZURE_FILES_MOUNT" 2>/dev/null || true

Step 2: Remove the managed disk mount

cd "$HOME"
sudo umount /datadrive
sudo nano /etc/fstab

Delete only the line that mounts the managed-disk UUID at /datadrive.

Validate:

sudo mount -a

Step 3: Detach the managed disk

1. Open the VM in the Azure portal.
2. Select Disks.
3. Locate disk-lab-data-01.
4. Select the detach option.
5. Select Save.
6. Search for Disks in the portal.
7. Open disk-lab-data-01.
8. Select Delete.
9. Confirm deletion.

Step 4: Delete storage resources

Either delete individual resources:

• Delete blob-lab.
• Delete files-lab.

Or delete the complete lab storage account:

1. Open the storage account.
2. Select Delete.
3. Enter the storage account name.
4. Confirm deletion.

Step 5: Review the managed identity

The VM’s system-assigned identity may remain enabled for future exercises. If the instructor requires its removal:

1. Open the VM.
2. Select Identity.
3. Set System assigned to Off.
4. Select Save.

---

Production-hardening discussion

The core lab prioritizes repeatability. A production implementation should additionally evaluate:

1. Private endpoints or selected virtual-network access instead of allowing all networks.
2. Separate storage accounts based on workload, security boundary and lifecycle.
3. Provisioned v2 Azure Files for new production file-share deployments.
4. Managed identity or another approved identity-based method for Azure Files instead of storage account keys.
5. Storage-account key rotation when keys remain enabled.
6. Azure Backup for important file shares.
7. Blob soft delete, versioning and lifecycle-management policies.
8. Zone-redundant or geo-redundant storage based on recovery requirements.
9. Azure Monitor diagnostic settings, alerts and storage metrics.
10. Least-privilege role assignments scoped to the required container or service.

Microsoft recommends managed identities over storage account keys where supported, and Azure Storage network controls can restrict storage endpoints to approved networks and resources.