Cram sheet — Configure access to storage

Five mechanisms grant access to storage, and the exam is almost never asking which one works. It is asking which one is revocable, which one is scoped narrowly enough, and which one leaves an account key in somebody's hands.

Three kinds of shared access signature

Microsoft recommends the user delegation SAS, precisely because it is secured with Entra credentials instead of the account key. If a stem mentions least privilege, auditability, or not distributing the key, that is the answer it wants.

Revoking a signature before it expires

• A signature, once issued, normally stands until its expiry. There is no list of issued SAS tokens to revoke from.
• A stored access policy is the mechanism that changes that. It lets you change the start time, expiry time, or permissions for a SAS, or revoke it after it has been issued.
• Stored access policies apply to service-level signatures. A policy on a container can back a signature for the container or the blobs in it; a policy on a file share, the share or its files.
• The blunt instrument is regenerating the account key, which invalidates every service and account SAS signed with it — including the ones you meant to keep.

Account keys

• Azure generates two 512-bit access keys when the account is created.
• The documented rotation practice is to use the first key and reserve the second for when you are rotating: move clients to key2, regenerate key1, move back.
• Microsoft recommends holding keys in Azure Key Vault rather than in application configuration.

The firewall starts open

• By default, storage accounts allow connections from any network. Restricting access is something you do; it is not the starting state.
• Once you switch to selected networks, traffic to all subnets is blocked and requests get a 403 until you add a rule allowing that subnet.
• Trusted-service exceptions exist for Azure services that operate outside your network boundary. They are an exception to the rules you set, not a bypass of authorization.

Identity-based access to Azure Files

Identity-based authentication over SMB uses one of three identity sources: on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos.

⚠ The constraint that decides most questions here: you can use only one identity source per storage account, and it applies to every file share in that account. Two shares in one account cannot use two different sources.

Traps

Check yourself

Where these figures come from

Every figure above was read from the raw documentation below on the day this sheet was written. The sha1 is git hash-object over the bytes as fetched, so a doc that changes underneath this sheet can be detected rather than assumed.