Configure Access to Azure Storage: SAS, Keys & Firewalls (AZ-104)

Access to an Azure storage account is governed by two separate questions: can you reach the endpoint (networking) and are you authorized (data-plane authorization). You must answer both, and the exam frequently splits a scenario across them.

The networking layer is the storage firewall: by default a storage account accepts connections from any network, but you can lock it to selected virtual networks and public IP ranges, or expose it only through a private endpoint.

The authorization layer offers three mechanisms, and choosing correctly is the heart of this topic:

• Access keys — two account-wide keys that grant full control of everything in the account. Powerful and dangerous.
• Shared access signature (SAS) tokens — signed URLs that grant scoped, time-limited access to specific resources.
• Microsoft Entra ID with Azure RBAC — identity-based access where users and applications authenticate with Entra credentials and receive role assignments. This is the option Microsoft recommends.

These layers combine: even a valid SAS is refused if the firewall blocks the caller's network, and even an open firewall grants nothing without a key, SAS, or role assignment. For the exam, always separate the network decision from the authorization decision — a question about IP restrictions is a firewall question, while a question about who may read a blob is an authorization question. Getting that split right resolves most access questions before you weigh the finer details.

By default, a storage account is reachable from the public internet by anyone who has a key or valid SAS. The storage firewall tightens this by changing the account's Public network access setting from Enabled from all networks to Enabled from selected virtual networks and IP addresses, or Disabled entirely.

When you select networks, you allow either of two things:

• Virtual network rules — you add specific subnets, which relies on a service endpoint for Microsoft.Storage on that subnet. Traffic from those subnets then reaches the account over the Azure backbone rather than the public internet.
• IP address ranges — public IPv4 ranges in CIDR notation that may connect, typically your office egress addresses. You cannot add private RFC 1918 ranges here, because they are not routable on the public endpoint.

A separate private endpoint goes further: it projects the storage account into your virtual network with a private IP address, so traffic never traverses the public internet at all. With private endpoints you usually set public network access to Disabled.

One switch you must know is Allow trusted Microsoft services. Enabling it lets platform services such as Azure Backup, Azure Monitor, and Event Grid bypass the firewall, and you keep it on so those features keep working after you lock the account down. On the exam, wording like only my corporate IP range maps to an IP firewall rule, while only this subnet maps to a virtual network rule backed by a service endpoint.

Every storage account is created with two access keys, key1 and key2. Each key grants full, unrestricted control of the entire account — every blob, file, queue, and table, with permission to read, write, and delete. There is no way to scope a key to a single container or to make it read-only; possession of a key is total power over the account. This is why keys are described as all-or-nothing and are the highest-risk credential in Azure Storage.

Two keys exist specifically to enable rotation without downtime. The pattern is: your applications use key1; when it is time to rotate, you switch applications to key2, then regenerate key1, then later repeat in the other direction. Because one key stays valid while you regenerate the other, you never break running clients. You regenerate either key from the Access keys blade, and you should rotate on a schedule and immediately if a key is ever exposed.

Regenerating a key instantly invalidates every SAS that was signed with it, because both account SAS and service SAS tokens are signed by an account key. That is both a risk — you can accidentally break legitimate SAS holders — and a blunt emergency tool for revoking everything at once. To reduce reliance on keys, store them in Azure Key Vault and prefer Entra RBAC or SAS for day-to-day access. On the exam, full access to the whole account and cannot be limited to one container describe an access key.

A shared access signature (SAS) is a signed token, appended to a resource URL as a query string, that grants scoped, time-limited access without sharing an account key. Every SAS encodes the same core constraints, and you should be able to list them: the permissions granted (read, write, delete, list, add, create), the start and expiry time, an optional allowed IP range, the allowed protocol (HTTPS only, or HTTPS and HTTP), and the signed resources the token applies to.

There are three kinds of SAS, and the exam tests the distinction:

A user delegation SAS is the option to prefer. It is signed with a key that Azure issues to a Microsoft Entra identity rather than with an account key, so it does not depend on a shared secret, and it is revoked by revoking the Entra credential or reducing its permissions. On the exam, the most secure SAS or secured with Entra credentials always points to a user delegation SAS, while a SAS that must work for a client with no Entra identity points to a service or account SAS.

A plain service SAS has a hidden weakness: once you hand out the token, you cannot easily revoke it. Its permissions and expiry are baked into the signed string, so short of regenerating the account key (which kills every SAS at once), an issued token stays valid until it expires on its own. If you gave a partner a token good for 30 days and the relationship ends on day 2, you are stuck.

A stored access policy solves this. You define a named policy on a container (or file share, queue, or table) that holds the permissions and expiry, then you issue a service SAS that references the policy by name instead of embedding those values in the token. Now the policy is the source of truth: to revoke the SAS you delete or rename the policy, or set its expiry to a time in the past, and every SAS bound to it stops working immediately — without touching account keys.

You can also modify a policy's permissions or extend its expiry, and every SAS tied to it inherits the change. A container supports up to five stored access policies at a time. The key exam fact is the reason to use one: server-side control that lets you revoke or change a service SAS after it has been issued. A user delegation SAS is revoked differently — through its Entra credential — but for a key-signed service SAS, the stored access policy is the revocation mechanism.

With the individual mechanisms covered, step back and compare the authorization options as an administrator would when designing access. The decision usually comes down to how much you trust the caller and how easily you must revoke them.

The guidance Microsoft repeats is to prefer Microsoft Entra ID with Azure RBAC whenever the caller can have an identity, because there is no secret to leak and access is centrally auditable and instantly revocable. Fall back to a user delegation SAS when you must hand a URL to something outside your directory but still want Entra-backed signing. Use a service SAS with a stored access policy when the client has no Entra identity at all. Reserve access keys for setup and emergencies. On the exam, ranking these from most to least secure — Entra RBAC, user delegation SAS, service SAS, then access keys — resolves many questions on its own.

Azure Files SMB shares can authenticate users with identities instead of the storage account key, which is what makes them a drop-in replacement for an on-premises file server. This is identity-based access, and it applies to the SMB protocol. You enable one of three directory sources on the storage account:

• On-premises Active Directory Domain Services (AD DS) — your existing domain controllers authenticate users, with identities synced to Microsoft Entra using Entra Connect.
• Microsoft Entra Domain Services — a managed domain in Azure provides Kerberos authentication for cloud-only scenarios.
• Microsoft Entra Kerberos for hybrid identities — Entra-joined clients authenticate hybrid users directly, without domain controllers in the path.

Configuring it is a two-part permission model you must remember. Share-level permissions are granted with Azure RBAC roles — for example Storage File Data SMB Share Reader, Contributor, or Elevated Contributor — assigned to a user or group, while directory- and file-level permissions are the standard Windows NTFS ACLs enforced inside the share. A user's effective access is the intersection of the two.

The payoff is that users mount the share with their own domain credentials and get single sign-on, and you never distribute the storage account key. For the exam, SMB file share with domain sign-in or replace a file server without sharing the account key points to identity-based access for Azure Files, and remember the split: RBAC for share-level access, NTFS ACLs for file-level access.

Bring the pieces together with a task you might see on the exam. A partner company needs read-only access to the blobs in one container for the next two weeks, they have no identity in your Microsoft Entra tenant, and — critically — you must be able to cut off their access early if the project is cancelled. What do you configure?

Because the partner has no Entra identity, both RBAC and a user delegation SAS are out, so you use a service SAS scoped to that single container with read and list permissions only. A raw service SAS, however, cannot be revoked before expiry — so you first create a stored access policy on the container that defines the read and list permissions and the two-week expiry, then issue the service SAS referencing that policy by name. You give the partner the resulting URL.

Now every requirement is met: access is scoped to one container, read-only, time-limited, and, most importantly, revocable. If the project is cancelled you simply delete the stored access policy and the SAS stops working instantly — with no key regeneration and no impact on any other client. For extra safety you can add an allowed IP range for the partner's network and require HTTPS only in the SAS. This combination — service SAS plus stored access policy — is the canonical answer whenever a question asks you to grant temporary scoped access that you can revoke.