1. The business problem
Contoso keeps invoices, employee records and customer documents in the storage account contosoinvoices01. Four requests arrive in one week.
- Security wants the account unreachable from the open internet; only the finance application servers in Azure and the Sydney office should connect.
- Sarah in Finance needs to open invoices every day, signing in as herself, with read-only rights.
- An external auditor needs to download last quarter's invoices for two weeks and then lose access, and the auditor has no Contoso account.
- Compliance asks what happens if a disk in Microsoft's datacentre is stolen, and whether Contoso can hold the encryption keys itself.
Each request is a different layer. The layers stack: a request must pass the network gate, then prove who it is, then be allowed the specific action, and the data it reaches is encrypted underneath all of that.
There is a fifth thing, the storage account key. It is not a layer of its own; it is an older way of proving identity that bypasses Entra ID. It appears in section 4 because the exam needs you to know how it relates to the others.
2. Network access: the storage firewall
What it does. Every storage account has a public address such as contosoinvoices01.blob.core.windows.net. The firewall decides which networks are allowed to send requests to that address at all. It does not know who the person is; it only sees where the connection comes from.
Why it exists. Even with strong permissions, an account that answers the whole internet can be probed, brute-forced and hit by leaked credentials. Cutting the network path removes most of that risk before identity is even checked.
How it works. Under Storage account › Networking there are three settings for the public address.
| Setting | Who can reach the public address | Contoso use |
|---|---|---|
| Enabled from all networks | Anyone on the internet may try; identity and permissions still apply | The default; acceptable for public website images, not for invoices |
| Enabled from selected virtual networks and IP addresses | Only the Azure subnets you list, plus the public IP ranges you list; everything else is refused | Add the finance app subnet and the Sydney office IP |
| Disabled | Nobody via the public address. The account is reachable only through a private endpoint, which you must create separately | Highest security; needs the private endpoint set up first |
Two details are needed for the second and third settings to work in practice:
- Adding an Azure subnet to the list turns on a service endpoint (a per-subnet switch that routes traffic to Azure Storage over Microsoft's backbone and stamps it with the subnet's identity, so the firewall can recognise it) for Microsoft.Storage on that subnet. The storage account keeps its public address; the subnet simply becomes a recognised caller.
- Choosing Disabled does not create private connectivity. You must also create a private endpoint (a network card in your own subnet that carries a private IP address for this one storage account, so clients reach it without touching the public address) and link the matching private DNS zone so the account name resolves to that private IP. The networking module covers the steps.
Trusted Azure services. Some Azure services need to reach the account on your behalf: Backup, Monitor diagnostics, Site Recovery and a defined list of others. When the firewall is restricted they are blocked too, so the Networking blade offers Allow Azure services on the trusted services list to access this storage account. This admits only the services on Microsoft's published list, for their supported operations; it is not a general pass for anything running in Azure. Tick it when one of those services is in use, not by habit.
When an administrator chooses it. Selected networks when known subnets and office addresses need access at no extra cost. Disabled plus a private endpoint when the requirement is that the account must not be reachable from the internet at all, or must be reachable from on-premises over a VPN.
Quick check
Security requires that contosoinvoices01 is reachable only from the finance application subnet in VNet1 and from the Sydney office, at the lowest cost. What do you configure?
3. Identity and permissions: Entra ID and roles
What it does. After the firewall lets a connection in, Azure asks who is calling. The recommended answer is an Entra ID sign-in: Sarah authenticates as herself, and an Azure role decides what she may do with the data.
Why it exists. An identity can be audited (the logs show "Sarah read invoice 1234"), can require MFA, can be disabled when she leaves, and can be given exactly the rights her job needs. A shared password or key gives none of that.
How it works. Managing the account and reading its contents are two different kinds of permission:
- Management plane (operations on the account itself: create it, change its firewall, view its settings) roles are the ones from the RBAC lesson: Reader, Contributor, Owner, Storage Account Contributor.
- Data plane (operations on the contents: list containers, read and write blobs, read files and queue messages) roles are separate: Storage Blob Data Reader, Storage Blob Data Contributor, Storage Blob Data Owner, and matching roles for Files, Queues and Tables.
So Contributor on the account lets Ravi change its firewall but does not let him open an invoice through Entra sign-in. Sarah, with only Storage Blob Data Reader on the invoices container, can open invoices but cannot change any setting. Data roles can be assigned at the account, or more narrowly at a single container.
When an administrator chooses it. For every employee and every application that can hold an identity (applications use a managed identity (an identity Azure creates for a VM or app so it can sign in to other services without a stored password)). This is the default choice; the others are for cases where an identity is not possible.
Quick check
Sarah must be able to open invoices in the invoices container by signing in with her own account, and nothing more. Which assignment?
4. Delegated temporary access: shared access signatures and account keys
What a SAS does. The auditor has no Contoso identity, so a role cannot be assigned. A shared access signature (SAS) (a URL for the storage account with a signed set of permissions and an expiry time appended to it) lets you hand over a link that works for exactly the permissions and period you choose.
Why it exists. Temporary, limited access for people and systems that cannot sign in with Entra ID.
How it works. You choose the scope (whole account, one container, one blob), the permissions (read, list, write, delete), the start and expiry, optionally an allowed IP range and HTTPS-only, and Azure signs those choices. The signature is appended to the URL as a query string. Whoever presents the URL gets the stated access until the expiry, whether or not you intended them to have it. Treat a SAS URL like a password.
What the exam asks about
- Scope: account SAS (any service in the account), service SAS (one container or blob), user delegation SAS (blobs, signed with Entra credentials)
- A SAS is not single-use; it works until expiry
- Stopping sharing the URL does not revoke it
- Revocation depends on how it was signed (below)
| SAS type | Signed with | Covers | How to revoke early |
|---|---|---|---|
| Account SAS | Storage account key | Any service in the account | Regenerate the key that signed it (breaks everything else using that key) |
| Service SAS | Storage account key, optionally through a stored access policy | One container, blob, share, queue or table | If tied to a stored access policy: change or delete the policy. Otherwise: regenerate the key |
| User delegation SAS | Your Entra ID sign-in (no key involved) | Blobs only | Revoke the user delegation key for the account, or remove the signer's role |
A stored access policy (a named set of permissions and expiry saved on a container (up to five per container) that a SAS can refer to instead of carrying its own) is the practical way to keep control. Issue the auditor's SAS against policy audit-2025q3; if the engagement ends early, delete the policy and every SAS that refers to it stops working at once. Microsoft recommends the user delegation SAS for blobs because no account key is involved and the signature is tied to a real identity.
What the account key does. Every storage account has two 512-bit keys, key1 and key2, generated by Azure. Presenting either key authorises any data operation on any service in that account, with no identity behind it and no record of who used it. It does not grant Azure management rights such as Owner; it is a data-plane master credential for that one account. Anyone with a management role that includes the "list keys" action (Owner, Contributor, Storage Account Contributor) can read them, which is why a Contributor can usually still reach the data despite lacking a data role.
Why there are two. To rotate without downtime: move every application to key2, regenerate key1, move them back, regenerate key2. Store keys in Key Vault, never in code. If the organisation wants Entra ID only, set Allow storage account key access to Disabled on the Configuration blade; keys and key-signed SAS tokens then stop working entirely.
When an administrator chooses each. Entra ID roles for anyone who can have an identity. A SAS, ideally user delegation and ideally via a stored access policy, for temporary outsiders and for applications that cannot use managed identities. Account keys only for legacy tools that support nothing else, and rotated on a schedule.
Quick check
An auditor was given a SAS URL, valid for 90 days, created against the stored access policy audit-q3 on the invoices container. The engagement ends after 20 days. How do you end their access immediately with the least disruption?
5. Encryption: protecting the bytes themselves
What it does. Everything written to Azure Storage is scrambled before it reaches the disk and unscrambled when an authorised request reads it. If a physical disk were removed from a datacentre, its contents would be unreadable.
Why it exists. Compliance regimes require it, and it protects against the one threat the other layers cannot: physical access to the media.
How it works. This is called Storage Service Encryption (SSE) (Azure's automatic encryption at rest for every storage account, using 256-bit AES). It is always on and cannot be switched off. The only decision is who controls the keys:
- Microsoft-managed keys (default): Microsoft creates, stores and rotates them. Nothing to configure.
- Customer-managed keys: Contoso keeps the key in its own Azure Key Vault (or Managed HSM) and the storage account is pointed at it. Contoso can rotate or revoke the key; revoking makes the data unreadable to everyone until restored. Requirements: the storage account needs a managed identity with access to the vault, and the vault must have soft delete and purge protection enabled so a deleted key cannot take the data with it.
Related settings on the Encryption and Configuration blades: infrastructure encryption adds a second layer with a separate key; encryption scopes allow different keys per container; Secure transfer required forces HTTPS (and encrypted SMB for file shares) so data is also protected in transit.
Encryption is not access control. An authorised user still reads the data in clear through the service. Encryption answers "what if someone gets the disk", not "who may read this file".
Quick check
Compliance requires that Contoso, not Microsoft, controls the key used to encrypt contosoinvoices01, and can revoke it. What must be true? (choose the best answer)
6. Tools: Storage Explorer and AzCopy
Two tools appear in the exam objectives because administrators use them to move data, and each must get through the same layers.
- Azure Storage Explorer is a free desktop program for browsing blobs, files, queues, tables and managed disks. It connects with an Entra ID sign-in, a SAS URL, a connection string or an account key. Drag-and-drop upload and download, create containers, change tiers.
- AzCopy is a command-line tool for bulk transfer.
azcopy loginuses Entra ID; otherwise a SAS goes on the end of the URL.azcopy copymoves files up, down or between accounts;azcopy syncmakes a destination match a source, sending only changed files and, with--delete-destination true, removing extras. Interrupted jobs resume withazcopy jobs resume. Choose it when the question mentions terabytes, scripts or scheduled transfers.
7. Putting the layers together
Contoso's final configuration for contosoinvoices01:
- Firewall: selected networks, finance subnet and Sydney office IP; trusted services allowed because Azure Backup protects the account.
- Sarah: Storage Blob Data Reader on the invoices container, via the Finance-Readers group.
- Finance application: a managed identity with Storage Blob Data Contributor.
- Auditor: user delegation SAS, read and list, 14 days, issued against a stored access policy, restricted to the auditor's IP.
- Keys: stored in Key Vault, rotated quarterly; plan to disable shared-key access once the last legacy script is retired.
- Encryption: customer-managed key in Key Vault, soft delete and purge protection on; Secure transfer required.
You, the admin: the auditor's link, the recommended way
- Confirm you hold Storage Blob Data Reader or higher on the container; a user delegation SAS can only grant permissions you have.
- contosoinvoices01 › Containers › invoices › Access policy › + Add policy: name audit-2025q3, permissions Read + List, expiry in 14 days. Save.
- invoices › Shared access tokens: signing method User delegation key, stored access policy audit-2025q3, allowed IP = the auditor's address, HTTPS only. Generate.
- Send the Blob SAS URL through a secure channel. To cut access early, delete the policy.
Script: az storage container generate-sas --account-name contosoinvoices01 --name invoices --policy-name audit-2025q3 --as-user --auth-mode login · Firewall: az storage account network-rule add --account-name contosoinvoices01 --vnet-name VNet1 --subnet finance then az storage account update --default-action Deny
8. AZ-104 exam scenarios
Scenario A. "The storage account must not be accessible from the internet. Solution: set public network access to Disabled." Incomplete on its own. It meets "not accessible from the internet", but no one can reach it until a private endpoint and its DNS zone exist. If the question also requires that the finance servers can still connect, the answer includes the private endpoint.
Scenario B. "A user with Contributor on the storage account reports they cannot read blobs in Storage Explorer when signed in with Entra ID." Expected. Contributor is management plane. Assign Storage Blob Data Reader. (They could connect with the account key instead, which is exactly why Entra-only designs disable key access.)
Scenario C. "A SAS token issued directly against the account key must be revoked immediately." Regenerate that key. There is no policy to delete. Accept that other clients using the same key break, then move them to the other key. This is the question that teaches why stored access policies exist.
Scenario D. "Minimise administrative effort while giving a partner application read access to blobs for one month without creating an identity for it." Service SAS via a stored access policy (or user delegation SAS if the signer has the role). Entra roles need an identity; account keys give far too much.
Scenario E. "Backup jobs fail after the firewall was restricted to selected networks." Enable the trusted Azure services exception. Backup is on the list; the exception admits it without opening the account to other networks.
Scenario F. "Which of the following protects data if a storage disk is physically stolen: firewall rules, RBAC, SAS or encryption?" Encryption, which is already on; the question tests that you see it as a separate layer.
9. Revision summary
- Four layers: network (firewall, service and private endpoints) → identity (Entra + data roles) → delegated access (SAS) → encryption. Each answers one question; none replaces another.
- Firewall settings: all networks, selected networks (subnets via service endpoints, plus IP ranges), disabled (private endpoint required, created separately). Trusted services exception admits a defined list, not everything.
- Management roles (Reader, Contributor) do not grant data access through Entra sign-in; data roles (Storage Blob Data Reader/Contributor/Owner) do.
- SAS = signed URL with scope, permissions, expiry, optional IP. Not single-use. Revoke via stored access policy (service SAS), key regeneration (account/service SAS), or revoking the delegation key (user delegation SAS). Prefer user delegation SAS.
- Account keys: two per account for rotation; full data access to that account, no identity, no management rights. Keep in Key Vault; disable shared-key access for Entra-only designs.
- Encryption at rest is always on. Customer-managed keys need Key Vault with soft delete and purge protection and a managed identity. Secure transfer required covers transit.
- Storage Explorer for browsing; AzCopy for bulk, scripted and resumable transfers.