Implement and manage storage practice questions

When granting temporary, delegated access to blob data, prefer a user delegation SAS: it is signed with Microsoft Entra ID credentials, can be scoped tightly to a resource and permission set, and avoids ever handling account keys.

The user delegation SAS satisfies every constraint: no account key is used in signing, the scope is a single blob, the permission is read-only, and the expiry is 24 hours. The account SAS and service SAS options both fail because their signatures require an account access key, and the account SAS additionally over-grants across services. Handing out the access key itself is the worst option because keys confer full, non-scoped access to all data in the account.

1. Note the constraint: account access keys must not be used or shared, which eliminates account SAS, service SAS, and direct key distribution.
2. Choose the user delegation SAS, which is signed with an Entra-issued user delegation key.
3. Scope the SAS to the specific blob, grant only the read permission, and set the expiry to 24 hours.
4. Deliver the SAS URL to the partner over a secure channel and require HTTPS-only access.

Exam tip: For time-limited delegated access without touching account keys, issue a tightly scoped user delegation SAS.

A stored access policy centralizes the permissions and expiry of the service SAS tokens that reference it. Because the policy is checked server-side on each request, changing or deleting it takes effect immediately for all dependent tokens.

Deleting the stored access policy is the precise, surgical revocation mechanism: only tokens that reference that policy die, and every other SAS in the account keeps working. Key rotation is the blunt alternative, revoking every SAS signed with the rotated keys account-wide, which the scenario forbids. Changing the container access level only affects anonymous readers, and network rules gate by source network, not by token.

1. Confirm the issued service SAS tokens reference a stored access policy rather than carrying ad-hoc parameters.
2. Delete the stored access policy on the container (or change its expiry to a past date).
3. Verify a request using one of the revoked tokens now returns an authorization error.
4. If access must continue for some clients, create a new policy and issue fresh SAS tokens against it.

Exam tip: Issue service SAS tokens against stored access policies so you can revoke them instantly by deleting the policy instead of rotating account keys.

Account SAS and service SAS tokens are signed with one of the two storage account access keys. Regenerating a key invalidates every SAS whose signature was produced with it, which is both the risk and the emergency revocation lever for ad-hoc SAS.

Because the token's signature was computed with key1, validation fails as soon as key1 is regenerated, so the tokens are dead immediately, not at expiry. Azure has no mechanism to migrate a token to key2, and user delegation SAS tokens are the ones NOT affected by key rotation since they are signed with a user delegation key from Entra ID.

1. Recall that ad-hoc account and service SAS signatures are computed from a specific account access key.
2. Recognize that regenerating that key breaks signature validation for every token it signed, effective immediately.
3. Plan rotations accordingly: reissue SAS tokens signed with the other key first, or accept the outage.
4. Remember that key rotation is the only way to revoke an ad-hoc SAS, which is why stored access policies or user delegation SAS are preferred.

Exam tip: Rotating an access key instantly invalidates every ad-hoc SAS signed with that key; only user delegation SAS tokens survive key rotation.

Azure separates control-plane roles (managing the storage account resource) from data-plane roles (accessing the data inside it). Reading blob data with an Entra identity requires a data-plane role such as Storage Blob Data Reader.

Storage Blob Data Reader is the narrowest built-in role that satisfies the requirement: read-only access to blob data via Entra ID authorization. Reader fails because control-plane visibility does not include data access. Storage Blob Data Contributor and Contributor both over-grant: the former adds write and delete on data, and the latter grants sweeping management rights including the ability to list access keys, effectively full data access.

1. Determine whether the requirement is control-plane (manage the account) or data-plane (read the data); here it is data-plane read.
2. Shortlist the data-plane blob roles: Storage Blob Data Reader, Contributor, and Owner.
3. Apply least privilege and pick the read-only role, Storage Blob Data Reader.
4. Assign the role at the narrowest sensible scope, such as the specific container or storage account.

Exam tip: For Entra-based read-only access to blob data, assign Storage Blob Data Reader; the plain Reader role sees the resource but not the data.

Least privilege in Azure Storage means picking the narrowest data-plane role that covers the required operations and assigning it at the narrowest scope, which can be a single container.

Uploading and overwriting are write operations on blob data, so the principal needs Storage Blob Data Contributor; scoping the assignment to the container limits blast radius. Storage Blob Data Owner over-grants because it adds permission management, and account-level scope widens access to all containers. Contributor is a control-plane role that could retrieve access keys and reconfigure the account. Storage Blob Data Reader simply cannot write.

1. List the operations required: create and overwrite blobs, which are data-plane writes.
2. Match the operations to the smallest built-in role that includes them: Storage Blob Data Contributor.
3. Reject roles that add unneeded rights (Data Owner, Contributor) or lack needed rights (Data Reader).
4. Assign the role at container scope rather than storage account or resource group scope.

Exam tip: Match the smallest data-plane role to the operations needed and assign it at the narrowest scope, down to a single container.

Disabling Shared Key authorization (AllowSharedKeyAccess = false) forces all requests to be authorized with Microsoft Entra ID. Anything whose validity chains back to an account access key stops working, including account SAS and service SAS.

The user delegation SAS survives because its signature comes from a user delegation key obtained with Entra ID credentials, keeping it within the Entra authorization chain. The account SAS, the service SAS, and raw key auth all fail because each is validated against a storage account access key, which is precisely the mechanism that was turned off. This setting is how organizations enforce an Entra-only access posture.

1. Understand that AllowSharedKeyAccess = false blocks every request whose authorization derives from the account access keys.
2. Classify each SAS type by its signing mechanism: account and service SAS use account keys; user delegation SAS uses an Entra-issued key.
3. Conclude that only Entra-based methods keep working: direct Entra tokens with RBAC roles and user delegation SAS.
4. Before flipping the setting in production, audit workloads for key or key-signed SAS usage to avoid outages.

Exam tip: Disabling Shared Key authorization kills account SAS and service SAS along with direct key access; only Entra ID tokens and user delegation SAS keep working.