AI-103 Practice Question 51: Foundry Private Endpoint DNS

Creating a private endpoint doesn't change how clients resolve the resource's hostname; it only adds a private IP for that hostname to route to. Microsoft's own troubleshooting guidance names this exact symptom: "DNS resolution returns a public IP address", and the fix is to "confirm that a private DNS zone exists for the `privatelink` subdomain and is linked to your virtual network", then verify with nslookup that it resolves to the private IP from inside the VNet. Azure normally creates this zone automatically when the private endpoint is created, but a hub-and-spoke topology, a custom DNS server, or a zone linked to the wrong VNet all leave clients falling back to the public endpoint even though the private endpoint itself is healthy.

- A is wrong because a Pending connection blocks traffic entirely rather than silently falling back to the public endpoint, and the stem already states the connection is Approved. - C is wrong because it weakens the bank's posture instead of fixing the routing problem; it would let the spoke reach the resource over its public endpoint, which is the opposite of what "resolves to the private IP" requires, and does nothing about DNS. - D is wrong because an NSG rule controls whether traffic already routed to the private IP is allowed through; it has no effect on which IP address the hostname resolves to in the first place, and the stem's symptom is a resolution problem, not a blocked-connection problem.

Reference: How to configure network isolation for Microsoft Foundry