Troubleshooting Lab: Create and Configure Storage Accounts
Diagnostic Scenarios
Scenario 1 — Root Cause
An operations team reports that a web application hosted on an Azure VM started receiving errors when trying to write files to a storage account. The application was working normally until yesterday.
The administrator checks the following in the portal:
- The storage account is in East US region, type StorageV2, SKU Standard_LRS
- The VM is in the same region and in the
snet-appsubnet of thevnet-prodVNet - The storage account firewall is configured to deny all public access
- The
snet-appsubnet is listed in the storage account's virtual network rules - Blob versioning was enabled yesterday afternoon by the security team
Application logs show:
[ERROR] StorageException: This request is not authorized to perform this operation.
Status: 403 Forbidden
RequestId: 7e3a1b92-...
Time: 2026-03-26T14:33:01Z
The administrator also confirms that the service account used by the application has the Storage Blob Data Contributor role assigned correctly.
What is the root cause of the 403 error?
A) The Storage Blob Data Contributor role is insufficient to write to a storage account with firewall enabled
B) Blob versioning enabled yesterday changed the write behavior and requires additional permissions
C) The Service Endpoint for Microsoft.Storage is not enabled on the snet-app subnet, making the VNet rule inoperative
D) The Standard_LRS SKU is not compatible with virtual network rules when public access is disabled
Scenario 2 — Action Decision
The cause of the problem was identified: a critical production storage account has its redundancy configuration changed from GRS to LRS by mistake, exposing data to loss risk in case of regional failure. The change was made 15 minutes ago by an administrator who operated on the wrong subscription.
The environment has the following constraints:
- The storage account is active and being used by two production applications at this moment
- No maintenance window is scheduled for today
- Replication to the secondary region was already stopped when changed to LRS
- The responsible administrator has the Contributor role on the subscription
What is the correct action to take at this moment?
A) Create a new storage account with GRS, copy data via AzCopy and redirect applications after copying
B) Change the redundancy back to GRS directly in the storage account settings, without needing to interrupt applications
C) Start a manual failover to the secondary region to restore geographic redundancy immediately
D) Open a support ticket with Microsoft to restore the previous state of the storage account before taking any action
Scenario 3 — Root Cause
A developer created a storage account and a container called uploads with anonymous access configured as Blob at the container level. They try to access a blob via direct URL in the browser and receive the following error:
<Error>
<Code>PublicAccessNotPermitted</Code>
<Message>Public access is not permitted on this storage account.</Message>
<RequestId>a91f2c03-...</RequestId>
</Error>
The developer checks the container in the portal and confirms that the Anonymous access level option is set to Blob. They also confirm that the storage account was created two hours ago with default portal settings, without additional manual modifications.
Other information collected:
- The storage account is type StorageV2
- The SKU is Standard_GRS
- No Azure Policy was identified as applicable in the resource group
- The security team enabled Microsoft Defender for Storage on the subscription yesterday
What is the root cause of the error?
A) The Standard_GRS SKU blocks anonymous access to blobs because it replicates data to a second region
B) Microsoft Defender for Storage automatically blocks anonymous access when activated on the subscription
C) The Azure portal now creates storage accounts with public access blocked by default at the account level, and this setting was not changed
D) Anonymous access type Blob only works when the container is created before the storage account is fully provisioned
Scenario 4 — Diagnostic Sequence
An administrator receives an alert indicating that an application cannot access files in a storage account configured with firewall and virtual network rules. Access was functional until the previous day.
The available investigation steps are:
- Check if the Service Endpoint for
Microsoft.Storageis enabled on the application's subnet - Confirm if the application's IP address or subnet is listed in the storage account firewall's allowed rules
- Test access using Storage Explorer with administrator credentials to isolate whether the problem is network or permission related
- Check if there were recent changes to the storage account's network settings or subnet
- Confirm if the storage account still exists and is in Available state in the portal
What is the correct diagnostic sequence?
A) 5 → 4 → 1 → 2 → 3
B) 3 → 5 → 4 → 1 → 2
C) 1 → 2 → 5 → 3 → 4
D) 4 → 5 → 2 → 1 → 3
Answer Key and Explanations
Answer Key — Scenario 1
Answer: C
The decisive clue is in the combination of two facts: the storage account firewall denies all public access, and the snet-app subnet is listed in the VNet rules. This pair of configurations seems sufficient, but it's not. For Azure to recognize traffic from a subnet as originating from within the VNet, the Service Endpoint for Microsoft.Storage must be enabled on that subnet. Without it, traffic reaches the storage account as if it were public traffic, and the firewall blocks it.
The irrelevant information in this scenario is the blob versioning enablement. It was deliberately included to induce the reader to associate the recent change with the problem. Blob versioning affects blob overwrite behavior but has no relation to authentication or access authorization.
The distractors represent two common reasoning errors: confusing the RBAC role with the network layer (alternative A) and attributing the problem to the last visible change in the environment, even without causal relationship (alternative B). Alternative D is technically false and serves as a basic knowledge filter.
The most dangerous distractor is B: an administrator who blames versioning might spend hours investigating a harmless change while the real problem remains active.
Answer Key — Scenario 2
Answer: B
The redundancy change from LRS back to GRS can be done directly in the storage account settings without interrupting running applications. Azure allows changing the redundancy level of an existing storage account, and the operation doesn't cause downtime or require account recreation.
The critical constraint in the scenario is that applications are in production and active. This eliminates any approach requiring service interruption or data migration. Alternative A would be valid in a context where the storage account needed to be moved between regions or had restrictions preventing in-place changes, but here it would be slow, risky, and unnecessary. Alternative C is a serious error: manual failover is irreversible and permanently moves the account to the secondary region, the opposite of what's wanted here. Alternative D wastes time and isn't necessary for an operation the administrator can perform directly.
Answer Key — Scenario 3
Answer: C
The key is in the phrase "created with default portal settings". Microsoft changed the default behavior of the portal and API to create storage accounts with the allowBlobPublicAccess property set to false. This means that even if the container has anonymous access configured at the container level, public access is blocked at the account level before any container-level verification.
The deliberate irrelevant information is Microsoft Defender for Storage. It provides alerts and threat detection but doesn't change public access settings or directly block requests. Including it in the statement exploits the tendency to associate "enhanced security yesterday" with today's problem.
The most dangerous distractor is B: a reader unfamiliar with Defender for Storage's actual behavior might spend time trying to disable it or create exceptions, with no effect on the real problem. The cause is a default configuration of the account itself, and the solution is to explicitly enable public access at the account level before configuring containers.
Answer Key — Scenario 4
Answer: A
The correct sequence follows progressive diagnostic logic: from simplest and most comprehensive to most specific.
Step 5 first: confirming the storage account exists and is available eliminates the most basic hypothesis before any network investigation.
Step 4 next: checking recent changes is fundamental because access was functional the previous day. A recent change is the most likely cause and should be identified early.
Step 1 then: checking the Service Endpoint on the subnet is the technical prerequisite for VNet rules to work.
Step 2 in sequence: confirming if the subnet or IP is listed in firewall rules validates the specific configuration.
Step 3 last: using Storage Explorer with elevated credentials tests access in isolation and confirms whether the problem is network-related or of another nature, serving as final validation.
Alternative B makes the error of starting with practical testing before checking the resource's basic state. Alternative C completely ignores checking recent changes, which is the most relevant clue given the context. Alternative D starts with recent changes but skips account existence verification and mixes the order of network steps without progressive logic.
Troubleshooting Tree: Create and Configure Storage Accounts
Color Legend:
| Color | Node Type |
|---|---|
| Dark Blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Orange | Intermediate validation or check |
| Red | Identified cause |
| Green | Recommended action or resolution |
When facing a real problem, start at the root node and answer each question based on what's observable in the portal or via CLI. Each branch eliminates a class of hypotheses. When you reach a red node, the cause is identified; the corresponding green node indicates the corrective action. If the path taken doesn't lead to resolution, return to the previous node and reevaluate the diagnostic question response based on additional evidence.