Implement and manage storage
Storage Network and Authorization Boundaries
CoreSelect network exposure and authorization mechanisms for Storage and Azure Files without confusing identity, keys, SAS, and endpoints.
Aligned to the current AZ-104 study guide, verified August 21, 2026.
Why this matters
A storage request succeeds only when both the network path and the data authorization path allow it, so fixing one boundary cannot compensate for a failure at the other.
Must Know
- Storage firewalls can allow selected networks, IP ranges, resource instances, or trusted service exceptions according to the account configuration.
- Microsoft Entra authorization with Azure data roles avoids distributing account-wide shared secrets and is preferred when supported.
- An account key grants broad authority; a SAS delegates bounded permissions, services, resources, times, and network constraints.
- A user delegation SAS is signed with Entra-derived credentials for Blob data; service and account SAS forms are signed with an account key.
- Identity-based Azure Files access combines a supported identity source, share-level Azure permission, and file/directory authorization as applicable.
Compare and Distinguish
- Account key vs SAS vs Entra/RBAC: reusable account secret vs delegated token vs identity-based authorization without sharing the account key.
- User delegation SAS vs service SAS vs account SAS: Entra-backed Blob delegation vs one-service resource delegation vs broader account-service delegation.
- Stored access policy vs ad hoc SAS: named server-side constraints can change or revoke associated service SAS tokens; an ad hoc token carries its limits only in the token.
- Storage firewall vs service endpoint vs private endpoint: account admission rules vs subnet identity to a public service endpoint vs a private IP for one service resource.
Scenario examples
- Scenario: A vendor needs read access to one blob container for four hours. Think: Issue a narrowly scoped SAS with only the required permissions and expiry.
- Scenario: A workload must reach one storage account through a VNet private IP. Think: Create a private endpoint, configure private DNS, and restrict public access as required.
- Scenario: A user can reach an Azure file share but cannot open files. Think: Check identity source, share-level role, and file or directory permissions separately.
Exam traps
- A valid SAS cannot bypass a storage firewall or broken private DNS path.
- Rotating an account key invalidates authorizations signed with that key and can break applications that still use it.
- A service endpoint does not give the storage account a private IP address in the subnet.
Key takeaways
- Evaluate storage access as network reachability plus data authorization, and require both to succeed.
- Prefer identity-based access; when delegation is necessary, minimize SAS permissions, scope, and lifetime.
How it works
- The client resolves and reaches a storage endpoint; the storage firewall evaluates network admission; the service then validates the presented identity or signature.
- A SAS signature proves delegation from an account or user delegation key, while its fields restrict what the bearer may do.
Objects and administrative surfaces
- Storage account — public network access, firewall rules, private endpoint connections, account keys, and encryption settings.
- Container or file share — SAS scope, stored access policy, data-role assignment scope, and service-specific authorization.
- Subnet and private DNS zone — service endpoint enablement or private endpoint address and name resolution.
When to use it
- Use Entra authorization for managed users and workloads where the storage service supports the required data actions.
- Use a SAS for temporary constrained delegation and reserve account keys for compatibility cases that cannot use a safer identity model.
Security and governance implications
- Disable unnecessary public exposure, protect keys, require HTTPS, and monitor changes to networking and authorization.
- Design short-lived SAS tokens and rotate keys through the secondary-key pattern when legacy key use remains.
How to reason about this
- Resolve the endpoint and test the route first, inspect firewall and private endpoint state second, then examine token validity and data-role scope.
- For Files, continue from share permission to directory/file permission instead of assuming one successful layer proves the next.
More detail
- Configure default network action and exceptions deliberately, then select Entra credentials, SAS, or keys based on identity support and delegation needs.
- Azure Files identity access is layered: reaching the account is different from authorization to the share and its directories or files.
Ready for the quiz?
- Which credential grants the broadest reusable access to a storage account?
- When can a stored access policy change the behavior of an issued SAS?
- What additional configuration is needed when a private endpoint name resolves publicly?
Related objectives
- D2.1.S1 — Configure Azure Storage firewalls and virtual networks
- D2.1.S2 — Create and use shared access signature (SAS) tokens
- D2.1.S3 — Configure stored access policies
- D2.1.S4 — Manage access keys
- D2.1.S5 — Configure identity-based access for Azure Files