Technical Lab: Create and use shared access signature (SAS) tokens
Questions
Question 1 — Multiple Choice
You need to grant temporary access to a single blob in a storage account for an external partner. The access must expire in 24 hours, be limited to read operations only, and not require the partner to have a Microsoft Entra ID account.
Which type of SAS meets these requirements with the least possible privilege scope?
A) Account SAS, as it allows defining permissions per service and per resource individually.
B) Service SAS without a stored access policy, as it is issued directly for a specific resource within a service.
C) User Delegation SAS, as it uses Microsoft Entra ID credentials to sign the token.
D) Service SAS with a stored access policy, as the policy ensures that access is automatically revoked after 24 hours.
Question 2 — Technical Scenario
An application consumes files from a container in Azure Blob Storage using a Service SAS signed with the account key. After a security incident, the team suspects that the SAS token has been compromised. The token is still within the configured validity period.
sv=2022-11-02&ss=b&srt=o&sp=r&se=2025-04-01T00:00:00Z
&st=2025-03-01T00:00:00Z&spr=https&sig=<signature>
What is the most direct way to immediately invalidate this token?
A) Change the container permissions to private in the Azure portal.
B) Regenerate the storage account key used to sign the token.
C) Remove the token from the application code and redeploy the service.
D) Reduce the token expiration time by editing the se parameter in the URL.
Question 3 — True or False
A User Delegation SAS can be issued for resources in the Blob, Queue, and Table services of Azure Storage, as long as the Microsoft Entra ID principal has the necessary permissions assigned via RBAC.
True or False?
Question 4 — Technical Scenario
A developer created a Service SAS associated with a Stored Access Policy on a container. After realizing that the granted permissions were broader than necessary, they updated the policy to remove write permission. Minutes later, the application can still write to the container using the original token.
blob_client.upload_blob(data, overwrite=True)
# Operation still successful after policy update
What is the most likely cause of this behavior?
A) The Service SAS ignores changes to the Stored Access Policy while the token hasn't expired.
B) The SAS token was issued before the policy existed, so it's not bound to it.
C) The propagation of changes in Stored Access Policies can take up to 30 seconds to be effective globally.
D) The application is using a cached version of the token that was resolved locally by the SDK.
Question 5 — Multiple Choice
When comparing an Account SAS with a Service SAS, which statement correctly describes a functional difference between the two types?
A) The Account SAS can grant access to multiple storage services in a single signature, while the Service SAS is limited to a single service.
B) The Service SAS supports delegation via Microsoft Entra ID, while the Account SAS is always signed with the account key.
C) The Account SAS allows defining permissions at the object level, while the Service SAS operates only at the container level.
D) The Service SAS can be used to manage storage account properties, while the Account SAS is restricted to the data plane.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A Service SAS without a stored access policy is issued directly for a specific resource within a service (in this case, an individual blob), with permissions, expiration time, and scope defined in the token itself. It doesn't require the recipient to have an identity in Microsoft Entra ID, meeting the external partner requirement.
Alternative A is incorrect because the Account SAS has broader scope, potentially covering multiple services and resource types simultaneously, which violates the principle of least privilege for accessing a single blob.
Alternative C is incorrect because the User Delegation SAS requires the issuer to have an identity in Microsoft Entra ID with adequate RBAC permissions. It's not suitable for external partners without an Entra account.
Alternative D confuses the role of the Stored Access Policy: it facilitates revocation and centralized management, but doesn't guarantee automatic expiration different from what would already be defined in the token.
Answer Key — Question 2
Answer: B
SAS tokens signed with the account key cannot be individually revoked, as there's no central record of them in Azure. The only way to invalidate all tokens signed by a compromised key is to regenerate that key. This immediately invalidates any SAS that depended on the signature generated by the previous key.
Alternative A is incorrect because changing the container's access level affects anonymous public access, not SAS tokens that already have permissions embedded in the signature.
Alternative C doesn't invalidate the token: removing the token from the code prevents the application from using it, but any other system or agent that already possesses the URL can continue using it until expiration.
Alternative D is unfeasible because the se parameter is part of the signed string. Changing it in the URL invalidates the cryptographic signature, making the token rejected by the service, but this is not a controlled administrative action.
Answer Key — Question 3
Answer: False
The User Delegation SAS is supported only for the Blob Storage service (including Azure Data Lake Storage Gen2). It cannot be issued for Queue or Table services. This is an important limitation: authentication via Microsoft Entra ID for delegated SAS issuance is available exclusively in the blob context. Assuming that all storage services support User Delegation SAS is a common misconception that can cause design failures in delegated access architectures.
Answer Key — Question 4
Answer: C
When a Service SAS is linked to a Stored Access Policy, changes to that policy (such as removing permissions or modifying the timeframe) are propagated to all tokens that reference it. However, this propagation is not instantaneous: Azure can take up to 30 seconds for the change to be effective across all storage nodes. The described behavior is expected and documented.
Alternative A is incorrect and represents the opposite of the central benefit of Stored Access Policies: precisely the ability to change or revoke tokens without waiting for expiration.
Alternative B describes a different situation: tokens issued before creating a policy and without reference to it are indeed unlinked, but the scenario explicitly states that the token is associated with the policy.
Alternative D is plausible, but the Azure Blob Storage SDK doesn't perform local caching of SAS tokens in a way that overrides 403 error responses returned by the service.
Answer Key — Question 5
Answer: A
The central functional difference between the two types is the scope of coverage: an Account SAS can grant access to multiple services (Blob, Queue, Table, File) in a single signature, with permissions configurable by resource type and operation. The Service SAS is always restricted to a single storage service.
Alternative B inverts the facts: it's the User Delegation SAS (not the Service SAS) that uses delegation via Microsoft Entra ID. Both Account SAS and Service SAS are signed with the account key or user delegation key.
Alternative C is incorrect: the Service SAS can indeed operate at the object level (for example, a specific blob), not just at the container level.
Alternative D is conceptually inverted: account management operations belong to the control plane (ARM) and are not accessible by any type of SAS, which operates exclusively on the data plane.