How to Resolve Private Endpoint FQDN Across Peered VNets
Two VNets are peered. AppVNet contains VMs that access a private endpoint in DataVNet successfully by IP, but name resolution fails for the storage FQDN. The private DNS zone is linked only to DataVNet. What should you do?
Quick Answer
The answer is to add a virtual network link from the private DNS zone to AppVNet. This is required because a private DNS zone is scoped only to the VNets it is explicitly linked to, and VNet peering does not automatically propagate DNS resolution—it only provides IP connectivity. Even though the VMs in AppVNet can reach the private endpoint by IP across the peering, they cannot resolve the storage FQDN because the DNS zone is not accessible from AppVNet. On the AZ-104 exam, this scenario tests your understanding of how private DNS zones integrate with VNet peering and private endpoints; a common trap is assuming peering alone enables name resolution. Remember: peering handles the route, but the link handles the lookup. A helpful memory tip is “Link to think”—if you want a peered VNet to resolve a private endpoint’s FQDN, you must link the private DNS zone to that VNet.
⚠ Common exam trap
Many exam-takers assume VNet peering automatically extends DNS resolution for private endpoints, but peering only provides IP connectivity—DNS resolution requires explicit virtual network links to the private DNS zone.
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
✓
Add a virtual network link from the private DNS zone to AppVNet.
The private DNS zone is linked only to DataVNet, so VMs in AppVNet cannot resolve the storage FQDN even though IP connectivity works via the VNet peering. By adding a virtual network link from the private DNS zone to AppVNet, you enable DNS resolution for the private endpoint's FQDN across the peered VNet. This is required because private DNS zones are scoped to the VNets they are linked to, and peering alone does not propagate DNS resolution.
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 another peering connection from AppVNet to DataVNet.
Why it's wrong here
Peering already exists, and peering does not automatically extend private DNS zone visibility across VNets.
When this WOULD be correct
This option would be correct if the VNets were not already peered and you needed to enable connectivity between them to access resources in DataVNet from AppVNet.
- ✓
Add a virtual network link from the private DNS zone to AppVNet.
Why this is correct
Private endpoint name resolution depends on the private DNS zone being linked to the VNet where the clients reside. Because AppVNet is not linked to the zone, its VMs cannot resolve the private endpoint FQDN even though IP connectivity exists. Adding a virtual network link from the private DNS zone to AppVNet makes the private records available to those clients.
- ✗
Create a public DNS zone with the same name as the private zone.
Why it's wrong here
A public DNS zone does not provide private endpoint resolution and can create conflicting records instead of fixing the lookup problem.
When this WOULD be correct
This option would be correct if the question stated that the storage account's FQDN needs to be resolved from the internet, and the private endpoint is not required. For example, if a VM in AppVNet needs to access the storage account over the public internet, creating a public DNS zone with the same name would allow public name resolution.
- ✗
Assign a public IP address to the private endpoint.
Why it's wrong here
Private endpoints are intended to use private addresses. Adding a public IP defeats the purpose and does not solve the DNS zone linkage issue.
When this WOULD be correct
If the question stated that the private endpoint needs to be accessible from the internet while still using a private IP for internal traffic, assigning a public IP to the private endpoint would be correct.
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.
✓Add a virtual network link from the private DNS zone to AppVNet.Correct answer▾
Why this is correct
Private endpoint name resolution depends on the private DNS zone being linked to the VNet where the clients reside. Because AppVNet is not linked to the zone, its VMs cannot resolve the private endpoint FQDN even though IP connectivity exists. Adding a virtual network link from the private DNS zone to AppVNet makes the private records available to those clients.
✗Create another peering connection from AppVNet to DataVNet.Wrong answer — click to see why▾
Why this is wrong here
The VNets are already peered, so creating another peering connection does not resolve DNS resolution issues. The problem is that the private DNS zone is not linked to AppVNet, not a lack of network connectivity.
★ When this WOULD be the correct answer
This option would be correct if the VNets were not already peered and you needed to enable connectivity between them to access resources in DataVNet from AppVNet.
Why candidates choose this
Candidates may think that name resolution failures are due to network connectivity issues and assume that adding another peering will fix it, overlooking the DNS configuration.
✗Create a public DNS zone with the same name as the private zone.Wrong answer — click to see why▾
Why this is wrong here
Creating a public DNS zone with the same name as the private zone would not resolve the private endpoint's FQDN for VMs in AppVNet because public DNS zones are used for internet-facing resolution, not for private IP addresses. The private DNS zone must be linked to AppVNet to enable name resolution across the VNet peering.
★ When this WOULD be the correct answer
This option would be correct if the question stated that the storage account's FQDN needs to be resolved from the internet, and the private endpoint is not required. For example, if a VM in AppVNet needs to access the storage account over the public internet, creating a public DNS zone with the same name would allow public name resolution.
Why candidates choose this
Candidates may think that creating a public DNS zone with the same name will override the private zone or provide a fallback for resolution, not realizing that private DNS zones take precedence within linked VNets and that public zones are irrelevant for private endpoint resolution.
✗Assign a public IP address to the private endpoint.Wrong answer — click to see why▾
Why this is wrong here
Assigning a public IP to the private endpoint would expose it to the internet, defeating the purpose of private connectivity and not resolving name resolution issues within the peered VNets.
★ When this WOULD be the correct answer
If the question stated that the private endpoint needs to be accessible from the internet while still using a private IP for internal traffic, assigning a public IP to the private endpoint would be correct.
Why candidates choose this
Candidates may think that name resolution fails because the private endpoint lacks a public IP, not realizing that private DNS zones require virtual network links for resolution across peered VNets.
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
Customer-Managed Keys (CMK) for Storage Encryption
Key term
DNS zone
A DNS zone is a distinct part of the global Domain Name System (DNS) namespace that is delegated to a specific administrator or organization for management, containing resource records for a domain.
Key term
VNet peering
VNet peering is a networking connection that links two virtual networks so they can communicate with each other as if they were a single network.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way 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.
Variation 1. A storage account is accessed from a VM in VNet A through a private endpoint. A VM in peered VNet B can connect to the storage account by IP, but when it uses the storage account name, it resolves to the public endpoint. What should the administrator configure?
medium- A.Enable a service endpoint on VNet B for Microsoft.Storage.
- ✓ B.Link the private DNS zone for the storage account to VNet B.
- C.Assign the VM in VNet B a managed identity.
- D.Create a route table that points storage traffic to the private endpoint subnet.
Why B: The VM in VNet B can reach the storage account by IP because the private endpoint is accessible over the VNet peering, but DNS resolution still returns the public IP because the private DNS zone (privatelink.blob.core.windows.net) is not linked to VNet B. By linking the private DNS zone to VNet B, the VM will resolve the storage account name to the private endpoint IP, ensuring connectivity over the Microsoft backbone instead of the public internet.
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.