AZ-104 Implement and Manage Virtual Networking Practice Question
Two VNets are peered successfully, and a VM in the spoke can reach a private endpoint in the hub by IP address. However, the VM cannot resolve the storage account name to the private endpoint FQDN. The private DNS zone is linked only to the hub VNet. What should the administrator do?
⚠ Common exam trap
Many exam-takers assume that VNet peering automatically extends DNS resolution for private endpoints, but in reality, each VNet must be explicitly linked to the private DNS zone for name resolution to work across the peering.
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
✓
Link the private DNS zone to the spoke VNet as well.
The VM can reach the private endpoint by IP, confirming that network connectivity (peering and routing) is working. However, name resolution fails because the private DNS zone, which contains the private endpoint FQDN mapping, is linked only to the hub VNet. By linking the private DNS zone to the spoke VNet (option B), the spoke VMs will use Azure-provided DNS to resolve the storage account name to the private IP, enabling seamless name resolution across the peered VNets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a route table to the spoke subnet pointing to the private endpoint IP.
Why it's wrong here
A route table controls the next hop for outbound traffic, but this issue is not about routing. The VM already successfully reaches the storage account by IP; the failure is that the storage account's FQDN does not resolve to the private endpoint's IP address because the private DNS zone is not linked to the spoke VNet. Adding a route entry to the spoke subnet would not alter how DNS name resolution works or supply the VM with the private IP record. In fact, the private endpoint's /32 route is already propagated through the VNet peering, so a route table is redundant and would not address the root cause.
When this WOULD be correct
A route table would be correct if the VM could not reach the private endpoint by IP due to asymmetric routing or missing routes, such as when the private endpoint is in a different VNet without proper peering or when using forced tunneling.
- ✓
Link the private DNS zone to the spoke VNet as well.
Why this is correct
Private DNS zones must be linked to every VNet that needs to resolve the private endpoint name through Azure-provided DNS behavior. Since the spoke VNet is not linked to the zone, its VM does not receive the private endpoint record and cannot resolve the storage account FQDN correctly. Linking the zone to the spoke VNet allows name resolution to return the private IP.
- ✗
Enable gateway transit on the peering connection.
Why it's wrong here
Enabling gateway transit on a VNet peering connection allows the peered VNet to use a VPN or ExpressRoute gateway located in the hub for connectivity to on-premises networks; it does not influence DNS zone configuration or the distribution of private endpoint DNS records. The private DNS zone was linked only to the hub VNet, and gateway transit has nothing to do with creating a link to the spoke VNet. The VM in the spoke can still reach the storage account by private IP over peering, but its DNS queries are answered by the Azure-provided resolver using the linked zones—and since the spoke lacks a link, the FQDN resolves to the public IP, if at all. Thus, gateway transit is irrelevant to resolving this name-resolution failure.
When this WOULD be correct
An administrator needs to enable connectivity from a spoke VNet to on-premises resources via the hub's VPN gateway. The hub has a VPN gateway configured, and the spoke VNet must use it to reach on-premises networks. Enabling 'Use remote gateways' on the spoke peering and 'Allow gateway transit' on the hub peering would be the correct solution.
- ✗
Create an NSG rule to allow DNS traffic to the storage account.
Why it's wrong here
NSG rules filter network traffic between Azure resources and do not control DNS resolution or the content of DNS zone records. The storage account's private endpoint is not a DNS server, so allowing DNS traffic to it would not cause the storage account FQDN to resolve to the private IP—the VM's DNS queries are sent to the Azure recursive resolver (168.63.129.16) or the VNet's configured DNS servers, not to the storage account. Furthermore, the VM already has IP-level connectivity to the storage account; the problem is purely that the DNS name is not resolving to that private IP. Adding an NSG rule for DNS to the storage account is therefore technically meaningless and would not fix the missing DNS zone link.
When this WOULD be correct
This option would be correct in a scenario where a VM cannot connect to a storage account via private endpoint because the NSG on the subnet is blocking outbound traffic to the private endpoint IP address on the required port (e.g., 443 for HTTPS). Adding an NSG rule to allow that traffic would resolve the connectivity issue.
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.
✓Link the private DNS zone to the spoke VNet as well.Correct answer▾
Why this is correct
Private DNS zones must be linked to every VNet that needs to resolve the private endpoint name through Azure-provided DNS behavior. Since the spoke VNet is not linked to the zone, its VM does not receive the private endpoint record and cannot resolve the storage account FQDN correctly. Linking the zone to the spoke VNet allows name resolution to return the private IP.
✗Add a route table to the spoke subnet pointing to the private endpoint IP.Wrong answer — click to see why▾
Why this is wrong here
The issue is DNS resolution, not routing. The VM can already reach the private endpoint by IP, so adding a route table does not help resolve the storage account name to the private endpoint FQDN.
★ When this WOULD be the correct answer
A route table would be correct if the VM could not reach the private endpoint by IP due to asymmetric routing or missing routes, such as when the private endpoint is in a different VNet without proper peering or when using forced tunneling.
Why candidates choose this
Candidates may confuse network connectivity issues with DNS resolution, assuming that if the VM cannot resolve the name, a route is needed to direct traffic to the private endpoint.
✗Enable gateway transit on the peering connection.Wrong answer — click to see why▾
Why this is wrong here
Gateway transit is used to allow a peered VNet to use the hub's VPN/ExpressRoute gateway for connectivity to on-premises networks, not for DNS resolution of private endpoints. The issue here is DNS resolution, not routing or gateway access.
★ When this WOULD be the correct answer
An administrator needs to enable connectivity from a spoke VNet to on-premises resources via the hub's VPN gateway. The hub has a VPN gateway configured, and the spoke VNet must use it to reach on-premises networks. Enabling 'Use remote gateways' on the spoke peering and 'Allow gateway transit' on the hub peering would be the correct solution.
Why candidates choose this
Candidates may confuse the need for routing traffic to the private endpoint with the need for DNS resolution, or mistakenly think that enabling gateway transit will also forward DNS queries to the hub's DNS servers.
✗Create an NSG rule to allow DNS traffic to the storage account.Wrong answer — click to see why▾
Why this is wrong here
The issue is DNS resolution, not network traffic. The VM can already reach the private endpoint by IP, so NSG rules for DNS traffic are irrelevant because DNS queries are sent to the Azure-provided DNS (168.63.129.16) or a custom DNS server, not to the storage account's IP.
★ When this WOULD be the correct answer
This option would be correct in a scenario where a VM cannot connect to a storage account via private endpoint because the NSG on the subnet is blocking outbound traffic to the private endpoint IP address on the required port (e.g., 443 for HTTPS). Adding an NSG rule to allow that traffic would resolve the connectivity issue.
Why candidates choose this
Candidates may think that DNS resolution failure is due to traffic being blocked by NSGs, confusing network connectivity issues with DNS resolution issues. They might assume that allowing DNS traffic to the storage account's IP would enable name resolution.
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?”
Visual reference
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
IP address
An IP address is a unique numerical label assigned to each device connected to a computer network that uses the Internet Protocol for communication.
Key term
VNet
A virtual private network inside a cloud provider that lets you securely connect and isolate your cloud resources.
About these practice questions
One of 1,049 original AZ-104 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.