Describe an analytics workload on Azure →hardMultiple ChoiceObjective-mapped

DP-900 Describe an analytics workload on Azure Practice Question

Exhibit

{
  "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
  "apiVersion": "2023-01-01",
  "name": "[concat(parameters('storageAccountName'), '/default/', parameters('containerName'))]",
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
  ],
  "properties": {
    "publicAccess": "None"
  }
}

Refer to the exhibit. A team is deploying an Azure Storage container using an ARM template. The template sets publicAccess to 'None'. However, after deployment, users report they cannot access data even with a valid SAS token. What is the most likely cause?

⚠ Common exam trap

A common mix-up: candidates confuse 'publicAccess = None' with disabling all forms of access, including SAS tokens, but in reality, SAS tokens are a separate authorization mechanism that remains functional on private containers.

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 token was generated with insufficient permissions

The ARM template sets publicAccess to 'None', which only disables anonymous public access to the container. It does not affect SAS token access. The most likely cause is that the SAS token was generated with insufficient permissions (e.g., missing read, list, or write permissions) or with a restricted scope (e.g., limited to a specific blob or with a short expiry), preventing users from accessing the data even though the container is private.

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 container disables SAS tokens by default
Why it's wrong here
SAS tokens are not a feature that can be toggled on or off at the container level; they are generated at the storage account level using either the account key or a user delegation. The container's publicAccess='None' setting only disables anonymous public read/write access, not SAS-based authenticated access. Additionally, no container property controls SAS existence or validity, so this option incorrectly attributes a storage-account-level mechanism to the container.
✗
The storage account firewall is blocking all traffic
Why it's wrong here
Firewall rules restrict the set of IP addresses or virtual networks that can reach the storage account, but they operate at the network layer rather than the authorization layer. Even if a firewall were misconfigured, a SAS token would still authenticate the request as long as the client's IP is allowed by the firewall rules. Since the exhibit's ARM template does not show any firewall configuration, there is no evidence that network traffic is being blocked, making this an unsubstantiated explanation for SAS failure.
✗
The storage account requires RBAC permissions, not SAS
Why it's wrong here
Azure Blob Storage supports multiple independent authorization methods, including shared key, shared access signature (SAS), and Azure AD RBAC, and these are not mutually exclusive. A SAS token is self-contained and carries its own permissions, so no additional RBAC role assignments are required to use it; RBAC would only be necessary if you were using Azure AD-based identity instead of a SAS token. Therefore, the storage account does not 'require' RBAC to the exclusion of SAS, and this option mischaracterizes the relationship between the two mechanisms.
✓
The SAS token was generated with insufficient permissions
Why this is correct
A SAS token is only as effective as the permissions it was granted at generation time; if the token lacks the read, write, list, or delete permission needed for the attempted operation, the storage service will deny the request despite the token being properly formatted. The container's publicAccess='None' setting is irrelevant because it only governs anonymous access, not requests authenticated with a valid SAS token. Since the token is evidently present, the most plausible failure point is that the token's permission scope does not match the operation being called.

Go deeper

DP-900 Describe an analytics workload on Azure Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question