Azure Storage SAS and RBAC Access Control
Short answer
User1 cannot write to container2 because the SAS is container-scoped, not object-scoped. User2's ability depends on their specific RBAC role assignment relative to the SAS scope.
Question
You have an Azure subscription that contains two users named User1 and User2 and the blob containers shown in the following table.
Policy1 is configured as shown in the following exhibit.
You assign the roles for storagte1 as shown in the following table.
The storage1 account has the following shared access signature (SAS) named SAS1:
Dates are in MM/DD/YYYY format.
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.
Key Takeaways
The core trap is confusing container-level SAS permissions with object-level operations; a Container SAS allows listing or managing the container but does not grant Write access to blobs inside it unless explicitly configured otherwise.
This scenario tests the intersection of Azure RBAC roles, storage account policies, and Shared Access Signature (SAS) constraints. It establishes that SAS permissions are additive to but do not override RBAC denials, and that resource-level SAS tokens restrict operations to specific entity types.
Common mistake: Learners often assume that because a user has a role allowing write access, any valid SAS token will also allow writing. They fail to recognize that a Container-scoped SAS token inherently lacks the 'Write' permission for individual blob objects.
Expert Analysis
Why the Answer Is Correct
To determine access, you must evaluate both the assigned RBAC role and the SAS token constraints simultaneously. For User1 on Container2: The RBAC role 'Storage Blob Data Contributor' allows writing blobs. However, the SAS token is scoped to the 'Container' level. By definition, a Container SAS grants permissions to list blobs or manage the container itself, but it does NOT grant permission to write, add, or create individual blob objects within that container. Therefore, User1 cannot write to a blob in Container2 using this specific SAS.
Why Other Candidate Answers Are Wrong
Many candidates incorrectly select 'Yes' for User1's write capability, assuming the high-level contributor role overrides the granular SAS limitation. Others might misinterpret the expiration date, thinking December 5th is outside the window when it is clearly within the start/end dates. For User2, if they lack the necessary RBAC role (e.g., if assigned only Reader), even a perfect Object SAS would fail due to RBAC denial. The key is understanding that SAS provides authorization based on the token, while RBAC provides authorization based on identity; both must permit the action.
Community Comment Notes
As mcdesilva74 noted, "Container-level access covers operations such as listing blobs... Writing a blob is an object-level operation." This highlights the critical distinction between managing the container metadata and manipulating the data within it. Another common confusion involves the date format; ensure MM/DD/YYYY is read correctly to avoid false negatives on time-based restrictions.
Official Reference
https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access?tabs=portal
This link opens the official vendor documentation in a new tab.
Exam Strategy
Always check the Scope of the SAS first. If it is 'Container', remember that Write/Add/Create permissions apply to the container structure, not the blobs inside. If the question asks about writing a blob, look for an 'Object' scope or explicit blob permissions in a container SAS, which are rare and specific.
Frequently Asked Questions
Can a Container SAS allow writing to blobs?
Does RBAC override SAS?
Discussion 2 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 2
-
mcdesilva74 👍 11. User1 can write to container2 on December 5, 2025: No The date is inside the SAS window, but the allowed resource type is only Container, not Object. Container-level access covers operations such as listing blobs or managing the container. Writing a blob is an object-level operation, so Write, Add, and Create don’t apply to blobs under this SAS. 2. User2 can write to container1 on December 20, 2025: No This fails for the same resource-type reason. Policy1 doesn’t help. Stored access policies only work with service SAS tokens, and SAS1 is an account SAS, so Policy1’s read-only permission and start time play no part in it. The Contributor role is also irrelevant, because a SAS authenticates with the account key and not with Azure RBAC. 3. User1 can read from container2 on January 10: No The SAS expired on 12/31/2025, so it’s invalid whether the year in the statement is 2025 or 2026. User1’s role doesn’t matter for the same reason. The uncertainty: I’m not sure the question author intended the resource-type trap. If the author only meant the date and policy to matter, the answer would be Yes, Yes, No. I chose No, No, No because the exhibit deliberately lists resource types as “Container” only. If you have the official answer, check which of the two it gives. Statement 3 is No either way.
-
Greens 👍 11. User1 can write to container2 on December 5, 2025: No User1 is a Storage Blob Data Reader therefore has only read-only access to blob data 2. User2 can write to container1 on December 20, 2025: No Container1 has a pre-defined policy1 which only allows read access 3. User1 can read from container2 on January 10: No The date exceeds the permitted range of the Shared Access Signature (SAS)
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All SC-500 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SC-500 Practice Test →