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.

• ✗

  Create a second private endpoint in VNet-B for the same storage account.

  Why it's wrong here

  A second private endpoint in VNet-B would create a new private IP for the storage account, but it does not address the root cause: VNet-B cannot resolve the FQDN to any private IP because the private DNS zone is not linked. The existing private endpoint in VNet-A is already reachable across the peering; the only missing piece is DNS linkage. Adding another endpoint would require new DNS records and unnecessary cost, without fixing the resolution failure for the peered VNet.

  When this WOULD be correct

  This option would be correct if the storage account needed to be accessed from VNet-B with a separate private IP (e.g., for isolation or compliance) and the private DNS zone was already linked to both VNets. For example, if each VNet required its own private endpoint for the same storage account to enforce network policies.

• ✗

  Enable a service endpoint on VNet-B and remove the private endpoint.

  Why it's wrong here

  Enabling a service endpoint on VNet-B does not assign a private IP to the storage account; it merely allows traffic to the service's public IP over the Azure backbone. Removing the private endpoint deletes the private IP address and invalidates the existing private DNS records, making the DNS issue worse. Service endpoints also do not change name resolution behavior—the FQDN still resolves to the public IP, so the connectivity model is not preserved.

  When this WOULD be correct

  If the requirement was to access the storage account from VNet-B using the public endpoint but with source IP restricted to VNet-B's subnet, and private endpoint was not needed, then enabling a service endpoint on VNet-B and removing the private endpoint would be correct.

• ✗

  Add a user-defined route in VNet-B that points the storage FQDN to the private IP.

  Why it's wrong here

  A user-defined route (UDR) is applied only after DNS resolution occurs, because routing decisions are based on the destination IP address prefix. It cannot intercept or rewrite DNS queries, so the storage FQDN would still resolve to its public endpoint unless the private DNS zone is linked. Even adding a /32 route for the private endpoint IP would not help because the client never learns that IP from hostname lookup.

  When this WOULD be correct

  A UDR would be correct if the VM could already resolve the storage account to the private IP (e.g., via a custom DNS server), but traffic was still going over the internet due to asymmetric routing or missing effective routes. The UDR would force traffic to the private endpoint IP.

• ✓

  Create a virtual network link from the private DNS zone to VNet-B.

  Why this is correct

  Private endpoint access depends on correct DNS resolution to the private endpoint IP. Because the private DNS zone is linked only to VNet-A, VNet-B does not receive the private name mapping. Linking the zone to VNet-B allows resources in the peered VNet to resolve the blob endpoint name to the private IP as intended.

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

Same concept, more angles

3 more ways this is tested on AZ-104

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.