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.