nerdexam
Microsoft

AZ-500 · Question #12

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might…

The correct answer is B. No. Why B (No) is Correct: Generating new SASs does not revoke existing SASs that unauthorized users already possess - those old tokens remain valid until they expire. Since both SAS tokens and stored access policies are in use, simply creating new ones does nothing to invalidate…

Submitted by weili_xi· Mar 6, 2026Secure compute, storage, and databases

Question

Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution. After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear in the review screen. You have an Azure Subscription named Sub1. You have an Azure Storage account named Sa1 in a resource group named RG1. Users and applications access the blob service and the file service in Sa1 by using several shared access signatures (SASs) and stored access policies. You discover that unauthorized users accessed both the file service and the blob service. You need to revoke all access to Sa1. Solution: You generate new SASs. Does this meet the goal?

Options

  • AYes
  • BNo

How the community answered

(27 responses)
  • A
    26% (7)
  • B
    74% (20)

Explanation

Why B (No) is Correct: Generating new SASs does not revoke existing SASs that unauthorized users already possess - those old tokens remain valid until they expire. Since both SAS tokens and stored access policies are in use, simply creating new ones does nothing to invalidate the compromised credentials already in circulation.

Why A (Yes) is Wrong: Generating new SASs only creates additional access tokens; it has no effect on revoking or invalidating previously issued SASs. Unauthorized users would still retain access using the original tokens.

The Correct Approach: The proper solution to immediately revoke all access is to regenerate the Storage Account's access keys. Since SASs are derived from these keys, rotating the keys instantly invalidates all existing SASs and stored access policies that were based on the old keys - cutting off all unauthorized access in one action.

Memory Tip: Think of the storage account key as the "master lock." SASs are like copies of keys made from that master - if you make a new copy (new SAS), old copies still work. But if you change the master lock (regenerate the account key), all old copies become useless instantly.

Topics

#Azure Storage Security#Shared Access Signatures (SAS)#Access Revocation

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full AZ-500 Practice