Azure Storage Access for AZ-104: RBAC, SAS and Firewalls
Azure Storage Access for AZ-104: RBAC, SAS and Firewalls
An application fails to download a blob from an Azure storage account. The application team says the storage account exists and its managed identity has Contributor. Networking reports that the private endpoint is healthy. Both statements can be true while the request still fails. To fix the incident, an Azure administrator must distinguish data authorization, token permissions, storage firewall behavior and name resolution.
The AZ-104 exam explicitly covers storage access keys, shared access signatures, stored access policies, identity-based Azure Files access and storage network restrictions. It also expects administrators to configure redundancy, encryption, lifecycle management and protection. A useful way to learn those objectives is to follow one request from the client to the exact storage operation it must perform.
An Azure Storage 403 is a symptom, not a diagnosis
Start with the caller. Is the request made by a person using Microsoft Entra ID, an application managed identity, a service principal, a shared key or a URL containing a shared access signature? Next identify the exact target: the storage account management resource, a blob in a container, a file share mounted through SMB, or another service endpoint. A permission that works for the Azure portal’s management view might not authorize the underlying data read.
Then ask where the request originates and which hostname it uses. A client running in a private virtual network may expect a private endpoint while its resolver returns the public storage address. Conversely, the client might reach the private IP but lack permission to read the blob. Authentication, authorization and connectivity are independent conditions; solving one does not automatically solve the others.
The error details, relevant identity, token or SAS expiry, network settings and client-side DNS result should narrow the cause. Do not make a production storage account publicly accessible just to see whether an error disappears. In a disposable lab, change one condition at a time and record which signal responds.
Management-plane roles are not automatically blob-data roles
Azure Resource Manager controls actions such as creating a storage account or configuring its properties. Microsoft Entra authorization for blob-data operations uses data actions. Contributor or Storage Account Contributor may permit substantial management operations without granting blob read access through Entra authorization. Storage Blob Data Reader is designed for reading data; Data Contributor provides additional write and delete data actions. The role must be assigned to the correct principal at a scope that includes the target data.
Consider an ingestion service that must upload documents but must not manage accounts or change networking. Give its managed identity a data role scoped to the necessary container or another appropriately narrow parent scope, not Owner at the subscription. A separate platform identity may need management permissions for infrastructure deployment. Test with the service’s actual identity and a token obtained for the correct storage audience; testing as an administrator conceals missing workload permissions.
Role assignment propagation and cached credentials can delay the apparent effect of a newly added role. If a role is correct but a request still fails, confirm which identity and token the client is using before granting another broad assignment. The deeper principle is that permission should follow the data operation, not the familiar name of a broad Azure resource role.
Choose among user delegation, service and account SAS deliberately
A shared access signature (SAS) grants time-limited, permission-scoped access without requiring the recipient to have a normal Microsoft Entra login to the storage resource. The URL or token itself carries authority, so it must be protected as a secret. A leaked SAS with read permissions can expose data until it expires or is otherwise rendered unusable. For security-sensitive systems, short validity periods and narrow resource scopes are more defensible than an account-wide token.
Microsoft distinguishes user delegation SAS, service SAS and account SAS. A user delegation SAS is secured using Microsoft Entra credentials rather than the account key and is generally preferred where supported. Service and account SAS are secured using the storage account key. A service SAS can authorize operations against an individual storage service; an account SAS can cover multiple services and certain account-level operations. The difference changes both the blast radius of a compromised token and how administrators manage issuance.
Do not describe every SAS as revocable in exactly the same way. A stored access policy can constrain a service SAS and can be changed to invalidate SAS tokens associated with that policy, subject to service behavior. A user delegation SAS and account SAS do not use stored access policies. A user delegation SAS can be affected by revoking its delegation keys, while key-signed tokens may require storage key rotation or other security measures. Design the revocation method before distributing production SAS URLs.
Account keys are powerful and deserve a rotation plan
Storage account access keys authorize broad operations for services that support Shared Key authentication. They are operationally convenient for older applications and integration tools, but using a key everywhere collapses identities into one powerful shared credential. Whoever obtains it may be able to operate far beyond one application’s intended data container. Prefer Microsoft Entra-based authorization when the client and service support it, and reserve shared keys for justified compatibility requirements.
If a system still uses account keys, inventory each consumer before rotation. A typical rotation uses an alternate key only after applications have switched and been verified, so there is not a sudden outage. Store secrets using an approved secret-management process rather than embedding them in a deployment template or source repository. Where supported, consider disabling Shared Key authorization after verifying all required clients can use stronger alternatives.
Exam questions that mention “regenerate a key” may be testing more than the location of the setting. The safe administrator must predict which services depend on that key and how to roll the change back without reintroducing a compromised secret.
Firewalls, service endpoints and private endpoints solve different access problems
A storage firewall decides which network paths and origins may reach supported storage endpoints. Virtual network rules with service endpoints can restrict access through selected subnets while traffic still reaches the storage service’s public endpoint through Azure’s service routing. A private endpoint maps a particular storage service instance to a private IP in a virtual network, with DNS configured so clients resolve the familiar service hostname to that private address.
For a private-endpoint deployment, record the endpoint’s target service and subresource, the private IP, the related private DNS zone and its virtual-network links. A client can have the right data role and still fail because its DNS resolver returns a public address that the storage firewall refuses. VNet and private-endpoint troubleshooting is useful here because name resolution, routing and NSG evaluation all affect how the request reaches storage.
Do not assume that creating a private endpoint automatically disables every public path. Review the target storage account’s public network access policy separately. Likewise, peering two networks provides routing connectivity under its configured conditions, not a guarantee that their clients share the same private DNS visibility. Secure a storage design by proving both the intended allowed path and the denied alternative.
Azure Files combines share access with file permissions
Blob containers and file shares look similar in storage-account navigation, but a file share mounted through SMB has a different access model. A user or machine may need both the appropriate share-level permission and the file- or directory-level permission provided by the file system. A role assignment that authorizes reading a share at one layer does not necessarily grant access to every file within it. The identity source and authentication method must also match the supported Azure Files configuration.
In a hybrid organization, test a Windows client opening one allowed directory and another it should not access. Verify the share path, chosen identity, share permissions and file ACLs. When the same share is used from Azure and on-premises clients, consider the network path and port requirements as well as the identity integration. An otherwise valid RBAC assignment cannot compensate for a network restriction or a denied NTFS permission.
The existing Azure Files mounting guide explains the operational share workflow; the exam-level lesson is to separate service authorization, file authorization and connectivity when diagnosing access failures.
Data resilience settings do not replace an access-control design
Redundancy options such as locally redundant or zone-redundant storage address different infrastructure failure scenarios; they do not determine who may download a document. Blob versioning and soft delete can help recover from accidental updates or deletions, but they are not substitutes for least-privilege access or a complete disaster-recovery plan. Lifecycle management can move or remove data based on rules, so an incorrect lifecycle policy may create unexpected cost or retention effects even when permissions are correct.
A sensible operational design ties protection to the data’s behavior. A frequently overwritten document repository may need versioning and a recovery procedure that selects the intended version. An archival repository may prioritize retention policies, infrequent access tiers and controlled deletion. Test the restoration of a representative object and record whether applications continue to read the correct version afterward. Avoid assuming a storage account’s redundancy choice alone proves a specific recovery time.
An administrator should be able to explain what will be lost when a container is deleted, which recovery protections are currently enabled and whether there is a documented method to get the data back. These answers belong beside the authorization and firewall settings in the service runbook.
Use a small test application to isolate failures
Create a disposable storage account with a private blob container and a small non-sensitive file. First access the blob from a test client using an appropriate Microsoft Entra data role. Remove the data role and repeat the request while leaving the network unchanged. Then restore the role, wait for authorization to settle and change the storage firewall so the same client is no longer permitted. Compare the observed failures and the evidence available in each case.
Issue a tightly scoped SAS for the test object, note the allowed operations and expiry, and prove that it cannot perform an operation outside its permissions. Do not include live SAS tokens in screenshots or shared study notes. If experimenting with a private endpoint, confirm the ordinary storage hostname resolves to the endpoint’s private IP from the right network before changing any access controls.
End by testing a recoverable deletion with soft delete or versioning and cleaning up the lab’s resources. The most valuable result is not that every request succeeded; it is a record of which control changed the outcome and why.
Choose a correction that does not weaken unrelated controls
Suppose a help-desk ticket reads: “The storage account works from my workstation but not from the application.” That statement does not prove the application’s identity is wrong. It may use a different DNS resolver, different subnet, different authentication scheme or expired SAS. Ask for the application principal, destination hostname, effective network origin and exact operation. Then use the least disruptive test needed to distinguish the hypotheses.
Avoid solving a private access failure by permanently enabling public anonymous access, regenerating account keys blindly or granting broad Owner permissions. Each of those actions changes security properties unrelated to the original symptom. Correct the denied data role, expired token, DNS link or firewall condition that the evidence identifies, and record a successful retest as the actual application identity.
For AZ-104, that process ties together storage administration, identity, network troubleshooting and recovery. Knowing the product terms matters; knowing which layer owns a particular failure is what makes the knowledge operational.
- Category: Certifications Microsoft
- Tags: AZ-104
