Troubleshooting Lab: Configure Azure Storage Firewalls and Virtual Networks
Diagnostic Scenarios
Scenario 1 — Root Cause
A data team configured a Storage Account to accept traffic only from a specific subnet called snet-analytics within the VNet vnet-prod. The configuration was applied via portal and there was no error message during the process.
The environment is as follows:
Storage Account: stprodanalytic01
Region: East US
Replication: LRS
Firewall default action: Deny
Virtual network rules configured: snet-analytics (vnet-prod)
IP rules: none
Exceptions: none enabled
A VM called vm-etl-01, located exactly in the snet-analytics subnet, tries to mount a file share via SMB and receives the following error:
Error 0x800704cf: The network path was not found.
The team confirms that the VM has general internet connectivity, that the VM firewall does not block port 445, and that the Storage Account key is correct. The storage account was created three days ago.
What is the root cause of the problem?
A. Port 445 is blocked in a Network Security Group associated with the snet-analytics subnet, preventing SMB traffic even with the virtual network rule configured.
B. The service endpoint Microsoft.Storage is not enabled on the snet-analytics subnet, causing the VM traffic to not be recognized as originating from the VNet by the Storage Account.
C. LRS replication is not compatible with virtual network rules in recently created Storage Accounts, requiring a propagation period of up to 72 hours.
D. The default action Deny also blocks traffic from subnets configured as rules while the Storage Account is in the initial provisioning state.
Scenario 2 — Action Decision
The cause of an incident has been identified: a production Storage Account is refusing connections from a data ingestion pipeline hosted in Azure Data Factory. Investigation confirmed that the problem is the absence of the Azure Data Factory service in the Allow trusted Microsoft services exceptions list of the Storage Account.
The environment has the following constraints:
- The Storage Account also serves a critical production web application that consumes blobs every 30 seconds
- Firewall exception changes in Storage Accounts can cause a brief network rules reinitialization window, estimated at 5 to 15 seconds
- The operations team has Contributor permission on the Storage Account
- The official maintenance window is at 02:00, in 6 hours
- The ingestion pipeline has been stopped for 40 minutes and is accumulating unprocessed data, but without definitive loss, as the source maintains 7-day retention
What is the correct action to take at this moment?
A. Apply the exception immediately, as the brief rules reinitialization window is acceptable and the pipeline has been stopped long enough to justify the risk.
B. Wait for the maintenance window at 02:00 to apply the exception, as the production web application may be affected by the brief rules reinitialization window.
C. Create a second Storage Account without firewall restrictions, redirect Data Factory to it and migrate data after the maintenance window.
D. Temporarily remove the default action Deny from the Storage Account to allow the pipeline and re-enable it after ingestion is completed.
Scenario 3 — Root Cause
An administrator reports that a Storage Account that was working normally stopped receiving diagnostic logs from Azure Monitor. The administrator inspects the resource and observes the following state:
Storage Account: stlogs-monitor-prod
Firewall: enabled
Default action: Deny
IP rules: 203.0.113.45/32
Virtual network rules: none
Enabled exceptions: Allow storage account key access, Allow blob public access
The administrator also verifies that:
- The diagnostic configuration in Azure Monitor correctly points to
stlogs-monitor-prod - The Storage Account is in the same region as the monitored resources
- The account has available space and has not reached any capacity limit
- The IP
203.0.113.45belongs to the administrator's laptop and was added for testing
What is the root cause of the problem?
A. The IP rule 203.0.113.45/32 is conflicting with Azure Monitor configuration, as explicit IP rules disable diagnostic sending by Azure internal services.
B. The Allow storage account key access option is enabled, which forces Azure Monitor to authenticate via key, a method that is blocked by the firewall when the default action is Deny.
C. The Allow trusted Microsoft services exception is not enabled, preventing Azure Monitor, which is a trusted Microsoft service, from writing diagnostic logs.
D. The Storage Account does not have virtual network rules configured, and Azure Monitor mandatorily requires the source subnet to be registered as a virtual network rule to accept writes.
Scenario 4 — Collateral Impact
An administrator identifies that developers are accessing a production Storage Account directly from the internet using the storage account key, bypassing network policies. To correct this immediately, the administrator enables the Storage Account firewall with default action Deny and does not add any additional rules, exceptions, or virtual network rules.
The developers' improper access is immediately blocked as expected.
What secondary consequence can this action cause?
A. The Storage Account will also start rejecting backups performed by Azure Backup, as the absence of any rule prevents trusted services from being recognized even if the exception was previously enabled.
B. Existing blobs in the Storage Account will be automatically marked as immutable by Azure until at least one access rule is configured, protecting data during the transition.
C. Azure services that depend on this Storage Account and are not covered by the Allow trusted Microsoft services exception, such as Azure Functions on the Consumption plan without VNet integration, will immediately lose access.
D. The default action Deny without configured rules automatically activates Azure Policy audit mode, generating compliance alerts that can block operations on other resources in the same Resource Group.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue is in the problem description itself: the virtual network rule was configured in the Storage Account, but the scenario never mentions that the Microsoft.Storage service endpoint was enabled on the snet-analytics subnet. Without the service endpoint, traffic originated from the VM is not recognized by Azure as VNet traffic; it reaches the Storage Account appearing to be internet traffic, which is blocked by the default action Deny.
The information about port 445 and the VM firewall is relevant to the SMB symptom, but is an irrelevant detail here, as the team already confirmed that port 445 is not blocked on the VM. Alternative A is a distractor that directs diagnosis to the NSG, which is a classic mistake of focusing on the network symptom without verifying the service endpoint prerequisite. Alternatives C and D describe behaviors that don't exist in the platform, but are formulated plausibly enough to attract those who are unsure about replication restrictions or provisioning cycle.
The most dangerous distractor is alternative A: an administrator who would investigate the NSG would waste time and could open unnecessary rules without solving the real problem.
Answer Key — Scenario 2
Answer: B
The critical constraint is the production web application that consumes blobs every 30 seconds. A brief rules reinitialization window, even if 5 to 15 seconds, represents a real risk of interruption for this application. The Data Factory pipeline, on the other hand, is not losing data: the source maintains 7-day retention, and the 40-minute delay is recoverable. The maintenance window exists exactly for situations like this, where the correction is known, but the cost of applying it now exceeds the cost of waiting.
Alternative A represents the technically correct action applied without considering the active production constraint. Alternative C is a valid solution in another context, but is disproportionate and introduces unnecessary complexity for a problem that has a simple solution in the maintenance window. Alternative D is the most dangerous: removing the default action Deny exposes the Storage Account entirely to the internet during the period, which is a much more serious security violation than the pipeline delay.
Answer Key — Scenario 3
Answer: C
The firewall state clearly shows that the only enabled exceptions are Allow storage account key access and Allow blob public access, neither of which covers Azure Monitor. The Allow trusted Microsoft services exception is missing. Azure Monitor is listed as a trusted Microsoft service and depends exactly on this exception to be able to write logs to Storage Accounts with restrictive firewall.
The information about the administrator's laptop IP (203.0.113.45/32) and about available capacity are irrelevant details included purposely. The laptop IP does not interfere with Azure Monitor operation. Alternative A is a distractor that induces wrong diagnosis by suggesting a non-existent interaction between IP rules and internal services behavior. Alternative B confuses the authentication mechanism with the network control mechanism, which are independent layers. Alternative D describes a requirement that doesn't exist: Azure Monitor doesn't need a virtual network rule, it depends on the trusted services exception.
The most common error in this scenario is to focus on present configurations and forget to check what is missing.
Answer Key — Scenario 4
Answer: C
When the firewall is enabled with default action Deny and no exceptions configured, all access paths are blocked, including those of Azure services that depend on the Storage Account. Services like Azure Functions on the Consumption plan, which don't have VNet integration and are not covered by the Allow trusted Microsoft services exception, immediately lose access. This is the direct and expected collateral impact of the described action.
Alternative A is incorrect because the Allow trusted Microsoft services exception is not automatically enabled; it needs to be explicitly configured. If it wasn't enabled before, the administrator's action doesn't remove it. Alternative B describes a behavior that doesn't exist in the platform: Azure doesn't automatically mark blobs as immutable due to firewall changes. Alternative D also describes non-existent behavior: the default action Deny doesn't automatically activate audit modes nor affect other resources in the Resource Group.
The real collateral impact is silent and may not be immediately visible, especially if affected services don't have alerts configured, which makes this consequence particularly critical in production environments.
Troubleshooting Tree: Configure Azure Storage Firewalls and Virtual Networks
Legend
| Color | Meaning |
|---|---|
| Dark Blue | Initial symptom, entry point |
| Blue | Diagnostic question, decision node |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification before confirming cause |
To use this tree when facing a real problem, start at the root node by identifying that Storage Account access is being denied with the firewall active. Follow each diagnostic question by answering yes or no based on what you can directly observe in the portal or via CLI. The intermediate verification nodes in orange indicate points where it's necessary to confirm a detail before concluding the cause. When you reach a red node, the cause is identified; the immediately associated green node indicates the corresponding corrective action.