AZ-104 Question #788: Real Exam Question with Answer & Explanation

Question

Hotspot Question You have an Azure subscription named Subscription In Subscription1, you create an Azure file share named share1. You create a shared access signature (SAS) named SAS1 as shown in the following exhibit. To answer, select the appropriate options in the answer area. NOTE: Each correct selection is worth one point. Answer:

Options

• __typehotspot
• variantdropdown

Explanation

The correct options are 'will be prompted for credentials' for Scenario 1 due to insufficient SAS permissions/scope for Storage Explorer, and 'will have no access' for Scenario 2 because a Blob SAS cannot authenticate access to an Azure File Share.

Approach. Scenario 1: Connect to Storage Account with Storage Explorer (Jan 2, 2025)

1. SAS Validity Period & IP: The date (Jan 2, 2025) falls within the SAS validity period (Jan 1, 2025 - Jan 1, 2028), and there are no IP restrictions, so 193.77.134.1 is allowed.
2. Allowed Services & Permissions: The SAS (SAS1) is configured ONLY for 'Blob' service, and crucially, has NO permissions (Read, Write, List, etc.) selected, even for Blob. This means the SAS is effectively useless for granting any access to blobs, and certainly not for other services.
3. Storage Explorer Behavior: When connecting to a broad 'storage account' using a SAS that is valid by date/IP but provides no permissions or is only scoped to a specific service (Blob in this case) while the tool attempts broader access, Storage Explorer (a GUI tool) often recognizes the SAS as a technically valid token but insufficient for the requested operation. Instead of a hard 'no access' error, it will prompt the user for alternative, more comprehensive credentials (like account keys or Azure AD) to gain full access to the storage account. This is a common user experience design in such tools. Therefore, the correct interaction is to select 'will be prompted for credentials'.

Scenario 2: Connect to Azure File Share with net use (Jan 10, 2025)

1. SAS Validity Period & IP: The date (Jan 10, 2025) falls within the SAS validity period, and there are no IP restrictions, so 193.77.134.50 is allowed.
2. Allowed Services: The SAS (SAS1) is configured ONLY for 'Blob' service. The question specifies connecting to 'share1', which is an Azure File Share.
3. Service Type Mismatch: A SAS token generated for the Blob service CANNOT be used to authenticate access to the File service. These are distinct services within Azure Storage, and their SAS tokens are not interchangeable. The net use command, being a low-level command-line utility, will directly fail to authenticate because the provided SAS is for the wrong service type. Therefore, the correct interaction is to select 'will have no access'.

Common mistakes.

• common_mistake. 1. Selecting 'will have no access' for Scenario 1: While the SAS grants no effective permissions, Storage Explorer often attempts to provide a user-friendly experience. If a SAS is technically valid (not expired, correct IP) but insufficient in scope or permissions for the requested access (connecting to the whole storage account), Storage Explorer might prompt for stronger credentials rather than just failing silently.

1. Selecting 'will be prompted for credentials' for Scenario 2: The net use command is a command-line utility for network shares. When provided with an incorrect type of credential (a Blob SAS for a File Share), it typically results in a direct authentication failure and denial of access, rather than prompting the user for different credentials. It's a fundamental mismatch, not just an insufficient permission.
2. Selecting 'will have read-only access' or 'will have read, write, and list access' for either scenario: This is incorrect because the SAS configuration clearly shows that no permissions whatsoever are checked for any service, making the SAS incapable of granting any form of access even if the service type matched.
3. Overlooking 'Allowed services' setting: A common mistake is not realizing the SAS is strictly for 'Blob' and trying to apply it to a 'File' share (Scenario 2). This is a critical detail for determining access.

• alternative_explanation_for_scenario1. Some might argue 'will have no access' for Scenario 1 because the SAS has no permissions. However, the nuance for GUI tools like Storage Explorer is that they might try to obtain broader access, and if the provided SAS is valid but insufficient, they prompt for full credentials. If it was a command-line tool or a simple API call, 'no access' would be more likely.

Concept tested. The core concepts tested are:

1. Azure Shared Access Signature (SAS) Configuration: Understanding the parameters of a SAS, including its validity period, allowed IP addresses, allowed services (Blob, File, Queue, Table), and explicit permissions.
2. Service Type Specificity: The critical concept that a SAS token is generated for a specific Azure Storage service (e.g., Blob) and cannot be used to authenticate requests for a different service (e.g., File).
3. SAS Permissions: The requirement for explicit permissions to be granted via a SAS for any access to be possible.
4. Client Tool Behavior: How different client tools (Azure Storage Explorer vs. net use command) handle SAS tokens that are valid but insufficient or outright incorrect for the requested operation.

No community discussion yet for this question.