Cascade Regional Airlines' internal reservations API, running in one VNet, needs to resolve the private endpoint name of a database service that lives in a peered VNet, using a private DNS zone that already contains the correct record. What must be configured on the private DNS zone for the API's VNet to actually query and resolve that name?

A virtual network link associates a VNet with a private DNS zone and comes in two flavors: a resolution link, which lets resources in that VNet query and resolve records in the zone, and an optional registration link, which additionally lets Azure auto-create records for VMs deployed in that VNet. For the reservations API's VNet to resolve the database's private endpoint record, it needs at minimum a resolution-only virtual network link to the zone holding that record — VNet peering alone does not extend private DNS resolution across VNets, since peering only handles network connectivity, not name resolution. Autoregistration is the registration half of a VNet link and only controls whether VM records get created automatically; it doesn't grant resolution ability by itself and isn't needed here since the record already exists. A conditional forwarder on-premises is used to route on-premises DNS queries toward Azure DNS for Azure-hosted zones, which is unrelated to a purely intra-Azure VNet resolving a private zone record. A public NS delegation applies to public DNS zones and has no role in private zone resolution. The exam-relevant caveat: a private DNS zone can be linked to multiple VNets, and a VNet can only be linked for resolution to one instance of that specific zone's DNS suffix at a time. Operationally, verify by checking the private DNS zone's Virtual Network Links blade lists the API's VNet, then test resolution with nslookup against the private endpoint's FQDN from a VM in that VNet.