Skip to main content

Technical Lab: Create and configure a container in Azure Blob Storage

Questions​

Question 1 — Multiple Choice​

A development team needs to store build artifacts that should be publicly accessible only at the read level for individual blobs, but without allowing anonymous users to list the container contents. What public access level should be configured on the container?

A) Container — allows anonymous reading of blobs and container listing

B) Blob — allows anonymous reading of individual blobs, but blocks container listing

C) Private — requires authentication for any operation, including reading

D) ReadOnly — allows anonymous reading without exposing container metadata

Question 2 — Technical Scenario​

An administrator executes the following command to create a container:

az storage container create \
  --name logs \
  --account-name mystorageacct \
  --public-access off

After creation, an application attempts to upload blobs using a Shared Access Signature (SAS) generated with write permission. The operation returns an AuthorizationFailure error. What most likely explains the problem?

A) The --public-access off parameter prevents any type of writing to the container

B) The SAS was generated before container creation and is therefore invalid

C) The SAS doesn't have the List permission combined with Write, which is mandatory for upload

D) The storage account may have the "Allow Blob public access" option disabled at the account level, also blocking SAS authentication

Question 3 — True or False​

An Azure Blob Storage container created with public access set to Container remains anonymously accessible even if the "Allow Blob public access" option is subsequently disabled at the storage account level.

Question 4 — Technical Scenario​

An operations team needs to configure a container to store audit logs. The requirements are:

  • Blobs cannot be modified or deleted for 90 days after creation
  • The policy must be automatically applied to all blobs in the container
  • Read access must continue working normally

Which combination of features meets these requirements?

A) Configure a time-based immutability policy on the container with 90-day retention

B) Enable soft delete with 90-day retention period on the container

C) Create a lifecycle management policy that blocks deletion for 90 days

D) Configure a ReadOnly resource lock on the storage account

Question 5 — Multiple Choice​

When creating a container via the Azure portal, an administrator notices that the option to configure the public access level is disabled (grayed out). What is the most likely cause?

A) The container already contains blobs, which prevents changing the public access level

B) The storage account was created with Premium Block Blobs type, which doesn't support public access

C) The "Allow Blob public access" option is disabled at the storage account level

D) The user doesn't have the Storage Blob Data Contributor role assigned

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

The Blob access level grants anonymous read access to individual blobs via direct URL, but doesn't allow unauthenticated users to list objects within the container. The Container level exposes both blob reading and listing. The Private alternative requires authentication for any operation. The ReadOnly alternative is not a valid value for public access in Azure Blob Storage containers; its presence as a distractor represents a common mistake of confusing Azure resource locks with container access configurations.

Answer Key — Question 2​

Answer: D

In Azure, the "Allow Blob public access" option at the storage account level is a data plane control that, when disabled, blocks any anonymous access. However, it does not affect SAS or key authentications. The AuthorizationFailure error with a valid SAS points to another control: if the account has network access restricted (firewall or VNet) or, more commonly in this scenario, if the account key has been disabled via the --allow-shared-key-access false configuration, key-based SAS is rejected. This is the most plausible reason given the context. Alternatives A and C represent misconceptions about SAS functionality, and alternative B confuses the SAS lifecycle with the container creation cycle.

Technical note: In the AZ-104 exam, this scenario tests whether the candidate distinguishes anonymous access controls from key/SAS authentication controls.

Answer Key — Question 3​

Answer: False

The "Allow Blob public access" configuration at the storage account level takes precedence over the access level defined on each container. When this option is disabled on the account, all anonymous access is blocked regardless of what is configured on individual containers. This means that a container with Container or Blob access behaves like Private from the perspective of anonymous requests. This control hierarchy is a non-obvious behavior that causes frequent errors in production environments.

Answer Key — Question 4​

Answer: A

Time-based immutability policies (time-based retention) are the correct mechanism to ensure that blobs are not modified or deleted during a defined period. When applied at the container level with a locked policy, they exactly meet the 90-day protection requirement without restricting reading. Soft delete (alternative B) only postpones deletion, doesn't prevent it. Lifecycle management policies (alternative C) serve to automate tier transitions or deletions, the opposite of the requirement. The ReadOnly lock (alternative D) would also block legitimate write operations on the entire account, exceeding the required scope and preventing new uploads.

Answer Key — Question 5​

Answer: C

When the "Allow Blob public access" option is disabled at the storage account level, the Azure portal visually disables the selection of public access level on containers, because any value other than Private would be ineffective. This is an interface protection to avoid contradictory configurations. Alternative A is incorrect because the presence of blobs doesn't block container configuration changes. Alternative B is partially plausible, but Premium Block Blobs accounts still allow configuring public access when enabled on the account. Alternative D represents a common misconception: RBAC permissions control what the user can do, but the Storage Blob Data Contributor role doesn't govern the availability of public access configuration options in the interface.