AZ-104 Implement and Manage Storage 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.

• ✓

  Create storage account → Create container → Set access level → Upload blob → Generate SAS

  Why this is correct

  This order is correct because Azure Storage follows a strict hierarchy: the storage account is the top-level resource that provides the global namespace and access keys, so it must be created first. Within that account, a container acts as a logical grouping of blobs and cannot exist outside the account, thus it comes second. Setting the access level on the container before uploading any blobs ensures that the intended permissions (private, blob, or container) are applied consistently from the moment data is placed, avoiding a window where blobs might be exposed with unintended defaults. Finally, uploading the blob into the configured container and then generating a SAS token provides a time-limited, delegated URI that grants the specific permissions you have already enforced at the container level.

• ✗

  Create container → Create storage account → Set access level → Upload blob → Generate SAS

  Why it's wrong here

  This sequence is invalid because a container is a child resource that cannot be provisioned independently; you must have a storage account in place to provide the endpoint (e.g., https://<account>.blob.core.windows.net) and the authentication context required to create the container. Attempting to create a container first will fail with an authentication or resource-not-found error. Even if a container could be pre-created, the access level and blob upload steps would be meaningless without the storage account's service endpoint and key. The correct dependency chain demands that the storage account exists before any container, blob, or SAS token can be created.

• ✗

  Create storage account → Upload blob → Create container → Set access level → Generate SAS

  Why it's wrong here

  This order is wrong because blobs are stored within containers, and a container acts as the partition that holds blob data. Uploading a blob before creating a container is impossible in the Azure Storage REST API—the Put Blob operation requires a valid container path in the URL. Even if you created the container immediately after uploading (which cannot succeed), the access level configuration would be applied too late, as the container's public access setting is evaluated when the blob is uploaded to determine whether the blob is immediately accessible. The correct sequence must establish the container first, then set its access policy, and only then upload blobs so that the policy is in effect from the start.

• ✗

  Create storage account → Create container → Upload blob → Set access level → Generate SAS

  Why it's wrong here

  This is incorrect because setting the access level before uploading the blob is recommended to enforce permissions, but technically you can set it after; however, the standard best practice is to set access before upload.

Go deeper

Related to this question