Implement Azure security →mediumMultiple ChoiceObjective-mapped

AZ-204 Implement Azure security Practice Question

Exhibit

Refer to the exhibit.

{
  "type": "Microsoft.Storage/storageAccounts",
  "apiVersion": "2023-01-01",
  "name": "mystorageaccount",
  "location": "eastus",
  "kind": "StorageV2",
  "sku": {
    "name": "Standard_LRS"
  },
  "properties": {
    "minimumTlsVersion": "TLS1_2",
    "supportsHttpsTrafficOnly": true,
    "networkAcls": {
      "bypass": "AzureServices",
      "defaultAction": "Deny",
      "ipRules": [
        {
          "value": "192.168.1.0/24",
          "action": "Allow"
        }
      ],
      "virtualNetworkRules": []
    }
  }
}

Refer to the exhibit. You deploy an Azure Storage account using the ARM template snippet. A developer reports that they cannot connect to the storage account from their machine with IP 10.0.0.5, even though they have the proper RBAC role. What is the most likely reason?

⚠ Common exam trap

Candidates often assume RBAC roles alone grant access, overlooking that Azure Storage firewalls enforce network-level restrictions that are evaluated before any authorization checks.

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 storage account firewall is configured to deny all traffic except from the 192.168.1.0/24 IP range.

The ARM template snippet configures a network rule that only allows traffic from the 192.168.1.0/24 IP range. Since the developer's machine has IP 10.0.0.5, it falls outside this allowed range, causing the connection to be blocked by the storage account firewall, regardless of RBAC permissions. RBAC controls authorization (who can access), but network rules control access (who can reach the endpoint), and the firewall denies all traffic not explicitly permitted.

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 is configured to bypass Azure Services, which blocks non-Azure clients.
Why it's wrong here
The 'bypass Azure Services' setting within an Azure Storage account's firewall configuration allows specific trusted Microsoft services (e.g., Azure Backup, Azure Site Recovery, Azure Data Factory) to access the storage account, even when the firewall is otherwise configured to restrict network access. This setting does not inherently block non-Azure clients; rather, if a non-Azure client's IP address is not explicitly allowed by an IP rule or Virtual Network rule, it will be blocked by the default deny rule of the firewall, irrespective of the bypass setting.
✗
The developer does not have the Storage Blob Data Contributor role.
Why it's wrong here
The Storage Blob Data Contributor role is an Azure Role-Based Access Control (RBAC) permission that grants authorization to perform data plane operations on blobs, such as reading, writing, and deleting. However, RBAC permissions are evaluated only after a network connection has been successfully established and authenticated. If the storage account's network firewall blocks the initial connection attempt from the developer's IP address, the request never reaches the point where RBAC can be evaluated, leading to a network-level access denial rather than an authorization failure.
✓
The storage account firewall is configured to deny all traffic except from the 192.168.1.0/24 IP range.
Why this is correct
Azure Storage account firewalls operate on a default-deny principle, meaning all network traffic is blocked unless explicitly allowed by a configured rule. If the storage account firewall is configured to permit traffic exclusively from the 192.168.1.0/24 IP range, any connection attempt originating from an IP address outside this specific range will be immediately rejected at the network perimeter. This prevents the developer's client from establishing a connection, as their IP address is not within the allowed subnet, resulting in a network access denied error.
✗
The minimum TLS version is set to TLS 1.2, but the developer's client uses TLS 1.0.
Why it's wrong here
A mismatch in the minimum Transport Layer Security (TLS) version between the client and the storage account would manifest as a TLS handshake failure or a connection reset error during the secure channel negotiation phase. While this would indeed prevent successful communication, it is a distinct issue from a network firewall blocking the initial connection attempt based on IP address. The firewall operates at a lower network layer, preventing the connection from even reaching the point where TLS negotiation can begin.

Quick reference

Access Control Model Comparison

Model	Acronym	Who Controls Access?	Best For
Discretionary Access Control	DAC	Resource owner	Small teams, file shares
Mandatory Access Control	MAC	System / security labels	Classified govt / military
Role-Based Access Control	RBAC	Administrator (via roles)	Enterprise environments
Attribute-Based Access Control	ABAC	Policy engine (user + resource attributes)	Fine-grained, dynamic policies
Rule-Based Access Control	RuBAC	System rules / ACLs	Firewall rules, network ACLs

Go deeper

AZ-204 Implement Azure security Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Access Control Model Comparison

Related to this question