Design infrastructure solutions →mediumMultiple Choice

AZ-305 Design infrastructure solutions Practice Question

Exhibit

{
  "properties": {
    "sku": {
      "name": "Standard_GRS"
    },
    "kind": "StorageV2",
    "accessTier": "Hot",
    "supportsHttpsTrafficOnly": true,
    "networkRuleSet": {
      "defaultAction": "Deny",
      "virtualNetworkRules": [
        {
          "id": "/subscriptions/.../subnets/subnet-a",
          "action": "Allow"
        }
      ]
    }
  }
}

Refer to the exhibit. You have an Azure Storage account with the settings shown. A developer reports that they cannot access the storage account from their Azure VM that is connected to subnet-a. The VM's subnet ID matches the one in the rule. What is the most likely cause of the issue?

⚠ Common exam trap

Many candidates assume adding a subnet rule in the storage account firewall is sufficient, but they overlook the prerequisite of enabling the Microsoft.Storage service endpoint on the subnet, which is a critical step for the rule to take effect.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The subnet does not have a service endpoint for Microsoft.Storage enabled

The most likely cause is that the subnet does not have a service endpoint for Microsoft.Storage enabled. When a storage account firewall rule allows access from a specific subnet, that subnet must have a service endpoint configured for Microsoft.Storage; otherwise, traffic from the VM is treated as originating from the VM's public IP and is blocked by the firewall. The exhibit shows a firewall rule for the subnet, but without the service endpoint, the rule is ineffective.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The storage account requires HTTPS and the VM is using HTTP
Why it's wrong here
Although the storage account has `supportsHttpsTrafficOnly` set to true and the VM would need to use HTTPS, an HTTP request would be rejected with an HTTP 400-level protocol error, not a network-layer connectivity/timeout failure. More importantly, even if the VM switched to HTTPS, it would still fail because the missing service endpoint on the subnet would prevent the storage account's virtual network rule from matching the traffic. Therefore, the protocol mismatch is not the root cause of the problem.
✗
The storage account does not have a firewall rule for the VM's public IP
Why it's wrong here
The storage account's network rule is configured to allow the virtual network or subnet, not a public IP address. If the subnet had a service endpoint enabled, Azure would rewrite the source IP to the VM's private IP, making the public IP rule unnecessary. The absence of a public IP firewall rule is irrelevant because the VM's traffic should be coming from the virtual network, not the public internet. Adding a public IP rule would expose the storage account to the internet and still would not fix the missing service endpoint.
✓
The subnet does not have a service endpoint for Microsoft.Storage enabled
Why this is correct
Azure Storage virtual network rules are only effective when the client subnet has a service endpoint for `Microsoft.Storage` enabled. Without that service endpoint, the VM's outbound traffic to the storage account is source-NATed to its public IP, so the storage account sees a public internet address and the configured virtual network rule does not match. Enabling the service endpoint on the subnet is required to route traffic over the Azure backbone and present the VM's private IP to the storage account. This missing configuration is the direct cause of the connectivity failure described.
✗
The storage account uses GRS replication which is not supported with network rules
Why it's wrong here
Geo-redundant storage (GRS) replicates data asynchronously to a paired region, and replication happens entirely within Azure's infrastructure. Network rules such as service endpoints and virtual network firewall rules are evaluated only on client requests to the storage account's public endpoint; the internal replication traffic is not subject to these rules. Changing the replication type would not affect the subnet's lack of a service endpoint, so GRS is not the reason for the denial.

Visual reference

Go deeper

AZ-305 Design infrastructure solutions Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question