nerdexam
Microsoft

AZ-500 · Question #61

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. Option B (No) is correct because creating a lock on Sa1 does not revoke existing SAS tokens or stored access policies - it only prevents the storage account from being deleted or modified at the management plane level, but it has no effect on the data plane access that SAS…

Submitted by haruto_sh· 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 create a lock on Sa1. Does this meet the goal?

Options

  • AYes
  • BNo

How the community answered

(28 responses)
  • A
    29% (8)
  • B
    71% (20)

Explanation

Option B (No) is correct because creating a lock on Sa1 does not revoke existing SAS tokens or stored access policies - it only prevents the storage account from being deleted or modified at the management plane level, but it has no effect on the data plane access that SAS tokens provide.

Why Option A (Yes) is wrong: A lock (ReadOnly or Delete) controls Azure Resource Manager operations, not data access. Unauthorized users could still use existing valid SAS tokens to access blob and file services even with a lock in place, making it ineffective for revoking active access.

The correct solution to revoke all SAS-based access would be to regenerate the storage account access keys - this immediately invalidates all SAS tokens and stored access policies that were derived from those keys, effectively cutting off all unauthorized access.

Memory Tip: Think of SAS tokens like copies of a key - a lock on the building doesn't change the keys already in circulation. To invalidate all copies at once, you must change the master key (regenerate storage account keys). When you see "revoke all SAS access," always think "regenerate the keys."

Topics

#Azure Storage#Shared Access Signatures (SAS)#Azure Resource Locks#Access Revocation

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full AZ-500 Practice