Troubleshooting Lab: Configure stored access policies
Diagnostic Scenarios
Scenario 1 — Root Cause
A reporting application accesses blobs in a container called exportacoes using a SAS generated two weeks ago. The SAS was created linked to a stored access policy called politica-export. Last night, the infrastructure team rotated the secondary key of the storage account as part of a planned security procedure. This morning, the application started returning errors when trying to read the files.
The application log shows:
StorageException: Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctly including the signature.
RequestId: 7e2f3a91-0001-004b-0034-abc123000000
StatusCode: 403
Additional information collected by the team:
- The stored access policy
politica-exportstill exists and is configured with expiration for2026-12-31 - The
exportacoescontainer has public access disabled - The SAS was generated using the primary key of the account
- No changes were made to the stored access policy in the last 72 hours
What is the root cause of the observed 403 error?
A) The stored access policy politica-export was corrupted during the secondary key rotation, invalidating the reference in the SAS token.
B) The container's public access was disabled after the SAS generation, indirectly revoking the token.
C) The SAS was signed with the primary key, which was not rotated; however, the secondary key rotation altered the account's authentication metadata, invalidating existing tokens.
D) The SAS was signed with the account's primary key, and that key was rotated as part of the same procedure, invalidating the token signature.
Scenario 2 — Diagnostic Sequence
An administrator receives the following report: "The application returns 403 when trying to write files to the uploads container, but could write normally until yesterday."
The administrator has access to the Azure portal and CLI. The following investigation steps are available, but were listed out of order:
- Check what permissions are defined in the stored access policy associated with the SAS in use
- Confirm if the SAS in use is linked to a stored access policy or is an ad hoc SAS
- Check if the expiration date of the stored access policy or SAS has already passed
- Confirm if the stored access policy referenced by the SAS still exists in the container
- Check the Storage Account audit logs to identify which specific operation is being denied
What is the correct investigation sequence for this symptom?
A) 5 → 1 → 3 → 4 → 2
B) 2 → 4 → 3 → 1 → 5
C) 3 → 2 → 4 → 1 → 5
D) 1 → 4 → 2 → 3 → 5
Scenario 3 — Root Cause
A data team maintains four stored access policies in a container called landing-zone. The architect decides to further segment access and executes the following command to add a fifth policy:
az storage container policy create \
--container-name landing-zone \
--name "politica-auditoria" \
--account-name dadoscorp \
--permissions rl \
--expiry 2026-03-31
The command returns success. The next day, two different teams report that their applications, which used SAS linked to distinct policies, started receiving 403 errors intermittently and randomly.
Information collected:
- None of the four existing policies were modified or deleted
- The expiration dates of the affected policies are all in the future
- The Storage Account had no network or firewall configuration changes
- The
landing-zonecontainer had exactly 4 policies before the operation
What is the root cause of the intermittent 403 errors?
A) The creation of the fifth policy exceeded the supported limit for the container, corrupting the policy set and making some references invalid for Azure Storage.
B) Adding a fifth policy to the container exceeded the limit of 5 policies per storage account, forcing Azure to automatically remove one of the oldest policies.
C) The new politica-auditoria policy received the same permissions as another existing policy, causing access resolution conflict for SAS tokens that reference policies with overlapping permissions.
D) The limit of stored access policies per container is 4, and the attempt to add a fifth policy resulted in undefined behavior, silently corrupting the stored policy set.
Scenario 4 — Action Decision
The security team identified that a stored access policy called politica-parceiro in a production container called dados-sensiveis was configured with excessive permissions: read, write, and delete (rwd). The cause is confirmed: the operator who created the policy made a configuration error three days ago.
The operational context is as follows:
- There are at least 12 active SAS linked to this policy, distributed among external partner applications
- Immediately revoking the policy would interrupt all production integrations
- The partner team cannot be contacted outside business hours, and it's 11 PM
- A maintenance window is scheduled for tomorrow at 6 AM
- The excessive permissions are
wandd; therpermission is legitimate and necessary - There has been no misuse of the
wanddpermissions so far, according to audit logs
What is the correct action to take at this moment?
A) Immediately delete the politica-parceiro policy to eliminate the risk of misusing excessive permissions, accepting the interruption of integrations as necessary.
B) Wait for the 6 AM maintenance window and, in it, update the policy to contain only the r permission, preserving integration continuity and communicating with partners during business hours.
C) Create a new politica-parceiro-v2 policy with only r permission and request that applications migrate to the new SAS before the maintenance window.
D) Immediately rotate the account key used to sign the SAS, invalidating all tokens and forcing reissuance with the corrected policy tonight.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: D
The decisive clue is explicitly in the statement: the SAS was generated using the primary key of the account. A SAS is an HMAC signature calculated over its parameters using an account key. When the key used in the signature is rotated, Azure can no longer verify the token signature, regardless of the associated stored access policy still existing. The result is exactly the 403 error with the signature authentication failure message.
The irrelevant information in this scenario is the secondary key rotation. It was purposely included to induce the reader to conclude that the wrong type of rotation occurred, when in fact the statement confirms that the primary key (used in the signature) was the one rotated.
Alternative C represents the most dangerous reasoning error: it accepts that the primary key was not rotated and invents a fictitious mechanism of "authentication metadata" affected by secondary key rotation. Acting based on this hypothesis would lead the administrator to investigate the entire account instead of simply reissuing the SAS with the new primary key.
Answer Key — Scenario 2
Answer: B
The correct sequence is 2 → 4 → 3 → 1 → 5, which follows the logic of progressive elimination from most general to most specific.
The first step is to determine if the SAS has an associated policy (step 2), as this defines all subsequent investigation logic. If it's an ad hoc SAS, the following steps are different. Once the association is confirmed, the next natural step is to verify if the policy still exists (step 4), as its absence is an immediate cause of 403. Then check expiration (step 3), then the configured permissions (step 1), and finally the audit logs (step 5) for specific operational details.
Alternative C starts with expiration (step 3), which is a valid hypothesis but premature: checking expiration before confirming if the policy exists means investigating a detail before validating the structure that supports it. Alternative A starts with logs, which are a detailing tool, not an initial diagnostic tool.
Answer Key — Scenario 3
Answer: A
The Azure Storage limit is 5 stored access policies per container, not per account. The landing-zone container had exactly 4 policies, and creating the fifth should not have failed. However, the described behavior (intermittent and random errors after reaching the exact limit) indicates that the actual stably supported limit is 4, and the fifth entry silently corrupted the internally stored set, making some references invalid.
Alternative B is wrong because the limit applies per container, not per account. Alternative C invents a mechanism of "overlapping permission conflict" that doesn't exist in the stored access policies implementation: policies with similar permissions don't conflict with each other. Alternative D is wrong in stating that the limit is 4; the documented limit is 5. The described behavior occurs because reaching the maximum limit and still operating within it can generate instability depending on the service's internal implementation.
The central diagnostic point: the symptom (random errors in policies that weren't touched) appeared immediately after an operation that reached the resource limit. This is the warning sign to investigate platform limits before investigating individual configurations.
Answer Key — Scenario 4
Answer: B
The scenario presents three critical simultaneous constraints: real but unproven misuse risk, inability to contact partners outside business hours, and an available maintenance window in a few hours. The correct action is to wait for the maintenance window and update the policy to remove only the excessive permissions, preserving r.
Alternative A ignores the production impact constraint. Deleting the policy at 11 PM would interrupt 12 active integrations without possibility of communication or coordination, causing a major incident greater than the risk it aims to mitigate.
Alternative C seems reasonable but requires external applications to migrate to a new SAS during the night without partner team support, which is operationally unfeasible in the described context.
Alternative D is the most dangerous: rotating the account key invalidates all SAS signed with that key in all containers of the account, not just those linked to the problematic policy. This would cause a widespread authentication incident with much larger scope than the original problem.
The central lesson of this scenario: when risk is present but not materialized, and there's a nearby correction window, surgical action in the planned window is superior to immediate high-impact action.
Troubleshooting Tree: Configure stored access policies
Color legend:
- Dark blue: initial symptom for entering the tree
- Blue: diagnostic question to be actively verified
- Red: identified cause for the observed problem
- Green: recommended action or resolution path
To use this tree when facing a real problem, start with the root node (403 error in a SAS request) and answer each diagnostic question based on what is observable in the environment: policy existence, account key state, expiration dates, configured permissions, and platform limits. Each answer eliminates a branch and brings the diagnosis closer to the real cause. Never skip a layer to go directly to action: the correct action depends on the identified cause, and different causes with the same symptom require distinct corrections.