Connect to and consume Azure services and third-party services →hardMultiple ChoiceObjective-mapped

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

{
  "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
  "apiVersion": "2021-02-01",
  "name": "images-container",
  "properties": {
    "publicAccess": "None"
  }
}

Refer to the exhibit. A developer deploys this ARM template to create a blob container. Later, they attempt to upload a file to the container using a SAS token. What is the result?

⚠ Common exam trap

The trap here is that candidates mistakenly think setting `publicAccess` to `None` blocks all access, including SAS tokens, when in fact SAS tokens provide explicit delegated access that overrides the public access setting.

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 upload succeeds if the SAS token has write permission.

The ARM template creates a blob container with `publicAccess` set to `None`, meaning no anonymous public access. However, a SAS token with write permission grants delegated access to the container, bypassing the public access setting. Therefore, the upload succeeds because the SAS token provides the necessary authorization, regardless of the container's public access level.

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 upload succeeds only if the SAS token includes read permission.
Why it's wrong here
An upload operation involves creating or modifying data within Azure Blob Storage. Read permission, as its name suggests, only grants the ability to retrieve or view existing data. Therefore, a Shared Access Signature (SAS) token that exclusively includes read permission is insufficient to perform an upload, and any attempt to write data will result in an authorization failure.
✗
The container is not created because publicAccess is set to None.
Why it's wrong here
Setting the `publicAccess` property to `None` for an Azure Blob Storage container simply designates it as private, meaning anonymous public access is disallowed. This is a standard and valid configuration for securing storage containers. The ARM template will successfully create the container with this privacy setting, as it does not prevent the container's provisioning.
✓
The upload succeeds if the SAS token has write permission.
Why this is correct
To successfully upload a blob to an Azure Storage container, the Shared Access Signature (SAS) token must explicitly include `Write` permission. This permission authorizes the client to create new blobs or overwrite existing ones within the specified container. The SAS token provides authenticated access, which overrides the container's public access setting, enabling uploads even to private containers.
✗
The upload fails because the container is private.
Why it's wrong here
The privacy setting of an Azure Blob Storage container, configured by `publicAccess` set to `None`, only prevents anonymous public access. It does not block access for authenticated requests made with valid credentials, such as a Shared Access Signature (SAS) token. If the SAS token itself is correctly generated with the necessary write permissions, it provides the authorization required for the upload to succeed, irrespective of the container's private status.

Go deeper

AZ-204 Practice Question: Connect to and consume Azure services and third-party services

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question