AZ-104 Implement and Manage Virtual Networking 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 a service endpoint for Microsoft.Storage on the subnet and keep the public endpoint enabled.

  Why it's wrong here

  A service endpoint for Microsoft.Storage merely adds a route from the subnet to Azure's public storage infrastructure; it does not place a private IP for the storage account inside your VNet. Because the storage account's public endpoint remains enabled and DNS still resolves to a public IP, traffic is not fully private and the environment is still exposed to internet-based access attempts. The VM can reach the account, but the solution fails if the requirement is true private connectivity.

  When this WOULD be correct

  If the requirement were to allow a VM in a subnet to access Azure Storage without a public IP, but the storage account could still be accessible from the internet (just restricted to the subnet), then enabling a service endpoint on the subnet would be correct.

• ✓

  Create a private endpoint for the storage account and link the appropriate private DNS zone.

  Why this is correct

  A private endpoint attaches a network interface with a private IP from your VNet to the storage account, causing all traffic destined to that account to traverse the Microsoft backbone instead of the public internet. Linking the private endpoint to the appropriate private DNS zone ensures that the storage account's FQDN resolves to that private IP, so the VM can connect without egress to a public address. This is the correct way to provide secure, private access from a subnet that has no public IP.

• ✗

  Use a SAS token and allow access from any network for the storage account.

  Why it's wrong here

  A SAS token provides time-limited delegated authorization to specific storage resources, but it does not alter the network path; the client still sends requests to the storage account's public endpoint. Allowing access from any network means the storage account remains publicly reachable, making it vulnerable to brute-force or anonymous probing if a token leaks. This option mixes data-plane authorization with network-layer security and is therefore not a valid private access solution.

  When this WOULD be correct

  A question where a client outside Azure (e.g., on-premises) needs temporary, time-limited access to a specific blob in a storage account that is otherwise private, and public internet access is acceptable.

• ✗

  Assign a managed identity to the VM and remove all network restrictions from the storage account.

  Why it's wrong here

  A managed identity replaces stored access keys with Azure AD authentication, so it addresses who can authenticate, not how packets travel to the storage account. Removing network restrictions leaves the storage account's public endpoint open to any IP address, which increases the attack surface even though the identity itself may be narrowly scoped. This option does not put a private IP in the subnet, so it cannot satisfy the need for private network access.

  When this WOULD be correct

  A question where a VM needs to authenticate to Azure Blob Storage without using keys or SAS tokens, and the storage account's network restrictions are not a concern (e.g., the storage account is already isolated via other means).

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question