AZ-500 Secure 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.

• ✗

  The ExpressRoute circuit is not configured for DNS forwarding.

  Why it's wrong here

  ExpressRoute is a Layer 3 connectivity service that extends an on-premises network into Azure; it does not provide DNS resolution or DNS forwarding. DNS forwarding is a server-side function performed by a DNS resolver (e.g., the custom DNS server you configured for the virtual network). An ExpressRoute circuit only carries IP traffic—including DNS queries—but it cannot be 'configured for DNS forwarding' itself. Therefore, the issue is not a missing DNS forwarder on the circuit, but a missing conditional forwarder on your custom DNS server.

• ✓

  The custom DNS server does not have a conditional forwarder to the on-premises DNS.

  Why this is correct

  When you set a custom DNS server on an Azure virtual network, all VMs in that network send their DNS queries to that server. Because your VM can ping the on-premises host by IP but cannot resolve its name, the custom DNS server is receiving the query but does not know where to send it. A conditional forwarder specifically forwards queries for a given on-premises domain suffix (e.g., corp.contoso.com) to the on-premises DNS server. Without this forwarder, the custom DNS server either tries to resolve the name against the internet root hints or responds with an error, failing to resolve the on-premises hostname.

• ✗

  The Azure Private DNS zone does not include the on-premises hostname.

  Why it's wrong here

  Azure Private DNS zones are used to provide DNS resolution for records within a virtual network (or networks linked to the zone), such as custom domain names that you create in Azure. An on-premises hostname is not a record in any Azure Private DNS zone, and adding it there would not make your custom DNS server forward queries to the on-premises DNS. The core problem is the lack of a forwarding path from the Azure-side DNS resolver to the on-premises DNS infrastructure, not a missing zone or record in Azure. Additionally, Private DNS zones are not designed for integrating with on-premises DNS servers—that integration is done via conditional forwarders or DNS server-to-server zone transfers.

• ✗

  An NSG rule is blocking DNS traffic.

  Why it's wrong here

  An NSG rule that blocks DNS traffic would prevent the VM from sending or receiving UDP/TCP port 53 traffic to whatever DNS server it uses. However, the symptom is that name resolution fails specifically for an on-premises hostname, while IP connectivity works—if an NSG blocked DNS, all name resolution would fail, not just for on-prem names, and you likely couldn't resolve Azure names either. Furthermore, NSGs apply to traffic entering/leaving network interfaces or subnets; they do not selectively filter which DNS names can be resolved. Since the VM can reach the on-premises host by IP, the underlying network path is fine, ruling out NSG blocking as the cause.

Go deeper

Related to this question