AZ-104 Implement and Manage Virtual Networking Practice Question
A spoke VM can connect to a hub VM by IP address after peering is configured, but it cannot resolve internal host names such as app01.corp.local. The hub has a DNS server at 10.50.1.4 that hosts those records. What should the administrator configure so the spoke VMs use that DNS server?
⚠ Common exam trap
Test-takers frequently confuse VNet peering with DNS resolution, assuming that peering automatically enables name resolution across VNets, when in fact you must explicitly configure a custom DNS server or use Azure Private DNS Zones to resolve private hostnames.
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
✓
Set the spoke VNet's custom DNS server to 10.50.1.4.
The spoke VNet must be configured to use a custom DNS server to override Azure's default internal name resolution. By setting the spoke VNet's DNS server to 10.50.1.4, all VMs in the spoke will query that server for hostname resolution, including app01.corp.local. This is a VNet-level setting that applies to all VMs in the spoke, and it does not require any changes to NSGs or peering configurations.
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 NSG rule allowing UDP and TCP port 53 between the VNets.
Why it's wrong here
Port 53 may be required for DNS traffic, but it does not tell the spoke where to send queries.
When this WOULD be correct
An administrator configures VNet peering but cannot connect to the hub VM by IP address. The hub VM has a firewall blocking inbound DNS traffic. Adding an NSG rule allowing UDP/TCP 53 on the hub subnet would permit the spoke VMs to reach the hub's DNS server.
- ✓
Set the spoke VNet's custom DNS server to 10.50.1.4.
Why this is correct
The spoke VNet must be told to use the DNS server that contains the internal zone records. By configuring 10.50.1.4 as the custom DNS server for the spoke VNet, new and existing VMs in that VNet can query the hub-based resolver for names such as app01.corp.local. Peering alone does not change DNS behavior, so the DNS server setting is the missing configuration.
- ✗
Create a private endpoint for the hub DNS server.
Why it's wrong here
Private endpoints are for Azure PaaS services, not for exposing a standard DNS server as a private service.
When this WOULD be correct
An administrator needs to securely connect to an Azure SQL Database from a spoke VNet using a private IP address, avoiding public internet exposure. In that scenario, creating a private endpoint for the SQL Database in the hub VNet would be correct.
- ✗
Enable remote gateways on the spoke peering.
Why it's wrong here
Remote gateways are for routing through an existing gateway, not for name resolution between VNets.
When this WOULD be correct
This option would be correct in a scenario where the hub VNet has a VPN gateway or ExpressRoute gateway, and the spoke VNet needs to use that gateway to access on-premises resources or the internet. The question would specify that the spoke VMs need to route traffic through the hub's gateway.
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.
✓Set the spoke VNet's custom DNS server to 10.50.1.4.Correct answer▾
Why this is correct
The spoke VNet must be told to use the DNS server that contains the internal zone records. By configuring 10.50.1.4 as the custom DNS server for the spoke VNet, new and existing VMs in that VNet can query the hub-based resolver for names such as app01.corp.local. Peering alone does not change DNS behavior, so the DNS server setting is the missing configuration.
✗Add an NSG rule allowing UDP and TCP port 53 between the VNets.Wrong answer — click to see why▾
Why this is wrong here
The issue is DNS resolution, not network connectivity. NSG rules control traffic flow, but the spoke VNet still uses its default Azure DNS, not the hub's DNS server. Adding NSG rules for port 53 does not change the DNS server configuration.
★ When this WOULD be the correct answer
An administrator configures VNet peering but cannot connect to the hub VM by IP address. The hub VM has a firewall blocking inbound DNS traffic. Adding an NSG rule allowing UDP/TCP 53 on the hub subnet would permit the spoke VMs to reach the hub's DNS server.
Why candidates choose this
Candidates often confuse connectivity issues with DNS resolution. Since DNS uses port 53, they assume that allowing this port via NSG will fix name resolution, overlooking that the VNet's DNS server setting must be changed first.
✗Create a private endpoint for the hub DNS server.Wrong answer — click to see why▾
Why this is wrong here
A private endpoint is used to securely access Azure PaaS services (like Azure SQL, Storage) over a private IP within a VNet, not to configure DNS resolution for VMs. It does not set a custom DNS server for a VNet.
★ When this WOULD be the correct answer
An administrator needs to securely connect to an Azure SQL Database from a spoke VNet using a private IP address, avoiding public internet exposure. In that scenario, creating a private endpoint for the SQL Database in the hub VNet would be correct.
Why candidates choose this
Candidates may confuse private endpoints with DNS resolution because both involve private IPs and name resolution, but private endpoints are for PaaS services, not for setting DNS servers for VMs.
✗Enable remote gateways on the spoke peering.Wrong answer — click to see why▾
Why this is wrong here
Enabling remote gateways on the spoke peering allows the spoke VNet to use the hub's VPN/ExpressRoute gateway for outbound connectivity, but it does not configure DNS settings. The spoke VMs still need a custom DNS server address to resolve internal host names.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the hub VNet has a VPN gateway or ExpressRoute gateway, and the spoke VNet needs to use that gateway to access on-premises resources or the internet. The question would specify that the spoke VMs need to route traffic through the hub's gateway.
Why candidates choose this
Candidates may confuse the concept of using a hub's gateway for network connectivity with using a hub's DNS server for name resolution, assuming that enabling remote gateways also forwards DNS queries.
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
DNS
DNS is the system that translates human-friendly domain names like example.com into machine-readable IP addresses so computers can find each other on a 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 →
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.