Troubleshooting Lab: Create and configure a container in Azure Blob Storage
Diagnostic Scenarios
Scenario 1 — Root Cause
A data team published a container called datasets in a general-purpose v2 storage account. The container was configured with public access set to Blob. Data scientists confirm they can upload and download normally using account keys.
However, an external partner reports that when trying to access a blob directly via the public URL, they receive the following error:
HTTP 409 - PublicAccessNotPermitted
The public access is not permitted on this storage account.
The team verifies the container and confirms that the access level is correctly set to Blob. The storage account was created three weeks ago. The partner is accessing from outside the corporate network, without VPN. The account has no firewall rules configured. The account SKU is Standard_LRS.
What is the root cause of the error received by the external partner?
A) The Blob access level doesn't allow direct URL access without authentication; it's necessary to use Container
B) The "Allow Blob public access" option is disabled at the storage account level
C) The absence of firewall rules prevents requests coming from outside the corporate network
D) The Standard_LRS SKU doesn't support public blob access; it's necessary to use Standard_GRS
Scenario 2 — Action Decision
A company's security team identified the cause of an incident: a container called backups was mistakenly created with Container public access, exposing backup file names and metadata to any anonymous user on the internet. The cause is confirmed and documented.
The container is in active production. An internal application uploads new backups every 15 minutes using a Shared Access Signature (SAS) with write permissions. A second application reads the backups using the account access key. The security manager demands immediate correction.
What is the correct action to take at this moment?
A) Delete and recreate the container with Private access, since changing access on an existing container is not supported by Azure
B) Change the container access level from Container to Private directly in the container properties, without interrupting applications
C) Immediately revoke all active SAS and regenerate account keys before changing the container access
D) Disable the "Allow Blob public access" option in the storage account and then change the container to Private
Scenario 3 — Root Cause
A developer executes the following command to create a container and immediately tries to verify its existence:
az storage container create \
--name relatorios \
--account-name corpstorageeast \
--auth-mode login
az storage container show \
--name relatorios \
--account-name corpstorageeast \
--auth-mode login
The second command returns:
(AuthorizationPermissionMismatch) This request is not authorized to perform
this operation using this permission.
RequestId: 4f8a1c23-...
Time: 2026-03-26T10:14:32.0000000Z
The developer confirms they are authenticated via az login with their corporate account. The storage account exists and is accessible. The resource group is in the East US region. The storage account has no firewall enabled. The relatorios container was successfully created, as confirmed by the first command's return.
What is the root cause of the second command's failure?
A) The --auth-mode login parameter is not compatible with the show command; it's necessary to use --auth-mode key
B) The authenticated user doesn't have an RBAC role assignment in the data plane that authorizes the container metadata read operation
C) There's a replication delay between regions that prevents immediate reading after container creation
D) The name relatorios contains characters outside the ASCII standard and causes authentication failure in the second command
Scenario 4 — Collateral Impact
An administrator identifies that the storage account corpdata01 has the "Allow Blob public access" option enabled and that several containers were created with Blob or Container access over time. To remediate the exposure risk, the administrator disables the "Allow Blob public access" option directly in the storage account settings.
The action resolves the exposure problem immediately.
What secondary consequence can this action cause?
A) Existing containers with Blob or Container access will have their metadata automatically changed to Private in Azure's internal database
B) Applications that depend on public blob URLs to function correctly will start receiving authorization errors, without any configuration of these applications having been changed
C) Regeneration of account access keys will be automatically required by Azure as a complementary security measure
D) All existing blobs will be moved to the Archive tier as additional protection against unauthorized access
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the error code: PublicAccessNotPermitted. This specific error doesn't indicate a network problem or container access level issue; it indicates that the storage account has public access blocked at the account level. When the "Allow Blob public access" configuration is disabled in the account, Azure rejects any anonymous request regardless of what's configured in individual containers.
The information about absence of firewall rules is irrelevant and was purposefully included to divert reasoning toward alternative C. A blocked firewall would result in a network connectivity error, not the 409 - PublicAccessNotPermitted code. The Standard_LRS SKU (alternative D) has no relation to public access support. Alternative A is wrong because the Blob level is exactly the appropriate level for anonymous direct URL access without listing.
The most dangerous distractor is C, since the absence of firewall seems to be a relevant clue, but the 409 error code eliminates this hypothesis before any other investigation.
Answer Key — Scenario 2
Answer: B
The public access level of an existing container can be changed directly, without needing to recreate the container. Changing from Container to Private doesn't interrupt applications that use SAS or access key, since these authentication forms operate in the data plane independently of anonymous access control.
Alternative A is factually incorrect: Azure allows changing the access level of existing containers. Alternative C ignores the urgency constraint and would cause immediate interruption of both production applications before any actual problem correction. Alternative D is technically valid as a broader security measure, but goes beyond what's necessary at this moment and could have side effects on other containers in the same account that depend on legitimate public access. Given that the cause is confirmed and the correction is surgical and non-disruptive, alternative B is the correct action.
The most dangerous distractor is D, as it seems to be a more secure solution, but potentially interferes with other account services without that having been evaluated.
Answer Key — Scenario 3
Answer: B
When --auth-mode login is used, Azure CLI delegates authorization to the data plane via RBAC, not via key. To execute az storage container show, the user needs a role that grants read permission in the Blob Storage data plane, such as Storage Blob Data Reader or higher. Without this assignment, Azure returns AuthorizationPermissionMismatch even if the user created the container, because creation may have been authorized by a management plane role that doesn't extend to the data plane.
The information about East US location and absence of firewall is irrelevant. Replication delay (alternative C) doesn't apply here because the account uses Standard_LRS, which is locally redundant without cross-region replication. Alternative D is incorrect because relatorios contains only valid ASCII characters for container names. Alternative A is wrong because --auth-mode login is compatible with show; the problem is permission, not parameter compatibility.
The most common reasoning error in this scenario is concluding that the first command worked because the user has sufficient permission for everything, without realizing that creating and reading in the data plane are distinct permissions in RBAC.
Answer Key — Scenario 4
Answer: B
Disabling "Allow Blob public access" in the account immediately blocks all anonymous requests to any container in the account, regardless of the access level configured in each container. Applications that use public blob URLs to display images, serve static files, or integrate with external services will start receiving authorization errors without any configuration of these applications having been modified. The impact is silent from the applications' perspective: they weren't changed, but stop working.
Alternative A is wrong: Azure doesn't automatically change the configuration metadata of containers; they continue to be registered as Blob or Container, but the practical effect is blocked by the account. Alternative C is incorrect because key regeneration isn't automatically triggered by this configuration. Alternative D is incorrect because no storage tier movement occurs in response to public access configuration changes.
Troubleshooting Tree: Create and configure a container in Azure Blob Storage
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start at the root node and answer each question based on what you observe directly in the environment: the type of error returned, the authentication method in use, and the configurations visible in the portal or via CLI. Follow the path corresponding to your answer at each fork until you reach a red node with the identified cause, then proceed to the green node with the recommended action. If after applying the correction the problem persists, return to the orange validation node and traverse the tree again with the new information available.