AZ-104 Implement and Manage Storage Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Enable secure access from a specific VNet: Use service endpoints

  Why this is correct

  Service endpoints are the correct way to enable secure access from a specific VNet because they extend your VNet's private address space to the storage account, creating a direct, optimized route over the Azure backbone. When you enable a service endpoint for Microsoft.Storage on a subnet and add that subnet to the storage account's network rules, traffic from that subnet to the storage account is no longer sent through a public IP, though it still uses the storage account's public endpoint. This provides identity-based and route-based security without exposing the storage account to the entire internet, and it does not require a private IP from your VNet to be assigned to the storage account.

• ✓

  Restrict access to only trusted Microsoft services: Enable trusted services exception

  Why this is correct

  The trusted services exception is the correct mechanism when you need to allow a limited set of Microsoft-managed Azure services to bypass the storage account's default denial of public network access. This exception is controlled by the 'Allow trusted Microsoft services to access this storage account' setting, which permits services like Azure Backup, Azure Site Recovery, Azure Logic Apps, and Azure Data Factory to authenticate using their own managed identities or Azure AD, rather than through shared keys. It is not a blanket grant of access to all Azure services, and it still requires the specific service's request to originate from a Microsoft-owned service context, making it a targeted exception for scenarios like backup vaults or diagnostic logging.

• ✓

  Block all public network access: Disable public network access

  Why this is correct

  Disabling public network access is the definitive way to block all traffic from public endpoints because it tells Azure Storage to reject any connection attempt that does not originate from a private endpoint on your virtual network. When this setting is set to 'Disabled', the storage account no longer accepts requests over its public endpoint (the global or regional DNS name), so internet clients, even those with valid SAS tokens or account keys, cannot reach it. This is a binary, account-wide control and is the strongest option for meeting strict compliance or data isolation requirements, since it eliminates the entire public attack surface rather than merely filtering which source IPs are allowed.

• ✗

  Enable secure access from a specific VNet: Use private endpoints

  Why it's wrong here

  Private endpoints are wrong for secure access from a specific VNet in this context because they create a separate network interface with a private IP address from your VNet, which is meant for scenarios like hybrid or cross-premises connectivity, or when you need to completely remove the storage account from public exposure. Unlike service endpoints, private endpoints require a private endpoint resource and DNS configuration changes (e.g., private DNS zones) to route traffic, and they are not the default, simpler way to secure a single VNet's access to storage. For a requirement that simply says 'enable secure access from a specific VNet,' service endpoints are the more direct and cost-effective solution, while private endpoints are overkill unless you also need to block the public endpoint entirely.

• ✗

  Restrict access to a specific public IP address: Enable trusted services exception

  Why it's wrong here

  Enabling the trusted services exception does not restrict access to a specific public IP address; it instead allows a curated list of first-party Microsoft services to bypass the storage account's IP-based network rules. Each trusted service authenticates with the storage account using its own managed identity or Azure AD, so the source IP is not evaluated as a condition for access. To restrict access from a specific public IP address, you must add that IP (or CIDR range) to the storage account's IP firewall rules, and you should leave the trusted services exception disabled unless you actually need those Microsoft services to reach the storage account—otherwise, you are broadening access beyond the intended IP restriction.

• ✗

  Block all public network access: Use IP firewall rules

  Why it's wrong here

  IP firewall rules are not the correct way to block all public network access because they only allow or deny traffic from a defined set of public IP address ranges or Azure virtual network subnets; they still leave the public endpoint enabled for any request that matches an allowed rule. If you configure only IP rules, any public IP not explicitly denied can potentially reach the storage account if a rule is misconfigured, and the public endpoint remains reachable for those allowed addresses. The correct way to block all public access is to set the 'Public network access' field to 'Disabled', which completely removes the public endpoint from service, whereas IP rules are a finer-grained control for permitting selective public clients while keeping the endpoint available.

Go deeper

Related to this question