hardmultiple choiceObjective-mapped

Exhibit

Topology summary:
- HubVNet: 10.40.0.0/16
  - VM dns01: 10.40.0.4
  - DNS service on dns01 hosts the zone corp.contoso.local
  - HubVNet DNS servers: 10.40.0.4
- SpokeVNet: 10.41.0.0/16
  - Peered with HubVNet
  - Allow virtual network access: Enabled
  - Allow forwarded traffic: Enabled
  - DNS servers: Azure-provided
- Test results from app01 in SpokeVNet:
  - ping 10.40.1.10  => success
  - nslookup web01.corp.contoso.local => NXDOMAIN
  - nslookup www.microsoft.com => success

Based on the exhibit, what should the administrator configure so the VM in the spoke VNet can resolve internal hostnames that are hosted on the DNS server in the hub VNet?

The team has already verified that IP connectivity between the spoke VM and the hub VM works.

Question 1hardmultiple choice
Full question →

Based on the exhibit, what should the administrator configure so the VM in the spoke VNet can resolve internal hostnames that are hosted on the DNS server in the hub VNet?

The team has already verified that IP connectivity between the spoke VM and the hub VM works.

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Best answer

Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.

The spoke already has network connectivity to the hub, so the remaining problem is name resolution. Azure VNet peering does not copy DNS settings from one VNet to another. By configuring the spoke to use the hub DNS server, queries for the internal zone are sent to the resolver that actually hosts or forwards that namespace.

B

Distractor review

Create a private endpoint for web01.corp.contoso.local in the spoke VNet so DNS resolves automatically.

A private endpoint changes how a specific Azure service is reached, but it does not fix general DNS for a custom internal zone hosted on a VM. The failure shown is about resolving an internal hostname, not reaching a PaaS resource through a private IP.

C

Distractor review

Enable gateway transit on the peering so the spoke inherits the hub VNet DNS configuration.

Gateway transit is used to share a VPN or ExpressRoute gateway, not to inherit DNS server settings across a peering. The exhibit already shows successful IP connectivity, so the issue is not transit routing. DNS must still be configured explicitly in the spoke.

D

Distractor review

Add inbound and outbound NSG rules allowing UDP and TCP port 53 between the two VNets.

The exhibit shows the spoke VM can reach the hub VM by IP, which makes a basic network block less likely. More importantly, DNS server selection is controlled by VNet DNS settings and name resolution configuration, not by opening NSG rules alone.

Common exam trap

Common exam trap: NAT rules depend on direction and matching traffic

NAT is not only about the public address. The inside/outside interface roles and the ACL or rule that matches traffic are just as important.

Technical deep dive

How to think about this question

NAT questions usually test address translation, overload/PAT behaviour, static mappings and whether the right traffic is being translated. Read the interface direction and address terms carefully.

KKey Concepts to Remember

  • Static NAT maps one inside address to one outside address.
  • PAT allows many inside hosts to share one public address using ports.
  • Inside local and inside global describe the private and translated addresses.
  • NAT ACLs identify traffic for translation, not always security filtering.

TExam Day Tips

  • Identify inside and outside interfaces first.
  • Check whether the scenario needs static NAT, dynamic NAT or PAT.
  • Do not confuse NAT matching ACLs with normal packet-filtering intent.

Related practice questions

Related AZ-104 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this AZ-104 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly. — The spoke VM can already reach the hub by IP, so routing and peering are functioning. The broken piece is DNS: Azure-provided DNS in the spoke cannot automatically resolve the internal corp.contoso.local zone hosted on the hub DNS server. The administrator should point the spoke VNet to 10.40.0.4, or to a resolver that forwards to it, so the spoke uses the correct name-resolution path. Why others are wrong: Private endpoints are for specific Azure services, not for fixing a custom internal DNS zone. Gateway transit shares a network gateway and does not inherit DNS settings. NSG rules can allow DNS traffic, but they do not tell a VNet which DNS server to query, and the exhibit already proves basic IP connectivity works.

What should I do if I get this AZ-104 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.