Troubleshooting Lab: Create and use shared access signature (SAS) tokens
Diagnostic Scenarios
Scenario 1 — Root Cause
A production web application reads files from a container in Azure Blob Storage using a Service SAS generated programmatically. The application worked correctly for weeks. Last Monday at 09:00 AM (UTC-3), users started reporting errors when trying to download files.
The infrastructure team verified that the storage account is active, the container exists, blobs are present, and network connectivity shows no anomalies. The security team reported that they performed a key rotation on the account the previous Friday at 6:00 PM (UTC-3) as part of the monthly governance cycle.
The application logged the following error:
StorageErrorCode: AuthenticationFailed
RequestId: 4f2c1a3b-0000-0000-0000-000000000000
StatusCode: 403
ErrorMessage: Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctly
including the signature.
The SAS token generation code uses the account key retrieved from an environment variable set at deployment time, without dynamic reloading.
What is the root cause of the authentication error?
A) The container had its public access permissions removed during key rotation, invalidating SAS access.
B) The SAS token signature was generated with the old key and became invalid after rotation, as the environment variable was not updated with the new key.
C) The SAS token reached its natural expiration time coincidentally close to the key rotation.
D) Key rotation changed the storage account endpoint, making blob URLs invalid.
Scenario 2 — Action Decision
The security team identified that a SAS token linked to a Stored Access Policy called leitura-parceiros was accidentally included in a public GitHub repository for about 40 minutes before being removed. The token is still within its validity period. The cause is confirmed: the token was publicly exposed.
The storage account is shared among three production systems, all currently active. Two of these systems use SAS tokens linked to the same leitura-parceiros policy. The third system uses a different policy called escrita-interna.
The team has permission to modify Stored Access Policies on the account.
What is the correct action to take at this moment?
A) Regenerate the storage account key immediately to invalidate all active SAS tokens.
B) Delete and recreate the Stored Access Policy leitura-parceiros with a new identifier, invalidating tokens linked to it without affecting the system using escrita-interna.
C) Wait for the natural expiration of the exposed token, since it has already been removed from the repository and the risk of misuse is low.
D) Change the expiration time of the Stored Access Policy leitura-parceiros to a date in the past, invalidating linked tokens.
Scenario 3 — Root Cause
A developer created a Python script to generate User Delegation SAS tokens for blobs in a storage account. The script authenticates via Microsoft Entra ID using a service principal with correct credentials. Token generation works without errors. However, when trying to use the generated tokens to access blobs, the application receives the following error:
StorageErrorCode: AuthorizationPermissionMismatch
RequestId: 7a9e4b2c-0000-0000-0000-000000000000
StatusCode: 403
ErrorMessage: This request is not authorized to perform this operation
using this permission.
The developer confirmed that:
- The service principal has the
Readerrole on the subscription - The SAS token was generated with read permission (
sp=r) - The expiration time is correct and in the future
- The storage account doesn't have firewall enabled
- The container exists and contains the expected blobs
What is the root cause of the error?
A) The service principal doesn't have a data plane RBAC role assigned at the storage account or container scope, which prevents issuing User Delegation SAS with valid permissions.
B) The Reader role doesn't allow blob reading via SAS because it's a control plane role, not a data plane role.
C) The storage account firewall is blocking requests, despite the developer's claim to the contrary.
D) The service principal cannot be used to generate User Delegation SAS; only interactive users with active sessions in Microsoft Entra ID can request delegation keys.
Scenario 4 — Diagnostic Sequence
A team receives a ticket: an integration with external partners has stopped working. Partners use a URL with Service SAS to upload files to a container. The URL was generated two days ago by the internal team and sent via email to partners.
The following investigation steps are available, but out of order:
- Verify if the SAS token contains write permission (
sp=worsp=c) in the URL. - Confirm with partners what exact error message is being returned.
- Check the token's expiration date and time (
se=) against current UTC time. - Confirm if the storage account key used to sign the token was rotated after URL generation.
- Verify if the destination container still exists in the storage account.
What is the correct investigation sequence for this scenario?
A) 1 → 3 → 5 → 4 → 2
B) 2 → 5 → 3 → 4 → 1
C) 3 → 1 → 4 → 5 → 2
D) 5 → 2 → 1 → 3 → 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The central clue lies in the combination of two facts: the environment variable is set only at deployment time without dynamic reloading, and key rotation occurred after the last deployment. This means the application continues using the old key to sign new SAS tokens, and signatures generated with a revoked key are mathematically invalid for Azure Storage, resulting in a 403 error with AuthenticationFailed.
The information about users reporting the error on Monday is contextual detail that doesn't influence the diagnosis: what matters is that rotation occurred before error onset, without variable updates.
Alternative A represents a common misconception: key rotation doesn't alter container public access permissions. These are completely independent configurations.
Alternative C is the most dangerous distractor. The timing coincidence between rotation and error onset could lead to the wrong diagnosis of natural expiration, but the statement provides no data about token validity periods and the failure pattern is systematic, not gradual.
Alternative D is technically impossible: key rotation doesn't alter storage endpoints.
Answer Key — Scenario 2
Answer: B
The scenario presents a critical constraint: two production systems use tokens linked to the leitura-parceiros policy, while a third uses escrita-interna. The correct action eliminates only the risk vector without interrupting the third system.
Deleting and recreating the Stored Access Policy leitura-parceiros with a new identifier immediately invalidates all tokens that reference it, as the si= field in the token points to an identifier that ceases to exist. The system using escrita-interna is unaffected.
Alternative A is the most dangerous distractor: regenerating the account key invalidates all SAS tokens for all systems, including the one using escrita-interna, causing unnecessary production interruption. This action would be correct only if no Stored Access Policy existed or if the token was signed directly with the key.
Alternative C ignores that 40 minutes of public exposure is sufficient time for the token to be copied and exploited. Waiting for expiration is unacceptable given confirmed exposure.
Alternative D seems reasonable but doesn't work: modifying only the expiration time of a Stored Access Policy doesn't invalidate already-issued tokens that reference that policy if the policy identifier remains the same. Effective invalidation requires deletion or replacement of the policy with a new identifier.
Answer Key — Scenario 3
Answer: A
The User Delegation SAS is signed using a delegation key obtained from Azure Storage. For Storage to issue this key to a service principal, it needs a data plane RBAC role assigned at the appropriate scope, such as Storage Blob Data Reader, Storage Blob Data Contributor, or equivalent. The Reader role is a control plane (ARM) role and doesn't grant permissions over the data itself.
The critical clue is in the AuthorizationPermissionMismatch error: the token was generated, but the permissions embedded in it aren't supported because the principal that issued it doesn't have authority over the data plane. Storage validates not only the signature but also whether the issuing principal had the right to grant that permission.
Alternative B is partially correct in identifying that Reader is control plane, but wrong in stating this prevents blob reading via SAS. The problem isn't reading itself, but the lack of a data plane role to issue the delegation key with validity.
Information about disabled firewall and existing container are irrelevant details purposely included to divert diagnosis toward network or infrastructure problems.
Alternative D is false: service principals can generate User Delegation SAS normally, provided they have the correct data plane RBAC permissions.
Answer Key — Scenario 4
Answer: B
The correct sequence is: 2 → 5 → 3 → 4 → 1.
Diagnosis should start with the exact symptom reported by the external system (step 2), as the error message immediately delimits the investigation space. Next, verify if the destination resource exists (step 5), as a deleted container would make any token invalid regardless of other factors. Then examine the expiration time (step 3), which is the most frequent cause of SAS failure after initial operation. Next, check if key rotation occurred after generation (step 4), which would invalidate the signature. Finally, confirm if token permissions cover the write operation (step 1), which would be verified last as it's the least likely aspect to have changed, since the URL was generated by the internal team.
Alternative A starts with permission inspection before even confirming the error, which is inefficient. Alternative C begins with expiration without first confirming the exact symptom, risking investigation of the wrong cause. Alternative D starts with container existence without first collecting the reported error, losing the most objective available information.
Troubleshooting Tree: Create and use shared access signature (SAS) tokens
Color Legend:
| Color | Meaning |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question (binary or state decision) |
| Red | Identified cause |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start at the root node by identifying the type of error received. At each question node, answer based on what is directly observable: token URL parameters, storage account configurations, role assignments, and destination resource state. Follow the path that corresponds to the observed state until reaching an identified cause node. From there, apply the corresponding corrective action before reissuing or reconfiguring the token.