This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Configure Azure Private Link services to secure access to network resources

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Introduction

This topic belongs to the Secure storage, databases, and networking section of the SC-500 exam, under Implement security for Azure network services.

The focus is on configuring Azure Private Link services so that consumers can access privately hosted applications or network resources without exposing those resources through a public endpoint.

What is Azure Private Link?

Azure Private Link provides private connectivity between a consumer’s virtual network and a service. Traffic travels through Azure’s private network rather than across the public internet.

Private Link supports two related scenarios:

• Private endpoints allow consumers to privately access supported Azure platform as a service (PaaS) resources.
• Private Link services allow service providers to publish their own applications or services privately to consumers.

A private endpoint is created in the consumer’s virtual network. It receives a private IP address from that virtual network and connects to a specific resource or Private Link service.

A Private Link service is created by the service provider and exposes an application running behind an Azure Standard Load Balancer. Consumers then create private endpoints in their own virtual networks to connect to that service.

What is an Azure Private Link service?

An Azure Private Link service is the provider-side component of Azure Private Link.

It enables an organization to publish an application or network service running in its own virtual network so that authorized consumers can access it privately from their own virtual networks.

For example, a company might operate a custom payment-processing application behind an internal Standard Load Balancer. Rather than requiring business partners to connect through a public IP address, the company can publish the application through a Private Link service.

The partners create private endpoints in their own virtual networks. Their applications then connect to the private endpoint’s IP address, while Azure privately transports the traffic to the provider’s service.

A Private Link service:

• Is associated with an Azure Standard Load Balancer.
• Uses a selected frontend IP configuration of that load balancer.
• Provides a private connectivity path for consumers.
• Can be accessed by private endpoints in different virtual networks.
• Can support consumers from different subscriptions or Microsoft Entra tenants.
• Allows the service provider to approve or reject connection requests.
• Uses provider-side NAT IP addresses for traffic arriving at the service.

Private Link service architecture

A typical architecture contains the following components:

1. Provider virtual network
   Contains the application or network resource being published.
2. Backend application or service
   Runs on virtual machines, virtual machine scale sets, or other supported network resources.
3. Azure Standard Load Balancer
   Distributes traffic to the backend application.
4. Private Link service
   References the Standard Load Balancer frontend IP configuration.
5. Consumer virtual network
   Contains the private endpoint used by the consumer application.
6. Private endpoint
   Provides a private IP address in the consumer’s virtual network.
7. Private DNS configuration
   Allows applications to resolve the service name to the private endpoint’s IP address when name-based access is required.

The simplified traffic flow is:

Consumer application
        |
        v
Private endpoint
(private IP in consumer VNet)
        |
        v
Azure Private Link
        |
        v
Provider Private Link service
        |
        v
Standard Load Balancer
        |
        v
Backend application

The consumer does not need direct network-level access to the provider’s virtual network. The private endpoint provides the connection boundary between the consumer and the published service.

Important distinction: Private Link service versus private endpoint

These terms are closely related but serve different roles.

A common exam mistake is to assume that a Private Link service itself is the private IP address used by consumers. The consumer actually connects to the private endpoint, which has a private IP address in the consumer’s virtual network.

Requirements for an Azure Private Link service

For the standard Private Link service deployment model, the provider must have:

• An application or service running in an Azure virtual network.
• An Azure Standard Load Balancer.
• A frontend IP configuration on that load balancer.
• A subnet from which the Private Link service can obtain NAT IP addresses.
• Appropriate permissions to create and manage the Private Link service.
• A connection approval process for consumer requests.

Azure Private Link service is supported with Standard Load Balancer, not Basic Load Balancer. The standard load balancer backend pool must use network interfaces rather than IP-address-based backend configuration. Private Link service also supports IPv4 and TCP/UDP traffic in the standard deployment model.

How traffic is processed

When a consumer connects to a Private Link service:

1. The consumer application connects to the private endpoint.
2. The private endpoint forwards the traffic through Azure Private Link.
3. The traffic reaches the provider’s Private Link service.
4. The Private Link service performs destination-side NAT.
5. The traffic is delivered to the selected frontend IP configuration of the Standard Load Balancer.
6. The load balancer distributes the traffic to a healthy backend resource.

The provider normally sees incoming consumer traffic as originating from the Private Link service’s configured NAT IP address pool.

This is important because the provider should not assume that the original consumer IP address will always be visible to the backend application. If the application needs additional connection information, the provider may need to configure and process TCP Proxy Protocol version 2, where supported.

Configure an Azure Private Link service

Step 1: Prepare the provider application

The application must be reachable through an Azure Standard Load Balancer.

The provider should:

• Deploy the application in a virtual network.
• Create or identify the backend pool.
• Configure a health probe.
• Configure a load-balancing rule.
• Select the frontend IP configuration that will receive Private Link traffic.
• Confirm that the application is listening on the required port and protocol.

The load balancer frontend selected for the Private Link service is the entry point for traffic destined for the published service.

Step 2: Prepare the NAT subnet

A Private Link service requires a subnet for its NAT IP configurations.

The NAT IP addresses are used when traffic from consumers reaches the provider’s service. Microsoft recommends planning sufficient address capacity, with at least eight NAT IP addresses available in the subnet as a general recommendation for scalability.

The NAT subnet must be configured appropriately for Private Link service use. In particular, the subnet’s privateLinkServiceNetworkPolicies setting must be disabled for the subnet used by the Private Link service NAT configuration.

A dedicated subnet is not strictly required, but using a dedicated subnet can simplify:

• Network security group management.
• IP address planning.
• Monitoring.
• Troubleshooting.
• Separation of provider networking components.

Step 3: Create the Private Link service

In the Azure portal, the general process is:

1. Search for Private link services.
2. Select Create.
3. Select the subscription and resource group.
4. Specify the region.
5. Select the Standard Load Balancer.
6. Select the load balancer frontend IP configuration.
7. Select the source NAT subnet.
8. Configure the required NAT IP settings.
9. Configure access security and approval settings.
10. Review and create the Private Link service.

The Private Link service must be deployed in the same region as the provider virtual network and Standard Load Balancer.

After creation, Azure provides an alias for the Private Link service. The provider can share this alias with consumers so that they can create private endpoints without requiring direct access to the provider’s subscription or resource hierarchy.

Private Link service aliases

A Private Link service receives a globally unique alias.

The alias can be shared with consumers who need to establish a connection. Consumers can use the alias or the resource ID when creating a private endpoint.

Using an alias is especially useful when:

• The consumer is in another subscription.
• The consumer is in another Microsoft Entra tenant.
• The provider does not want to grant the consumer broad access to the provider’s Azure resources.
• The service is offered to multiple customers or business partners.

The alias identifies the published Private Link service, but it does not automatically authorize every connection. The provider still controls connection visibility, approval, and access policies.

Control access to a Private Link service

A Private Link service provides private connectivity, but the provider must still control who can connect.

Connection approval

When a consumer creates a private endpoint connection, the provider can:

• Approve the request.
• Reject the request.
• Leave the request pending until it is reviewed.

Manual approval is useful when the service is exposed to external organizations or cross-tenant consumers.

The provider should validate:

• The consumer organization.
• The consumer subscription.
• The intended application.
• The business relationship.
• The requested access scope.
• The expected network and security requirements.

A pending connection does not mean that the consumer has completed access. The provider must approve the connection before the private endpoint can use the service.

Automatic approval

Private Link service supports an auto-approval list based on subscriptions.

Subscriptions included in the auto-approval list can have their private endpoint connections approved automatically.

Automatic approval should be used carefully. It is appropriate only when the provider trusts the listed subscriptions and has a reliable process for managing the list.

For external consumers, manual approval is generally safer because it prevents an unexpected subscription from automatically connecting to the service.

Visibility settings

The provider can control which subscriptions are allowed to request connections.

This helps limit the exposure of the Private Link service and prevents arbitrary consumers from requesting access.

Visibility and auto-approval are different:

• Visibility controls who can discover or request access.
• Auto-approval controls which requests are approved automatically.
• Connection approval determines whether a specific connection is allowed.

Private Link service and cross-tenant access

A Private Link service can be consumed by private endpoints in:

• Different virtual networks.
• Different subscriptions.
• Different resource groups.
• Different Microsoft Entra tenants.

This makes Private Link useful for:

• Business-to-business applications.
• Managed service providers.
• SaaS platforms.
• Shared services.
• Centralized application platforms.
• Partner integrations.

Cross-tenant connectivity should be governed carefully. The provider should use restricted visibility, explicit approval, least-privilege administrative roles, and clear ownership of DNS and network configuration.

Private Link does not eliminate the need for application authentication and authorization. A consumer that can connect to the service must still be authorized by the application itself.

DNS considerations

Private Link connectivity and DNS name resolution are separate concerns.

A consumer application may connect to a private endpoint by IP address, but most applications use a fully qualified domain name. The DNS name must resolve to the correct private endpoint IP address.

For Azure PaaS private endpoints, this is commonly handled through Azure Private DNS zones. For a custom Private Link service, the provider and consumer must agree on how the service name will resolve.

A typical DNS design may include:

• A private DNS zone.
• An A record that maps the service name to the private endpoint IP address.
• A virtual network link to the consumer VNet.
• DNS forwarding for on-premises or hybrid clients.

In hub-and-spoke or hybrid environments, Azure Private DNS Resolver can help forward DNS queries between on-premises networks and Azure without requiring custom DNS forwarder virtual machines.

DNS troubleshooting example

Suppose an application connects to:

orders.contoso.com

If the name resolves to a public IP address, the application may bypass the intended private endpoint.

The expected behavior is:

orders.contoso.com
        |
        v
Private endpoint IP address
        |
        v
Private Link service

Useful validation commands include:

nslookup orders.contoso.com

or:

dig orders.contoso.com

The result should be checked from the actual client network, not only from an administrator’s workstation.

Network security controls

Private Link is a network isolation mechanism, but it should be combined with other security controls.

Network security groups

Network security group support for private endpoint subnets is disabled by default. If the organization needs NSG rules to apply to private endpoint traffic, network policies must be enabled for the subnet.

NSGs can be used to restrict:

• Which client subnets can reach the private endpoint.
• Which ports are allowed.
• Which protocols are allowed.
• Which application security groups can communicate with the endpoint.

When NSG support is enabled, verify that the rules do not unintentionally block required Private Link traffic.

Application security groups can simplify NSG management by grouping private endpoints according to application or security function.

Route tables and firewalls

Private Link traffic should be tested with the organization’s routing and inspection architecture.

Depending on the design, the organization may use:

• Network security groups.
• Azure Firewall.
• Network virtual appliances.
• User-defined routes.
• Azure Monitor.
• Flow logs or equivalent network diagnostics.

Do not assume that all traffic will automatically traverse a centralized firewall. Private Link is a private connectivity service, and its traffic behavior must be evaluated against the organization’s routing and inspection requirements.

Disable public exposure where appropriate

Private Link provides a private access path, but it does not automatically disable public access to the provider application.

If the application should be accessible only through Private Link, the provider should:

• Remove unnecessary public IP addresses.
• Restrict public inbound access.
• Configure the application firewall appropriately.
• Use NSGs and load balancer rules to limit traffic.
• Validate private connectivity.
• Disable public network access where the service supports that setting.

For supported Azure PaaS resources, Microsoft recommends disabling public network access after private connectivity has been validated.

For a custom application behind a load balancer, the provider must secure the load balancer and backend application separately. Creating a Private Link service does not automatically secure every other path to the application.

Private Link does not replace identity security

A private connection does not automatically mean that the caller is trusted.

The application should still use appropriate authentication and authorization, such as:

• Microsoft Entra authentication.
• Managed identities.
• Mutual TLS, where appropriate.
• Application tokens.
• Role-based authorization.
• API keys or certificates when required by the application.
• Tenant or customer-level authorization.

For example, a partner may successfully connect to a private endpoint but still be denied by the application because the partner does not have permission to access a particular API or dataset.

Private Link provides network-level privacy. It does not replace application-level access control.

Private Link does not replace encryption

Private Link keeps traffic on Azure’s private network path, but it does not automatically guarantee that the application protocol is encrypted.

The provider should still use:

• HTTPS for web applications.
• TLS for database connections.
• Secure application protocols.
• Valid certificates.
• Strong cipher suites.
• Appropriate certificate rotation procedures.

Private Link does not change the underlying encryption behavior of the application or service.

Monitoring and governance

Private Link services should be governed like other sensitive network resources.

Recommended controls include:

• Azure Policy to audit or enforce Private Link configurations.
• Resource locks to prevent accidental deletion.
• Activity logs for creation, modification, approval, and deletion.
• Monitoring of private endpoint connection states.
• Monitoring of Standard Load Balancer health.
• Monitoring of backend application availability.
• Documentation of approved consumers.
• Periodic review of visibility and auto-approval settings.
• Alerts for unexpected connection requests.
• Infrastructure-as-code deployment for repeatability.

A Private Link service can be deleted only after its associated private endpoint connections have been handled. Before deletion, the provider should reject or remove active connections and verify that dependent consumers have been notified.

Common configuration problems

The Private Link service cannot be created

Possible causes include:

• The load balancer is a Basic Load Balancer.
• The load balancer backend pool uses unsupported IP-based configuration.
• The load balancer and Private Link service are in different regions.
• The NAT subnet has incorrect network policy settings.
• The selected frontend IP configuration is invalid.
• The administrator lacks required permissions.

The consumer cannot connect

Check the following:

• The private endpoint connection has been approved.
• The private endpoint is in a connected state.
• The consumer subnet has appropriate routing.
• NSG rules allow the required traffic.
• The application is listening on the expected port.
• The Standard Load Balancer health probe is healthy.
• The load-balancing rule points to the correct backend pool.
• The provider firewall or application firewall is not blocking the traffic.
• The DNS name resolves to the private endpoint IP address.

DNS resolves to a public address

Possible causes include:

• The private DNS zone is missing.
• The zone is not linked to the consumer VNet.
• The client uses an on-premises DNS server that does not forward queries correctly.
• The DNS record points to the wrong address.
• DNS caching is returning an old result.
• The application uses a hostname that is not configured for private resolution.

The backend sees unexpected source IP addresses

Private Link service traffic is normally translated through the provider’s NAT IP configuration.

The backend may therefore see the NAT IP address rather than the original consumer IP address.

If the application needs connection metadata, consider whether TCP Proxy Protocol version 2 is appropriate and supported for the deployment. Ensure that the application and load balancer configuration are compatible with the selected proxy protocol behavior.

Private Link service versus service endpoints

Private Link services and virtual network service endpoints are not the same.

Service endpoints provide optimized connectivity from a subnet to supported Azure services and allow service-level network restrictions. Private Link is generally preferred when the requirement is to provide a private IP-based connection to a specific resource or service.

Exam-focused facts to remember

• A Private Link service is the provider-side component.
• A private endpoint is the consumer-side component.
• A Private Link service normally requires an Azure Standard Load Balancer.
• Basic Load Balancer is not supported.
• The Private Link service references a load balancer frontend IP configuration.
• Consumer traffic reaches the provider through the Private Link service’s NAT IP configuration.
• The provider can approve or reject private endpoint connection requests.
• Visibility and auto-approval settings control who can request or automatically receive access.
• Private Link can support cross-subscription and cross-tenant consumers.
• Private Link does not automatically disable public access.
• Private Link does not replace application authentication.
• Private Link does not replace TLS or application encryption.
• DNS must resolve the application name to the private endpoint’s IP address.
• NSG policies for private endpoint subnets are disabled by default.
• The Private Link service NAT subnet requires appropriate private link service network policy settings.
• A private endpoint connects to a specific published resource or service, not automatically to every resource in the provider’s environment.

Practice Exam Questions

Question 1

An organization hosts a custom application behind an Azure Standard Load Balancer. Business partners must access the application privately from their own virtual networks.

What should the organization create?

A. An Azure service endpoint on the provider subnet
B. An Azure Private Link service associated with the Standard Load Balancer
C. An Azure VPN gateway in the provider virtual network
D. A public load balancer with a public IP address

Answer: B

Explanation: An Azure Private Link service publishes a provider-owned application for private access. The service is associated with a frontend IP configuration of an Azure Standard Load Balancer. Consumers then create private endpoints in their own virtual networks.

Question 2

A company wants to publish an application through Azure Private Link service. The application is currently behind a Basic Load Balancer.

What should the company do?

A. Enable a service endpoint on the Basic Load Balancer
B. Add a public IP address to the Basic Load Balancer
C. Configure Azure Bastion for the application
D. Replace or migrate the Basic Load Balancer to a supported Standard Load Balancer

Answer: D

Explanation: Standard Azure Private Link service deployments require an Azure Standard Load Balancer. Basic Load Balancer is not supported.

Question 3

A consumer creates a private endpoint to connect to a provider’s Private Link service. The private endpoint connection remains in a pending state.

What is the most likely explanation?

A. The provider has not approved the private endpoint connection
B. The consumer must create a public IP address for the private endpoint
C. The provider must configure a service endpoint instead
D. The consumer must disable all NSGs in the provider virtual network

Answer: A

Explanation: Private endpoint connections to a Private Link service may require provider approval. Until the provider approves the request, the connection can remain pending.

Question 4

A Private Link service provider wants only approved subscriptions to be able to connect automatically. Other subscriptions must require manual review.

Which configuration should the provider use?

A. A route table on the provider subnet
B. A network security group on the load balancer
C. Visibility restrictions and an auto-approval subscription list
D. A public IP prefix attached to the consumer VNet

Answer: C

Explanation: Private Link service visibility controls which subscriptions can request access, while the auto-approval list identifies subscriptions whose requests can be approved automatically. Other requests can be reviewed manually.

Question 5

A provider creates a Private Link service and shares its alias with a partner in another Microsoft Entra tenant.

Which statement is correct?

A. The partner can create a private endpoint using the alias, subject to the provider’s connection controls
B. Cross-tenant private endpoints are not supported
C. The provider must give the partner Owner access to the provider subscription
D. The partner must deploy the Private Link service in the provider’s virtual network

Answer: A

Explanation: Private Link service supports consumers from different subscriptions and Microsoft Entra tenants. The provider can share the service alias without granting broad subscription access. The connection remains subject to visibility and approval settings.

Question 6

A provider wants to control traffic reaching private endpoints using network security groups. The private endpoints are located in a subnet where private endpoint network policies are disabled.

What should the provider do?

A. Enable public network access on the Private Link service
B. Replace the private endpoints with service endpoints
C. Add a public IP address to each private endpoint
D. Enable network policies for private endpoints in the subnet

Answer: D

Explanation: Network policies for private endpoints are disabled by default. They must be enabled on the subnet for NSG rules and supported route-table policies to apply to private endpoint traffic.

Question 7

A consumer application connects to a Private Link service by using a DNS name. The name resolves to a public IP address instead of the private endpoint’s IP address.

What should be investigated first?

A. Whether the provider has enabled TCP Proxy Protocol version 2
B. Whether private DNS records and virtual network links are configured correctly
C. Whether the provider has added a second Standard Load Balancer
D. Whether the consumer has configured a public IP prefix

Answer: B

Explanation: Private Link connectivity depends on correct name resolution. The DNS name should resolve to the private endpoint’s private IP address. Missing private DNS zones, missing VNet links, or incorrect hybrid DNS forwarding can cause the name to resolve publicly.

Question 8

Which statement best describes the source address seen by a backend application behind a Private Link service?

A. It is always the original public IP address of the consumer
B. It is always the private IP address of the consumer’s virtual machine
C. It normally appears to originate from the Private Link service’s NAT IP address pool
D. It is always the public IP address of the Standard Load Balancer

Answer: C

Explanation: Private Link service performs destination-side NAT, and consumer traffic normally appears to originate from the NAT IP configuration associated with the Private Link service.

Question 9

An organization creates a Private Link service for a sensitive application. The application is still reachable through another public load balancer frontend.

What is the best security conclusion?

A. Private Link automatically blocks all public access
B. The application is secure because private endpoints always require Microsoft Entra authentication
C. The public frontend is acceptable because Private Link encrypts all application traffic
D. The organization must separately restrict or disable the unnecessary public access path

Answer: D

Explanation: Creating a Private Link service does not automatically remove other access paths. Public load balancer frontends, public IP addresses, firewall rules, and application access controls must be secured separately.

Question 10

A provider wants to ensure that consumers connecting through Private Link are also authorized to use specific application functions.

Which control is required in addition to Private Link?

A. Application-level authentication and authorization
B. A second private endpoint in the provider VNet
C. A service endpoint on the consumer subnet
D. A public IP address for the backend application

Answer: A

Explanation: Private Link provides private network connectivity, but it does not determine whether a caller is authorized to use the application. The application must still enforce authentication and authorization, such as Microsoft Entra authentication, tokens, roles, certificates, or other appropriate controls.

Go to the SC-500 Exam Prep Hub main page