AZ-104 Implement and Manage Virtual Networking Practice Question
A private endpoint was created for Azure SQL Database in VNet A. A VM in peered VNet B can reach other resources, but it resolves the SQL server name to the public IP and connection attempts fail because public network access is disabled. What is the best fix?
⚠ Common exam trap
Many exam-takers assume DNS resolution works automatically across peered VNets, but private DNS zones are not transitive and must be explicitly linked to each peered VNet for private IP resolution to succeed.
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 appropriate private DNS zone to VNet B.
When public network access is disabled on an Azure SQL Database, the private endpoint in VNet A provides a private IP address for the SQL server. However, for VMs in peered VNet B to resolve the SQL server's fully qualified domain name (FQDN) to that private IP instead of the public IP, the private DNS zone (typically `privatelink.database.windows.net`) must be linked to VNet B. Without this link, DNS resolution falls back to the public IP, causing connection failures because public access is disabled.
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 an outbound NSG rule allowing TCP 1433 to the internet.
Why it's wrong here
An outbound NSG rule permitting TCP 1433 to the internet would only allow traffic to leave VNet B toward the SQL database's public endpoint. Since the SQL server's public endpoint was disabled when the private endpoint was created, the connection attempt would still be blocked by the server-side access control. This rule also does not address DNS resolution: clients in VNet B would still resolve the server name to the public IP (or fail to resolve), rather than to the private endpoint IP, so the rule is irrelevant to the core requirement.
When this WOULD be correct
In a scenario where a VM in a peered VNet cannot connect to an Azure SQL Database because outbound traffic on port 1433 is blocked by an NSG, and public network access is enabled, adding an outbound NSG rule allowing TCP 1433 to the internet would fix the connectivity issue.
- ✓
Link the appropriate private DNS zone to VNet B.
Why this is correct
Clients in VNet B must resolve the SQL server name to the private endpoint address. Linking the private DNS zone to VNet B allows the VM to receive the correct private IP mapping through DNS.
- ✗
Assign a public IP address to the private endpoint.
Why it's wrong here
A private endpoint is a network interface backed by a private IP address from the VNet address space; it does not accept a public IP assignment. Even if you could attach a public IP, doing so would expose the SQL server through a public route, defeating the entire purpose of private connectivity and potentially re-enabling public exposure. More importantly, adding a public IP to the private endpoint does nothing to make VNet B's DNS resolve the SQL server name to the private endpoint address, so the VM's DNS lookup would still return the public endpoint or fail.
When this WOULD be correct
If the question required enabling inbound internet access to an Azure SQL Database while keeping it private within a VNet, assigning a public IP to the database server (not the endpoint) and configuring firewall rules could be correct. However, this scenario is rare and typically avoided.
- ✗
Replace the private endpoint with a service endpoint.
Why it's wrong here
A service endpoint does not assign a private IP address to Azure SQL Database; it only routes traffic from the VNet to the service's public endpoint over the Azure backbone. Because the SQL server's public endpoint is disabled (which is why the private endpoint was created), traffic sent via the service endpoint would still target the public endpoint and fail. Moreover, service endpoints do not integrate with private DNS zones, so clients in VNet B would still resolve the server name to the public IP, leaving the DNS resolution problem unsolved.
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 appropriate private DNS zone to VNet B.Correct answer▾
Why this is correct
Clients in VNet B must resolve the SQL server name to the private endpoint address. Linking the private DNS zone to VNet B allows the VM to receive the correct private IP mapping through DNS.
✗Add an outbound NSG rule allowing TCP 1433 to the internet.Wrong answer — click to see why▾
Why this is wrong here
The issue is DNS resolution, not outbound connectivity. Adding an outbound NSG rule for TCP 1433 to the internet does not change the DNS resolution of the SQL server name from public IP to private IP, so the connection will still fail because public network access is disabled.
★ When this WOULD be the correct answer
In a scenario where a VM in a peered VNet cannot connect to an Azure SQL Database because outbound traffic on port 1433 is blocked by an NSG, and public network access is enabled, adding an outbound NSG rule allowing TCP 1433 to the internet would fix the connectivity issue.
Why candidates choose this
Candidates may think that the connection failure is due to network security blocking outbound traffic, and they focus on allowing the SQL port (1433) outbound, overlooking that the real problem is DNS resolution to a private IP.
✗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 a private endpoint is not supported; private endpoints use private IPs from the VNet. It would not resolve the DNS resolution issue in peered VNet B.
★ When this WOULD be the correct answer
If the question required enabling inbound internet access to an Azure SQL Database while keeping it private within a VNet, assigning a public IP to the database server (not the endpoint) and configuring firewall rules could be correct. However, this scenario is rare and typically avoided.
Why candidates choose this
Candidates may think adding a public IP to the private endpoint would make it reachable from peered VNets, misunderstanding that private endpoints are inherently private and cannot have public IPs.
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
Private IP address
A private IP address is a non-internet-routable address used within a local network to identify devices and allow them to communicate with each other without direct exposure to the public internet.
Key term
Private DNS zone
A private DNS zone is a hosted DNS namespace that is only resolvable from within specific virtual networks or private environments, not from the public internet.
About these practice questions
This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.