AZ-305 Design data storage solutions Practice Question

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 policy denies creation of blob containers

  Why this is correct

  The policy definition applies a Deny effect to the action Microsoft.Storage/storageAccounts/blobServices/containers/write and further constrains the condition to requests where the HTTP method is PUT. Since creating a blob container is performed through a PUT request to the containers endpoint, this policy blocks that creation attempt outright. The policy does not evaluate container properties or settings; it simply prevents the write operation itself, so any PUT aimed at creating a container will fail with an authorization/denial error.

• ✗

  The blob container requires immutable storage

  Why it's wrong here

  Immutable storage, also known as WORM (Write Once, Read Many), is configured through immutability policies on a container or a storage account (e.g., Microsoft.Storage/storageAccounts/blobServices/containers/immutabilityPolicies). The policy in the exhibit references only the containers/write action and the HTTP method PUT, not any immutability-related ARM resource type or property. Therefore, the denial is not caused by a requirement for immutable storage; the policy would deny the container creation regardless of whether immutability is enabled, disabled, or unset, because the condition does not inspect that attribute.

• ✗

  The user is trying to enable public access on the container

  Why it's wrong here

  Public access for a blob container is controlled by the container's 'publicAccess' property, which governs anonymous read access to blobs and containers. This policy definition, however, does not include any condition on 'publicAccess' or any other property of the container; its only conditions are the resource type and the request method (PUT). Even if the user was attempting to enable public access on a new container, the underlying write request is what gets denied, not the public access setting—the policy would equally deny a PUT request that sets publicAccess to 'None' or omits it, so the cause is the write operation itself.

• ✗

  The storage account does not have encryption enabled

  Why it's wrong here

  Storage Service Encryption (SSE) is enabled for all Azure Storage accounts by default and is configured at the storage account level, not via a container-level write operation. The policy under consideration is scoped to 'Microsoft.Storage/storageAccounts/blobServices/containers/write' and checks only for the HTTP method being PUT, making no reference to the 'encryption' property or any storage account settings. If encryption were not enabled, the error would typically be an Azure Policy denial on the storage account resource type (e.g., Microsoft.Storage/storageAccounts) with an encryption condition, which is not the case here. Thus, this option incorrectly attributes the denial to a storage-account-level encryption requirement that the policy never inspects.

Go deeper

Related to this question