Technical Lab: Integrate a Private Link service with on-premises clients
Questions
Question 1 — Multiple Choice
A network team needs to expose an internal service hosted on a Standard Load Balancer in Azure to on-premises partner clients, without exposing the service to the public internet and without requiring virtual network peering (VNet peering) between the parties.
Which combination of resources makes this scenario possible?
A) A Public Load Balancer associated with a public endpoint, with NSG restricting access to the partner's IP.
B) A Private Link Service linked to the Standard Load Balancer, with a Private Endpoint created in the consumer's VNet and connected via ExpressRoute or VPN to the on-premises environment.
C) A Service Endpoint configured in the consumer's subnet, pointing to the internal service, with route defined via BGP over VPN.
D) An Internal Load Balancer with static IP directly accessible via site-to-site VPN tunnel, without need for Private Link.
Question 2 — Technical Scenario
An engineer configured a Private Link Service to expose an internal application. The service was approved and the Private Endpoint was successfully created on the consumer side. However, on-premises clients cannot reach the endpoint by the configured DNS name.
The environment is as follows:
On-premises DNS → resolves "app.interno.empresa.com"
Private Endpoint IP: 10.1.4.20 (assigned in consumer's VNet)
On-premises DNS: points to 10.1.4.20
Route to 10.1.4.0/24: absent from on-premises routing table
What is the most likely cause of connectivity failure?
A) The Private Link Service does not support access from on-premises clients; a Public Endpoint is required.
B) The on-premises DNS cannot resolve Private Endpoint names because Azure private DNS is mandatory and cannot be integrated with external resolvers.
C) The route to the Private Endpoint network prefix is not being advertised or configured to the on-premises environment, preventing traffic routing to the endpoint IP.
D) The Private Endpoint was not registered in the correct private DNS zone, so the returned IP address is the service's public IP.
Question 3 — True or False
A Private Link Service can be associated with a Basic Load Balancer, as long as the backend service is in a subnet with Private Link network policies disabled.
Question 4 — Technical Scenario
A company wants its on-premises clients to access a Private Endpoint hosted in an Azure VNet via ExpressRoute with private peering. The responsible engineer configures the Private Endpoint, creates a private DNS zone (privatelink.database.windows.net) and links it to the VNet. After configuration, on-premises clients attempt to resolve the name and receive the service's public IP, not the endpoint's private IP.
What is the cause of this behavior?
A) ExpressRoute private peering does not support traffic to Private Endpoints; Microsoft Peering is required.
B) The private DNS zone is linked to the Azure VNet, but on-premises DNS resolvers do not directly query Azure private DNS; a DNS Forwarder or DNS Resolver is needed to forward queries to Azure.
C) The private DNS zone's A record was overwritten by the service's public CNAME record, and the CNAME record needs to be manually deleted.
D) The Private Endpoint needs to have a DNS network policy enabled on the subnet for resolution to work in hybrid scenarios with ExpressRoute.
Question 5 — Multiple Choice
When configuring on-premises client access to a service exposed via Private Link, what is the role of Private Endpoint network policies (PrivateEndpointNetworkPolicies) in the subnet where the endpoint is provisioned?
A) They control whether the Private Endpoint can be accessed by clients outside the VNet, blocking connections from on-premises networks by default.
B) When enabled, they allow NSGs and user-defined routes (UDRs) to be applied to traffic destined for the Private Endpoint IP, enabling granular traffic control.
C) They determine whether the Private Link Service can accept connections from consumers in different subscriptions, functioning as an access control list between tenants.
D) When enabled, they disable private DNS resolution for the endpoint and require the client to use the IP directly.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Private Link Service is the mechanism that allows the provider to expose a service behind a Standard Load Balancer privately. The consumer creates a Private Endpoint in their VNet, which receives a private IP. On-premises clients access this IP via ExpressRoute (private peering) or site-to-site VPN, without any internet exposure.
The main error represented by the distractors is confusing access restriction mechanisms (NSG, Service Endpoint) with actual network isolation. Service Endpoints do not create a private IP in the consumer's VNet; they only extend the VNet's identity to the service control plane. An Internal Load Balancer accessible via VPN without Private Link directly exposes the internal IP and requires address space overlap or peering, which Private Link solves by design.
Answer Key — Question 2
Answer: C
DNS correctly resolved the name to IP 10.1.4.20, but traffic doesn't reach the destination because no route exists for the 10.1.4.0/24 prefix in the on-premises routing table. DNS resolution and packet routing are independent layers: the client knows where to send, but the network infrastructure doesn't know how to forward the packet.
Alternative A is false: Private Link supports on-premises access. Alternative B is imprecise: it's possible to integrate on-premises DNS with Azure via forwarders. Alternative D describes a real problem, but not the cause in this scenario, as the returned IP is already the correct private IP (10.1.4.20).
Answer Key — Question 3
Answer: False
The Private Link Service mandatorily requires a Standard Load Balancer as frontend. The Basic Load Balancer is not compatible with Private Link. This is a platform limitation, not workaround-able through subnet configuration or network policies. The confusion occurs because other Azure functionalities accept Basic Load Balancer, leading to the misconception that the restriction can be compensated by other configuration adjustments.
Answer Key — Question 4
Answer: B
Azure private DNS only responds to queries that arrive from within the linked VNet. On-premises DNS resolvers query their own servers, which by default do not forward queries to Azure. To bridge this gap, a DNS Forwarder (a VM or resolution service within the VNet) or the Azure DNS Private Resolver is needed, which accepts queries from external networks and forwards them to Azure private DNS.
Alternative A is wrong: ExpressRoute private peering supports traffic to Private Endpoints. Alternative C describes behavior that doesn't occur automatically; the private zone's A record is not spontaneously overwritten by public CNAME. Alternative D confuses endpoint network policies (which affect NSG/UDR) with DNS resolution.
Answer Key — Question 5
Answer: B
By default, Private Endpoint network policies are disabled, which means NSGs and UDRs associated with the subnet are not applied to traffic destined for the Private Endpoint IP. By enabling PrivateEndpointNetworkPolicies, it becomes possible to use NSGs to control which sources (including on-premises prefixes) can reach the endpoint, and UDRs to force traffic through an NVA or firewall.
The distractors represent common confusions: alternative A reverses the logic (policies don't block by default and aren't specific to on-premises); alternative C describes the Private Link Service connection approval mechanism behavior, not network policies; alternative D mixes network policies with DNS behavior, which are independent.