AZ-104
Deep Dive
Secure access to Azure Storage is one of the most heavily tested topics on the AZ-104. You need to master the 4 authorization methods, the 3 SAS types, the storage firewall, and when to use Private Endpoints.
Contents
Azure Storage supports 4 distinct authorization methods. The AZ-104 tests when to use each one and which is more secure for each scenario.
| Method | Who uses it | Granularity | Risk |
|---|---|---|---|
| Access Keys (Shared Key) | Applications, scripts, CLI | FULL access to the account | 🔴 High — equivalent to root |
| SAS (Shared Access Signature) | External clients, third-party apps | Per service/container/blob + permissions + time | 🟡 Medium — limited by design |
| Azure AD (Entra ID) + RBAC | Users, services, Managed Identities | By roles (Storage Blob Data Reader, etc.) | 🟢 Low — centralized management |
| Anonymous (Public Access) | Any internet user | Read-only, public containers only | 🔴 High — no authentication |
Microsoft recommends: Entra ID + RBAC whenever possible
Entra ID removes the need to manage secrets (keys, SAS tokens). With Managed Identities, the application stores no credentials at all. Microsoft has stated that the goal is to deprecate the use of Shared Key in the future.
Every Storage Account has 2 access keys (key1 and key2). They are equivalent — having one gives full access. They are used mainly in scenarios where Entra ID is not available.
Risks of Access Keys
Key rotation — zero downtime
The 2-key pattern allows rotation without downtime:
1. App currently uses key1
2. Update the app to use key2
3. Regenerate key1 (no one is using it anymore)
4. If you need to rotate again → go back to key1
Azure Key Vault can manage automatic rotation of storage keys.
A SAS token is a URI with signed parameters that grants temporary, limited access to Storage resources. It's the way to give external clients access without exposing the access keys.
| SAS type | Signed with | Scope | Revocation |
|---|---|---|---|
| Account SAS | The account's Access Key | One or more services (Blob, File, Queue, Table) across the entire account | Regenerate the access key (affects all SAS signed with that key) |
| Service SAS | The account's Access Key | A specific service: a container, a blob, a file share, etc. | Regenerate the access key (same limitation) |
| User Delegation SAS | The user's Entra ID credentials | Blob and Queue only. Maximum validity of 7 days. | Revoke the user's credentials in Entra ID (granular) |
Parameters of a SAS token
sv=2021-06-08 // Storage service version
ss=b // Service: b=blob, f=file, q=queue, t=table
srt=co // Resource types: s=service, c=container, o=object
sp=rwdlacup // Permissions: r=read, w=write, d=delete, l=list, a=add, c=create, u=update, p=process
se=2024-12-31T23:59:59Z // Expiry time (UTC)
sip=192.168.1.0/24 // Allowed IPs (optional)
spr=https // Protocol: https or https,http
sig=base64EncodedSignature // HMAC-SHA256 signature
Stored Access Policy — additional control
A Stored Access Policy (SAP) ties a SAS to a policy defined on the container. It lets you revoke a SAS without regenerating the access key: just modify or delete the SAP. Maximum of 5 SAPs per container. Recommended for long-lived SAS.
Azure Storage supports authentication via Entra ID for Blob, Queue, and Table (not File natively). The data-plane RBAC roles for storage are different from the management roles.
| Storage Data role | Permissions | Typical scope |
|---|---|---|
| Storage Blob Data Owner | Full CRUD + change ACLs (ADLS Gen2) | Account or container |
| Storage Blob Data Contributor | Read, write, delete blobs and containers | Account or container |
| Storage Blob Data Reader | Read-only access to blobs and container metadata | Account or container |
| Storage Blob Delegator | Can generate User Delegation SAS tokens | Account only |
| Storage Queue Data Contributor | CRUD on Queue messages | Account or queue |
| Storage Table Data Contributor | CRUD on Table Storage entities | Account or table |
| Storage File Data SMB Share Contributor | Read/write/delete on Azure Files via SMB with Entra Kerberos | File share |
Contributor ≠ Storage Blob Data Contributor
The Contributor role (an Azure management role) lets you manage the Storage Account but CANNOT read the content of the blobs. You need a data role (Storage Blob Data *) to access the data.
The Storage Firewall controls where the Storage Account can be accessed from. By default all networks are allowed. Once the firewall is enabled, only the allowed rules can access it.
Types of network rules
IP Rules
Allows specific public IP addresses or CIDR ranges. Does not support private IPs (RFC 1918) — use VNet rules for that.
VNet Rules (Service Endpoints)
Allows traffic from specific VNet subnets. Requires enabling the Microsoft.Storage Service Endpoint on the subnet.
Resource Instances
Allows access from specific Azure services (e.g., Azure Backup, Azure Site Recovery) even when the firewall is active.
Trusted Microsoft Services
An exception that lets trusted Microsoft services (Azure Monitor, Backup, Azure AD, etc.) bypass the firewall.
Service Endpoints vs Private Endpoints
Service Endpoint
Private Endpoint
A Private Endpoint creates a NIC with a private IP in your VNet representing an Azure service. Traffic to the Storage Account never goes out to the internet.
Storage sub-resources for Private Endpoints
| Sub-resource | Service | DNS Zone |
|---|---|---|
| blob | Blob Storage | privatelink.blob.core.windows.net |
| file | Azure Files (SMB/NFS) | privatelink.file.core.windows.net |
| queue | Queue Storage | privatelink.queue.core.windows.net |
| table | Table Storage | privatelink.table.core.windows.net |
| dfs | ADLS Gen2 (Data Lake) | privatelink.dfs.core.windows.net |
| web | Static Website | privatelink.web.core.windows.net |
DNS is critical with Private Endpoints
With a Private Endpoint, the storage account's DNS name (mystorageaccount.blob.core.windows.net) must resolve to the private IP, not the public one. A Private DNS Zone linked to the VNet is used. Without this, clients will resolve the public IP and the firewall will block the connection.
Encryption at rest (Storage Service Encryption)
Encryption in transit
| Key type | Managed by | Rotation | When to use |
|---|---|---|---|
| Microsoft Managed Keys (MMK) | Microsoft | Automatic | Most cases — no operational overhead |
| Customer Managed Keys (CMK) | Customer (in Azure Key Vault) | Manual or automatic (Key Vault) | Compliance that requires key control (PCI-DSS, HIPAA) |
| Customer Provided Keys (CPK) | Customer (in each request) | Customer decides | Very special cases — no integrated Key Vault |
User Delegation SAS is the most secure — signed with Entra ID
The User Delegation SAS is signed with Entra ID credentials (not the account key). It can be revoked granularly by removing the permission from the user in Entra, without affecting other SAS. Maximum validity of 7 days for Blob/Queue. It is the most secure option among the SAS types.
Contributor cannot read Blob data
The Contributor role grants management access to the Storage Account (create, configure, delete) but does NOT grant access to the content of blobs or queues. To read data you need Storage Blob Data Reader or Storage Blob Data Contributor.
Service Endpoints do not create private IPs
Service Endpoints restrict traffic so it only leaves from authorized subnets, but the storage account still has a public IP. Private Endpoints DO create a private IP within the VNet. For scenarios where traffic CANNOT go out to the internet, the answer is Private Endpoint.
Revoking a SAS signed with an Access Key requires regenerating the key
There is no way to revoke an Account or Service SAS individually (unless a Stored Access Policy is used). The only way is to regenerate the Access Key — which invalidates ALL SAS signed with that key. A User Delegation SAS CAN be revoked by removing the permission from the user.
Disabling anonymous access at the account level disables all containers
Azure 2023+: there is an account-level Storage Account setting "Allow Blob anonymous access." If disabled, ALL containers are private even if they individually have public access configured. The account setting overrides the container setting.
Did you get this topic?
Test what you just learned
A web application on Azure App Service needs to read blobs from a Storage Account. The security policy prohibits storing secrets or access keys in the app's code or configuration. What is the correct solution?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.