Stored Access Policy
What it is
A stored access policy is an access rule defined on a container, file share, or queue (not on an individual blob) that supplies conditions — start time, expiry time, and permissions — which a SAS referencing it inherits. It gives an extra, central layer of control over shared-access tokens.
Why it exists
A standalone SAS embeds expiry/permissions inside the token itself, so you can’t change them later. By attaching a stored access policy, you centralize that definition server-side, which lets you revoke a SAS, widen or tighten its permissions, or extend its validity — without issuing a new token.
Key ideas
- Where it lives: attached to a container, file share, or queue, and referenced by a service SAS.
- What it controls: start time, expiry, and permissions. These become conditions of any SAS that points at the policy. (IP/protocol restrictions stay in the SAS query string, not in the policy.)
- Revocation: to kill all tokens governed by a policy, delete the policy or rename it (renaming breaks existing references, instantly invalidating those SAS).
- Widen/change: edit the policy’s permissions/expiry and existing SAS are automatically affected next time they validate.
- Used with service SAS — an account SAS does not use a stored access policy (account SAS are only revoked by cycling the account key).
How it fits (diagram)
Exam notes
- #1 exam concept: stored access policy = the revocable way to govern SAS — delete/rename the policy and all linked tokens stop working.
- Attach it at the container / file share / queue level; it cannot reference IP/protocol, and account SAS don’t use it.
- Role in SAS question flows: “how do you revoke a SAS later?” → stored access policy.
Related
sas-token · storage-access-keys · storage-account · azure-queues
📘 Source: Microsoft Learn — Shared Access Signatures (SAS overview)