AZ-204 Practice Question: SAS token scope misconfiguration allowing upload…
External partners are given Shared Access Signatures to upload product images to a specific Blob Storage container named 'images'. A partner reports accidentally uploading files to the 'contracts' container, which should not be accessible. What is the most likely configuration mistake?
⚠ Common exam trap
Test-takers frequently confuse the scope of a SAS (account-level vs. resource-level) with other SAS properties like expiry time or stored access policies, leading them to incorrectly attribute the security breach to token lifetime or policy misconfiguration rather than the fundamental lack of resource-level scoping.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The SAS was generated at the storage account level, granting write access that applies to multiple containers rather than being scoped to the 'images' container only
A SAS generated at the storage account level grants permissions across all containers within that account. When the SAS URI includes only the account endpoint (e.g., https://<account>.blob.core.windows.net/) and a set of permissions (like write), the token can be used to access any container, including 'contracts'. To restrict access to a single container, the SAS must be scoped to the container resource URI (e.g., https://<account>.blob.core.windows.net/images) and the signed resource type must be 'c' (container) or 'b' (blob), not 's' (service).
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The SAS was generated at the storage account level, granting write access that applies to multiple containers rather than being scoped to the 'images' container only
Why this is correct
An account SAS with sr=c (container) permission and no container restriction grants access to all containers. A container SAS is generated with a specific container name in the signed resource URI (e.g., https://account.blob.core.windows.net/images?sig=...), making it impossible for the holder to use the SAS against any other container.
- ✗
The SAS expiry time is too long, giving partners time to discover and access other containers
Why it's wrong here
SAS expiry controls the time window during which the SAS is valid but does not affect which containers the SAS can access. Even an expired SAS has a defined resource scope — changing the expiry does not change the scope.
- ✗
The partner used a storage account key instead of the provided SAS token
Why it's wrong here
An account key grants unrestricted access to the entire storage account, which would be a far more severe security incident. The scenario describes a partner using a SAS — the SAS is the control that needs to be scoped correctly.
- ✗
The SAS was signed with a stored access policy that did not name the correct container
Why it's wrong here
Stored access policies are attached to a specific container. If a SAS references a stored access policy, it inherits the policy's permissions — but the SAS's signed resource URI still determines which container it grants access to, not the policy name.
Go deeper
Related to this question
About these practice questions
One of 881 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.