Technical Lab: Create a Private Link service
Questions
Question 1 — Multiple Choice
When creating a Private Link service in front of an internal Standard Load Balancer, an architect notices that the configuration requires a specific type of NAT to function. What is the purpose of the source IP address NAT automatically applied by the service in this context?
A) Ensure that consumer traffic reaches the backend with the original IP preserved, avoiding routing conflicts.
B) Translate the consumer's IP address to an IP within the provider subnet's address space, avoiding conflicts between overlapping VNets.
C) Map the consumer endpoint's private IP to the provider's Load Balancer public IP.
D) Replace the packet's destination IP with the real backend IP before forwarding to the Load Balancer pool.
Question 2 — Technical Scenario
A team configured a Private Link service and provided the alias to the consumer team. The consumer team created a Private Endpoint in their VNet pointing to this alias. After creation, the connection status on the provider side shows as Pending. Traffic does not flow.
What does the provider need to do for connectivity to be established?
A) Recreate the Private Link service with automatic approval enabled for the consumer's subscription.
B) Manually approve the pending connection request in the Private Link service, as automatic approval was not configured for that subscription.
C) Request that the consumer delete and recreate the Private Endpoint using the complete Resource ID instead of the alias.
D) Add the consumer's Private Endpoint IP address to the Network Security Group of the provider subnet.
Question 3 — True or False
A Private Link service can be associated with an internal Basic Load Balancer, as long as the NAT subnet SKU is compatible with the service.
Question 4 — Technical Scenario
An engineer is creating a Private Link service and needs to define the NAT subnet. He chooses a subnet that also hosts the Load Balancer backend VMs, believing it simplifies the design. Consider the partial configuration:
Private Link Service:
Load Balancer Frontend IP: 10.0.1.10 (Internal Standard LB)
NAT Subnet: 10.0.1.0/24 <-- same subnet as backends
Visibility: Restricted (subscription list)
What is the main problem with this approach?
A) The NAT subnet must belong to a different VNet from the Load Balancer VNet.
B) Using the same subnet as backends for NAT is not technically prohibited, but creates operational risk of NAT IP exhaustion and management overlap, being an explicitly non-recommended practice.
C) The Private Link service requires that the NAT subnet has a default route pointing to an NVA before forwarding to the Load Balancer.
D) The NAT subnet needs to have the Private Link Network Policy enabled, which is incompatible with subnets hosting VMs.
Question 5 — Multiple Choice
A service provider wants to expose their solution via Private Link service to a restricted set of customers, without the alias being publicly discoverable. Additionally, they want consumers from specific subscriptions to be able to create Private Endpoints without manual approval.
Which combination of configurations meets both requirements simultaneously?
A) Visibility set to None and automatic approval configured with the list of authorized subscriptions.
B) Visibility set to RBAC and automatic approval disabled, delegating control via Azure Policy.
C) Visibility set to Restricted (specific subscriptions) and automatic approval configured with the same subscriptions.
D) Visibility set to Public and automatic approval configured only for customer subscriptions, blocking others via NSG.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The SNAT (Source NAT) applied by the Private Link service translates the consumer's source IP to an IP allocated from the provider's NAT subnet. This is fundamental because consumers and providers may have overlapping address spaces, and the provider's backend never sees the consumer's real IP, only seeing an IP from the NAT subnet.
The main misconception represented by the distractors is confusing the direction of translation: NAT acts on the source IP (consumer), not on the destination IP (backend). Alternative A denies exactly what happens. Alternative C mixes public IP concepts, which are not part of the Private Link flow. Alternative D describes Load Balancer behavior (DNAT), not Private Link.
Answer Key — Question 2
Answer: B
When a Private Link service doesn't have the consumer's subscription listed in automatic approval, every new Private Endpoint connection arrives with Pending status. Data flow remains blocked until the service owner accesses the connections panel and manually approves the request.
Alternative A is incorrect because recreating the service is unnecessary; automatic approval can be edited without recreation, but the immediate solution is manual approval of the existing connection. Alternative C is a common misconception: alias and Resource ID are valid and interchangeable ways to reference the service; Pending status is not related to which form was used. Alternative D confuses the control plane (connection approval) with the data plane (NSG rules), which are independent mechanisms.
Answer Key — Question 3
Answer: False
The Private Link service mandatorily requires an internal Standard Load Balancer as frontend. The Basic Load Balancer is not supported for this purpose, regardless of any additional subnet configuration or SKU. This distinction is important because the Basic LB lacks the high availability features and integration APIs necessary for the Private Link service.
Answer Key — Question 4
Answer: B
Technically, Azure doesn't prevent the NAT subnet from being the same as the backends, but this is an explicitly non-recommended practice by Microsoft. The central problem is that NAT IPs are dynamically allocated from this subnet for each consumer connection, which can exhaust available space and create operational conflicts in an environment where VMs also consume IPs from the same range.
Alternative A is false: the NAT subnet must be in the same VNet as the Load Balancer. Alternative C introduces a non-existent requirement; the Private Link service doesn't require NVA in the NAT subnet route. Alternative D inverts the correct logic: in the NAT subnet, the Private Link Network Policy must be disabled, not enabled, and this requirement has no relation to the presence of VMs.
Answer Key — Question 5
Answer: C
To restrict service discovery to a specific group of subscriptions, visibility must be configured as Restricted, explicitly listing the authorized subscriptions. To eliminate manual approval friction for these same customers, automatic approval must be configured with the same list.
Alternative A is incorrect because None visibility prevents any consumer from discovering or creating connections with the service, blocking even authorized customers. Alternative B is incorrect because RBAC mode controls visibility by role permission, not by subscription, and disabling automatic approval contradicts the second requirement. Alternative D contradicts the first requirement: Public visibility means anyone with the alias can attempt to create a Private Endpoint, exposing the service beyond the intended restricted group.