Storage account 403 errors

Keep the storage account for both breaks.

1Break it: the firewall locks you out

A security baseline sets the storage firewall to deny by default:

az storage account update --resource-group rg-saat-l64 --name $st --default-action Deny -o none
az storage blob list --account-name $st --container-name lab --auth-mode login --query "[].name" -o tsv

After a minute you should see something like this:

This request is not authorized to perform this operation.
RequestId:...
ErrorCode:AuthorizationFailure

Same identity, same role, same command, different error code. AuthorizationFailure points at the network layer, not at permissions. Adding more roles would change nothing.

Check the network rules, add your current public IP, wait a minute and retry:

az storage account show --resource-group rg-saat-l64 --name $st --query "networkRuleSet.{default:defaultAction, ips:ipRules[].ipAddressOrRange, vnets:virtualNetworkRules[].virtualNetworkResourceId}" -o json
$myIp = (Invoke-RestMethod https://api.ipify.org)
az storage account network-rule add --resource-group rg-saat-l64 --account-name $st --ip-address $myIp -o none
az storage blob list --account-name $st --container-name lab --auth-mode login --query "[].name" -o tsv

hello.txt is listed again. In production, servers usually come in through service endpoints or private endpoints (Lessons 26 and 65), and people through a VPN or Bastion, rather than personal IPs.

One trap catches many teams here. When a VM reaches storage through a service endpoint, the request arrives with the VM’s private IP, not its public IP. An IP rule for the VM’s public address then never matches, and the VM keeps getting AuthorizationFailure.

For VNet traffic, add a virtual network rule for the subnet; IP rules are for traffic that really comes from the internet. Requests from Azure services in the same region also follow different paths, which is why private endpoints are the cleanest answer for servers.

2Break it: a SAS link that stopped working

A partner gets a short-lived read link. Create a user delegation SAS that expires in 2 minutes and test it:

$exp = (Get-Date).ToUniversalTime().AddMinutes(2).ToString('yyyy-MM-ddTHH:mmZ')
$uri = az storage blob generate-sas --account-name $st --container-name lab --name hello.txt --permissions r --expiry $exp --auth-mode login --as-user --full-uri -o tsv
curl.exe -s $uri

You should see hello from lesson 64. Wait 3 minutes, then run the same request:

curl.exe -s $uri

You should see something like this:

<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:...
Time:2026-10-21T06:14:09.1234567Z</Message><AuthenticationErrorDetail>Signature not valid in the specified time frame: Start [Tue, 21 Oct 2026 06:05:31 GMT] - Expiry [Tue, 21 Oct 2026 06:12:00 GMT] - Current [Tue, 21 Oct 2026 06:14:09 GMT]</AuthenticationErrorDetail></Error>

AuthenticationFailed means the signature itself is no longer valid. The AuthenticationErrorDetail element names the reason, here the expiry time. Note that the request still came from your allowed IP: a SAS doesn’t bypass the firewall.

Fix it: issue a new SAS with an expiry that matches the partner’s real need, and keep it as short as possible:

$exp = (Get-Date).ToUniversalTime().AddHours(4).ToString('yyyy-MM-ddTHH:mmZ')
$uri = az storage blob generate-sas --account-name $st --container-name lab --name hello.txt --permissions r --expiry $exp --auth-mode login --as-user --full-uri -o tsv
curl.exe -s $uri

You should see hello from lesson 64 again.

3Clean up

Delete the lab resource group:

az group delete --name rg-saat-l64 --yes

✅ Checkpoint: You fixed a missing data role, a firewall block and an expired SAS, each from its own error code.