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.

• ✗

  A network security group on the subnet.

  Why it's wrong here

  A network security group on the subnet filters traffic by IP address, port, and protocol, but it does not participate in DNS name resolution. NSGs can control whether traffic is allowed to reach the private endpoint's IP, yet they cannot translate the storage account's FQDN into that IP. Even with the most permissive NSG rules, a client must first resolve the name through DNS, and no NSG rule can create or modify DNS records. Therefore, an NSG is irrelevant to the reported name-resolution failure.

  When this WOULD be correct

  You need to restrict inbound traffic to a subnet hosting a private endpoint, allowing only specific sources. An NSG on that subnet would filter traffic to the private endpoint's network interface.

• ✓

  A private DNS zone linked to VNet-App.

  Why this is correct

  A private DNS zone linked to VNet-App is required for correct name resolution. When you create a private endpoint, the storage account's FQDN must resolve to the assigned private IP instead of the public endpoint. Linking a private DNS zone—such as privatelink.blob.core.windows.net for Blob Storage—to VNet-App and creating an A record for the private endpoint enables clients in that virtual network to resolve the storage name to the private address. Without this DNS zone, name resolution will still return the public IP, breaking connectivity through the private endpoint.

• ✗

  A public DNS zone for the storage account name.

  Why it's wrong here

  A public DNS zone for the storage account name cannot resolve within VNet-App. You do not own the existing Azure domain (e.g., blob.core.windows.net), so you cannot create an authoritative public zone for that namespace. More importantly, a public DNS zone is queried by external clients and would return the storage account's public IP address, not the private endpoint address. To enable private endpoint resolution, the private DNS zone must be linked to the virtual network; a public zone has no effect on VNet DNS resolution.

  When this WOULD be correct

  You need to create a custom domain name for an Azure Storage account that is accessible from the internet, and you want to use Azure DNS to manage the DNS records for that custom domain. In that case, you would configure a public DNS zone.

• ✗

  A user-defined route table on the subnet.

  Why it's wrong here

  A user-defined route table on the subnet affects the routing path of IP packets by defining next hops for destination prefixes, but it has no mechanism for DNS resolution. Route tables operate at Layer 3, forwarding already-addressed packets, and cannot map a hostname to an IP address. Even if routing directs traffic correctly toward the private endpoint's IP, the client must still know that IP through name resolution. A route table cannot supply the DNS mapping required to reach the storage account via its hostname, so it does not fix the underlying issue.

  When this WOULD be correct

  In a scenario where you need to force traffic from a subnet to go through a network virtual appliance (NVA) for inspection or to a specific next hop, you would configure a user-defined route table. For example, to route all outbound traffic from a subnet through a firewall.

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