A sedge-meadow hydrology team wants one container-side place to revise expiry for several service SAS tokens without regenerating each signature string from scratch. What should the developer define?
Select an answer to reveal the explanation.
Short Explanation
A stored access policy is the master checklist pinned on the container: change expiry once, and service SAS tokens that point at that policy follow along (up to five policies). User-delegation and account SAS do not ride that container policy the same way.
Full Explanation
Stored access policies on a container (limited to five per container) let service SAS tokens reference a policy identifier instead of embedding all constraints only in the signature string. When the sedge-meadow team needs one container-side place to revise expiry for several service SAS tokens, they define or update a stored access policy’s expiry (and permissions) on the container; signed tokens that reference that policy identifier pick up the revised constraints without regenerating each signature from scratch. That is the classic operational reason to prefer policy-backed service SAS for revoke/adjust scenarios.
Claiming a stored access policy on a user-delegation SAS because only that SAS type supports it fails: stored access policies apply to service SAS on containers/queues/tables/files as documented; user-delegation SAS is keyed off Microsoft Entra user delegation keys and is a different mechanism.
An account-level stored access policy that every container inherits automatically fails because stored access policies are defined on the resource (for example the container), not as an automatic account-wide inheritance model of that form.
A Cosmos DB TTL policy that expires Blob SAS tokens fails because Cosmos TTL expires documents in Cosmos DB; it does not revoke or expire Blob SAS signatures.
Exam caveat: if you omit a stored policy identifier and put expiry only in the SAS, you typically must regenerate signatures to change expiry and may rely on rotating account keys to revoke broadly—plan policy identifiers up front. Operational check: create a container stored access policy, mint two service SAS tokens referencing it, shorten the policy expiry, and confirm clients fail after the new expiry without rewriting the SAS strings.