In the AZ-104 storage domain (15–20%), the first group in the official skills outline is "configure access to storage." Firewalls and virtual networks, SAS tokens, stored access policies, access keys, and identity-based access for Azure Files all sit there, and in our question bank, questions about firewalls and access rights make up close to half of all storage questions. The tricky part is that these features work at different layers. Open the firewall without the right permissions and you get a 403; have the permissions while the firewall blocks you and you still can't get in.
This article separates the two gates every storage request must pass: network and authorization. We cover the public network access setting and firewall rules, the four authorization methods, the three kinds of SAS and stored access policies, rotating access keys and turning off Shared Key, identity-based access for Azure Files, and encryption at rest. The basics, such as redundancy, access tiers, and lifecycle management, are in Storage Management Complete Guide.
---
Two Gates Every Storage Request Must Pass
To get into an office building you first pass the security desk at the main entrance, then you badge in at the office door. Getting past the front desk doesn't mean you can walk into any office, and having a badge doesn't help if the main entrance is closed. Azure Storage checks every request twice in the same way.
| Gate | What it checks | Where you configure it | |------|------|------| | 1. Network | Where the request comes from (internet, a specific VNet, a specific IP, a private endpoint) | Storage account → Networking | | 2. Authorization | Whether the caller may perform this operation (key, SAS, Entra ID, anonymous) | Access keys, SAS, Access control (IAM), container access level |
!A storage request must pass both the network gate and the authorization gate
Exam tip: If "the SAS token is valid, but access is denied only from one office," suspect the network gate (firewall rules), not authorization. If "a VNet rule was added, but requests fail with a 403 permission error," check the RBAC data role or the SAS permissions.
---
The Network Gate: Public Network Access and Firewall Rules
The first choice on a storage account's Networking page is the level of public network access.
| Setting | Behavior | |------|------| | Enabled from all networks | Reachable from anywhere on the internet (only the authorization gate remains) | | Enabled from selected virtual networks and IP addresses | Only requests that match the rules below are allowed; everything else is blocked | | Disabled | The public endpoint is blocked; access only through private endpoints |
When you choose selected networks, you combine allow rules.
| Rule | What it allows | What to remember | |------|------|------| | Virtual network rule | A specific subnet in a specific VNet | The subnet needs the Microsoft.Storage service endpoint (the portal creates it automatically) | | IP network rule | Public IP addresses or ranges | Private IPs (10.x, 172.16–31.x, 192.168.x) aren't allowed; enter /31 and /32 as individual IPs | | Resource instance rule | A specific Azure resource instance | Resources in the same tenant; what they can do is set by that resource's role assignments | | Trusted services exception | Azure services on the trusted list | For services that can't be isolated by VNet or IP |
IP rules hide a frequently tested trap. IP network rules have no effect on requests that come from the same Azure region as the storage account, because services in the same region communicate over private Azure IP addresses. To allow or restrict access from VMs in the same region, you must use virtual network rules. Also, once you enable a service endpoint on a subnet, traffic from that subnet uses a private IP as its source, so IP rules that allowed that subnet's public IP no longer apply.
A private endpoint gives the storage account a private IP inside your VNet, so even with public network access set to Disabled, traffic coming through the private endpoint still gets through. Service endpoints and private endpoints are compared with a diagram in VNet, NSG, DNS, and Load Balancer Explained for Beginners.
Exam tip: "Allow access only from the on-premises office's public IP 203.0.113.10" is an IP network rule. "Allow only Subnet1 of VNet1 in the same region" is a virtual network rule plus a service endpoint. "Block the internet completely and allow access only over a private IP in the VNet" is a private endpoint with public network access disabled.
---
The Authorization Gate: Four Ways to Prove Access
A request that passes the network gate proves its rights in one of four ways.
| Method | Proof | Characteristics | |------|------|------| | Microsoft Entra ID | Token for a user, group, or managed identity + an RBAC data role | Recommended by Microsoft, supports Conditional Access and auditing | | Shared Key | Account access key | One key gives full rights to all data in the account | | SAS | Signed URL token | Delegation limited by time, permissions, and target | | Anonymous read | None | Works only when allowed on the account and then enabled at the container level |
Microsoft recommends Entra ID and managed identities by default and keys only when they're truly needed. Reading and writing blobs with Entra ID requires a data role such as Storage Blob Data Reader or Storage Blob Data Contributor, as explained in Reading Azure RBAC Role Assignments for AZ-104.
---
Three Kinds of SAS and Stored Access Policies
A SAS (shared access signature) works like a hotel room key card. The front desk issues a card that opens a specific room until a specific date. What differs is what the card was signed with, which gives three kinds.
| Kind | Signed with | Target | Stored access policy | If Shared Key is turned off | |------|------|------|------|------| | User delegation SAS | A user delegation key obtained with Entra credentials | Blob (including Data Lake), Queue, Table, Azure Files | Not supported | Keeps working | | Service SAS | Account access key | One storage service | Supported | Denied | | Account SAS | Account access key | One or more services, including service-level operations | Not supported | Denied |
When you need a SAS, Microsoft recommends a user delegation SAS, because it's protected by Entra credentials rather than the account key. A user delegation key is valid for at most seven days, so a user delegation SAS can't expire more than seven days out either.
Stored Access Policies
A stored access policy is a "key card issuing rule" you define in advance on a container, queue, table, or file share. When a service SAS references the policy, it inherits the start time, expiry time, and permissions from it.
Up to five per container (or queue, table, or share) Creating or changing a policy can take up to 30 seconds to take effect Deleting the policy, renaming its identifier, or setting its expiry in the past invalidates every SAS linked to it Works only with a service SAS; user delegation and account SAS can only be ad hoc
Ways to Invalidate a SAS You Already Issued
| Method | Blast radius | |------|------| | Wait for it to expire | That SAS only (short expiry is the safest default) | | Delete or change the stored access policy | Every service SAS that references the policy | | Regenerate the account key used to sign it | Every service SAS and account SAS signed with that key + every app using that key | | Revoke user delegation keys | Every user delegation SAS for the account |
Exam tip: To be able to "immediately invalidate a set of issued SAS tokens without affecting other SAS tokens or apps," you must issue them from the start as service SAS tokens linked to a stored access policy. Regenerating the key has the widest blast radius and often appears as the wrong answer.
---
Managing Access Keys and Turning Off Shared Key
Every new storage account gets two 512-bit access keys. There are two so you can rotate them without breaking your apps.
If apps use key1, first switch the app configuration to key2 Regenerate key1 Switch the apps to the new key1, then regenerate key2
Microsoft recommends storing keys in Azure Key Vault and rotating them regularly. Because an access key gives full rights to all data in the account and the ability to issue SAS tokens, who receives roles that can read the keys (Owner, Contributor, Storage Account Contributor, and so on) also needs managing.
Going a step further, if you turn off "Allow storage account key access" (AllowSharedKeyAccess = false), every request signed with the account key is rejected and only Entra ID requests get through. Service SAS and account SAS tokens are blocked along with them, and only user delegation SAS tokens keep working. Older tools or services that rely on keys may stop working too, so check the impact first.
Exam tip: "Force every client to authenticate only with Microsoft Entra ID" means disallowing Shared Key access. If a SAS is still needed, choose a user delegation SAS.
---
Identity-Based Access for Azure Files
Employees who use Azure Files over SMB expect to connect with their own accounts, just like an office file server, and to get different permissions per folder. For this, Azure Files supports Kerberos-based identity authentication. A storage account can use only one of the following identity sources, and it applies to every file share in the account.
| Identity source | Fits environments where | |------|------| | On-premises AD DS | An existing Active Directory is in place and clients can reach the domain controllers | | Microsoft Entra Domain Services | A managed domain runs in Azure and VMs join that domain | | Microsoft Entra Kerberos | Hybrid or cloud identities connect without domain controller connectivity |
After authentication, permissions are checked in two layers.
| Layer | How you set it | Example | |------|----