A vendor's contract with Cascade Regional Airlines ended, so an administrator deleted the stored access policy that several outstanding SAS URLs referenced, and those URLs stopped working immediately. The URLs carried no expiry of their own — they took their permissions and expiry from the policy. Two weeks later a scripted container deployment re-creates a stored access policy on the same container using the same policy identifier. What happens to the vendor's old SAS URLs?
Select an answer to reveal the explanation.
Short Explanation
Think of the policy identifier as a lock, and each SAS URL as a key cut for that lock. Delete the lock and the key opens nothing — but fit a brand-new lock with the same ID and that old key slides right back in. That's exactly why you never reuse a stored access policy identifier after you've revoked one.
Full Explanation
A SAS that references a stored access policy stores only the policy's identifier in the token; the service resolves that identifier on the container at request time and applies whatever permissions and expiry the policy currently holds. Deleting the policy leaves the identifier unresolvable, so every SAS built on it fails — but the token itself is untouched and still cryptographically valid. Re-creating a policy under the same identifier therefore rebinds those tokens and they work again, now governed by the new policy's permissions and expiry rather than the old one's. Treating deletion as permanent destruction is the misconception being tested: nothing about the token was invalidated, only the thing it pointed at. Key rotation is a genuinely different revocation mechanism, and deleting a policy does not trigger it; a token signed with a still-current key stays signed. And Azure has no notion of degrading an orphaned SAS to read-only — a SAS either resolves to a valid signature and policy or it is refused outright. The practical rule is to retire a policy identifier permanently once it has been used for revocation, and to prefer a user delegation SAS where revoking the underlying role assignment kills the token outright. To check this, re-create a test policy under a previously revoked ID and replay an old SAS URL: if it returns data, that identifier is still live and must not be reused.