Cloud / Azure Private Link Interview questions

Azure Private Link lets you reach Azure PaaS services, and your own services hosted on Azure, through a private IP address inside your virtual network instead of a public endpoint. Traffic stays on the Microsoft backbone network and never crosses the public internet.

It works in two directions. As a consumer you create a private endpoint that points at one specific resource, such as a storage account or SQL server. As a provider you publish your own application behind a Standard Load Balancer using a Private Link service.

The practical effect is that mystorage.blob.core.windows.net behaves as if it lived in your own subnet, and you can then switch off its public network access completely.

A private endpoint is a network interface in your subnet that gets a private IP address and is mapped to one specific Azure resource and one sub-resource of it, for example the blob service of a single storage account.

Because the mapping is to a resource instance, not to the whole service type, you can allow access to your own storage account without opening a path to every other storage account in the region.

The endpoint is a regional resource that lives in the same region as its virtual network, but the target resource can be in a different region. Clients still use the normal service hostname, so DNS has to resolve that name to the private IP.

A Private Link service is the provider-side resource that publishes your own application to other virtual networks, subscriptions, or tenants over Private Link. It is attached to the frontend IP configuration of a Standard Load Balancer that fronts your backend VMs or pods.

Consumers create a private endpoint that targets the service by its alias or resource ID. Their traffic is source-NATed to an IP from a NAT subnet you choose, then delivered through the load balancer.

You control who can connect with visibility settings and an auto-approval list, so partner access does not require peering or exposing a public IP.

Private Link is made of a few cooperating pieces. Some sit on the consumer side, some on the provider side, and DNS ties them together.

Its purpose is to let workloads use Azure services privately, without sending traffic to a public endpoint.

• Remove public exposure: the resource can have public network access disabled.
• Private reachability: the service gets an address from your own address space, reachable from peered VNets and from on-premises over VPN or ExpressRoute.
• Exfiltration control: an endpoint reaches one resource, not the whole service.
• Overlapping IP ranges: consumer and provider address spaces can overlap because no peering is needed.

Every private endpoint connection has a state that shows where it is in the approval cycle. Only one state lets traffic through.

The group ID selects which sub-service of the target resource the endpoint exposes. One private endpoint carries exactly one group ID.

If an application needs both Blob and Data Lake (dfs) access on the same account, you create two endpoints.

Use az network private-endpoint create with the subnet, the target resource ID, and the group ID.

az network private-endpoint create \
  --name pe-stdata-blob \
  --resource-group rg-net \
  --vnet-name vnet-spoke1 \
  --subnet snet-pe \
  --private-connection-resource-id $(az storage account show -n stdata123 --query id -o tsv) \
  --group-id blob \
  --connection-name conn-stdata-blob

The command creates the NIC and the connection. If you have rights on the target it is auto-approved. DNS is a separate step, handled by a private DNS zone group.

Clients keep using the normal service hostname, so something must make that name return the private IP. That is the job of a private DNS zone such as privatelink.blob.core.windows.net.

When a client queries mystorage.blob.core.windows.net, the public DNS answers with a CNAME to mystorage.privatelink.blob.core.windows.net. A private zone linked to your VNet answers that second name with an A record holding the endpoint's private IP.

The zone only answers queries that come from virtual networks linked to it, or from resolvers that forward into those networks.

Each service type has its own privatelink zone. These are the ones you meet most often:

Always confirm the current zone name in the Microsoft documentation for the service, since some services need more than one zone.

A private DNS zone group is a child object of a private endpoint that links the endpoint to one or more private DNS zones. Azure then creates, updates, and deletes the A records for you as the endpoint changes.

Without it, you add and clean up A records by hand, which is how stale records and outages usually start.

az network private-endpoint dns-zone-group create \
  -g rg-net --endpoint-name pe-stdata-blob --name default \
  --private-dns-zone privatelink.blob.core.windows.net \
  --zone-name blob

Creating a private endpoint also creates a read-only network interface in the endpoint's subnet. This NIC holds the private IP that clients connect to.

• It is created in the same resource group as the private endpoint.
• You cannot attach it to a VM or modify it directly.
• Its lifecycle follows the endpoint: delete the endpoint and the NIC goes with it.
• The IP is allocated from the subnet; you can request a specific static IP when you create the endpoint.

Support is broad and keeps growing. Common examples:

• Data: Storage, Azure SQL Database, Cosmos DB, Synapse, Data Factory
• Security and integration: Key Vault, Service Bus, Event Hubs, Event Grid
• Compute and apps: App Service, Functions, Container Registry, AKS private cluster API server
• AI and monitoring: Azure OpenAI and other Foundry resources, Azure Monitor through AMPLS

Check the Private Link availability page before designing, because the supported sub-resources and regions differ per service.

Manual approval means the resource owner must approve a private endpoint connection before it works. The connection sits in Pending until then.

It applies when you create an endpoint to a resource you do not have approval rights on (the privateEndpointConnectionsApproval permission), when the resource is in another tenant, or when a Private Link service has no matching entry in its auto-approval list.

You can add a request message to tell the owner who is asking and why.

Before you create one, line up the following:

1. A virtual network and subnet with at least one free IP address, in the region where the endpoint will live.
2. The resource ID and group ID of the target.
3. Permissions to create network resources, plus approval rights on the target or an owner who can approve.
4. A DNS plan: the right privatelink zone, linked to the VNets that need it, or forwarders for on-premises.
5. The Microsoft.Network resource provider registered on the subscription.

A Private Link service translates each consumer's source address to an IP from a NAT subnet in the provider's VNet. Those addresses are the NAT IP configurations.

You can configure up to 8 per service, and each one adds about 64,000 ports of capacity, so adding NAT IPs is how you scale concurrent connections.

Side effect: the backend sees the NAT IP, not the consumer's real address, unless TCP Proxy Protocol v2 is enabled. The NAT subnet also needs Private Link service network policies disabled.

Private Link Center is the portal hub for everything Private Link. From one blade you can see private endpoints and Private Link services, review pending connection requests, approve or reject them, and start creating new endpoints.

It saves you from opening each target resource individually to find out what is waiting for approval.

An Azure Monitor Private Link Scope groups Azure Monitor resources, such as Log Analytics workspaces, Application Insights components, and data collection endpoints, behind a single private endpoint.

Each scope has access modes for ingestion and query. Open allows both private and public traffic, while Private Only accepts traffic only from the private endpoint.

The endpoint needs several DNS zones, for example privatelink.monitor.azure.com and the oms and ods opinsights zones.

Managed private endpoints are created by services like Azure Data Factory and Synapse inside the Microsoft-managed virtual network that runs their integration runtimes, not inside your VNet.

You request one to a data source such as a storage account or SQL server, and the data source owner approves it. After that the service reaches the source privately even if its public access is off.

Because they live in a managed network, you do not pick a subnet or manage a NIC.

Once the endpoint works, turn off the public path on the resource. Most services expose a public network access setting for this. On a storage account:

az storage account update \
  --name stdata123 --resource-group rg-data \
  --public-network-access Disabled

Move every client to the private name first, and verify DNS from each network. Then test that a request from outside your network fails and one from inside succeeds.

Both keep traffic on the Azure backbone, but they work very differently. A service endpoint extends your subnet's identity to the service's public IP. A private endpoint gives the resource a private IP in your VNet.

Pick the private endpoint when on-premises access or resource-level isolation matters.

Applications connect by hostname, and TLS certificates are issued for that hostname. If DNS keeps returning the service's public IP, traffic skips the private endpoint entirely.

So the name must stay the same but resolve to the endpoint's private IP inside your network. That is why you connect to mystorage.blob.core.windows.net and not to a raw IP.

With public access disabled, a wrong DNS answer does not fall back gracefully. Requests simply fail, which is the most common Private Link outage.

The client asks for mystorage.blob.core.windows.net. Public DNS answers with a CNAME to mystorage.privatelink.blob.core.windows.net. Inside a VNet linked to the private zone, that second name resolves to the endpoint's private IP. Outside, it resolves to the public IP.

sequenceDiagram
  participant V as VM in VNet
  participant D as Azure DNS
  participant Z as Private DNS zone
  V->>D: mystorage.blob.core.windows.net
  D-->>V: CNAME mystorage.privatelink.blob.core.windows.net
  V->>D: mystorage.privatelink.blob.core.windows.net
  D->>Z: lookup in linked zone
  Z-->>V: A 10.0.2.5

The CNAME is why the same hostname works both inside and outside your network.

On-premises DNS cannot talk to Azure's resolver at 168.63.129.16 directly, because that address is only reachable from inside Azure. So you add a hop.

1. Deploy an Azure DNS Private Resolver inbound endpoint, or a DNS forwarder VM, in a VNet linked to the private zones.
2. On your on-premises DNS, create a conditional forwarder for the service's public zone, such as blob.core.windows.net, pointing to that inbound endpoint.
3. Make sure VPN or ExpressRoute routes the private endpoint subnet to on-premises.

Forwarding the public zone name keeps non-private accounts resolving normally, since Azure DNS still returns their public IPs.

A private endpoint maps to one resource instance. A VM using the endpoint to storageA has no path through that endpoint to storageB, even in the same region.

A service endpoint is broader: it allows the subnet to reach the whole service type unless you add service endpoint policies. Private Link also works in one direction. Only the consumer starts connections, and the provider cannot reach back into your VNet.

For full protection, also disable public access on the target and block outbound internet or restrict it with a firewall.

They are the two ends of the same connection. The Private Link service publishes your application. The private endpoint consumes it.

A Private Link service is attached to a frontend IP configuration of a Standard Load Balancer. That load balancer decides which backend instance receives each connection, using health probes and its distribution rules.

The Basic SKU is not supported. The service relies on Standard SKU features and platform integration, so the provider uses an internal Standard Load Balancer and publishes it.

1. The provider creates a Standard Load Balancer and a Private Link service on its frontend, with a NAT subnet.
2. The provider shares the service alias or resource ID.
3. The consumer creates a private endpoint to that alias in their own VNet.
4. The connection is auto-approved or approved manually.
5. Consumer traffic reaches the endpoint IP, is NATed, and lands on a backend through the load balancer.

flowchart LR
  C["Consumer VM"] --> E["Private endpoint 10.1.0.4"]
  E --> S["Private Link service"]
  S --> L["Standard LB frontend"]
  L --> B["Backend VMs"]

No peering, no public IP, and no address planning between the two networks.

By default the backend sees the service's NAT IP, so every consumer looks the same. Enable TCP Proxy Protocol v2 on the service to fix this.

With it on, each connection starts with a proxy header carrying the consumer's source IP and a LinkID that identifies the private endpoint. Your application or proxy, such as NGINX or HAProxy, must be configured to read that header.

az network private-link-service update \
  -g rg-prov -n pls-app --enable-proxy-protocol true

A public answer means DNS is not using your private zone. Work from the client outward:

1. Run nslookup mystorage.blob.core.windows.net from the failing client and check for the CNAME to the privatelink name.
2. Confirm the private DNS zone exists and has an A record for the account.
3. Confirm the zone is linked to the client's VNet.
4. If the VNet uses custom DNS, check that server forwards to Azure DNS or a Private Resolver.
5. From on-premises, check the conditional forwarder and any hosts file or DNS cache.

Pending means the resource owner has not approved the connection. DNS and routing are not the problem yet.

1. Open the target resource and check Networking > Private endpoint connections.
2. Find someone with approval permission on that resource.
3. Approve it in the portal or by CLI.
4. If it was rejected, create a new endpoint, since a rejected request cannot be revived.

az network private-endpoint-connection approve \
  --id <connection-resource-id> --description "Approved"

The endpoint and its NIC are removed and the private IP returns to the subnet. On the target, the connection moves to Disconnected. The target resource itself and its data are untouched.

What happens to DNS depends on how you set it up. A zone group removes the A record. Manually created records stay behind, and clients keep resolving to an IP that no longer answers.

If public access was disabled, the service is unreachable from that network until you recreate the endpoint.

Historically, NSG rules and UDRs were ignored for private endpoint traffic. You now opt in per subnet with the privateEndpointNetworkPolicies property.

az network vnet subnet update -g rg-net --vnet-name vnet-hub \
  -n snet-pe --private-endpoint-network-policies Enabled

Without this, the endpoint's /32 system route beats broader UDR prefixes, so firewall steering silently does not happen.

Peering makes the endpoint's private IP routable from the peered VNet, and global peering works across regions. Routing is only half of it, though.

The spoke must also resolve the service name to that private IP. Either link the private zone to the spoke VNet, or point the spoke at a central DNS forwarder or Private Resolver.

If the endpoint subnet has NSG policies enabled, the rules must allow the spoke's address range. Spoke-to-spoke access to a hub endpoint works because each spoke peers with the hub that hosts it.

You need the target's resource ID (or alias for a Private Link service) and an owner who will approve the request.

1. In the portal, choose Connect to an Azure resource by resource ID or alias, or use the CLI with --manual-request true.
2. Enter the resource ID, the group ID, and a request message.
3. The connection stays Pending until the other tenant's owner approves it.
4. Set up DNS in your own tenant so the name resolves to your endpoint IP.

Permissions are separate in each tenant, so approval is always manual across tenants.

Choose Private Link when any of these apply:

• On-premises clients must reach the service privately over VPN or ExpressRoute.
• You need access to a single resource, not the whole service.
• Compliance requires that the service has no public path.
• The target is in another region or tenant.

Service endpoints remain fine for simple Azure-only access where the public IP is acceptable, no DNS work is wanted, and cost matters, since they are free.

Keep DNS central. One copy of each privatelink zone lives in a connectivity subscription and is linked to the hub, and spokes use the hub resolver.

flowchart LR
  S["Spoke VMs"] --> R["Hub DNS Private Resolver"]
  O["On-premises DNS"] --> I["Inbound endpoint"]
  I --> R
  R --> Z["Central private DNS zones"]

• Spokes set the hub resolver as their DNS server, or link the zones directly.
• Endpoints in any spoke register A records in the central zones through their zone groups.
• Use Azure Policy (DeployIfNotExists) so new endpoints join the right zone automatically.

Duplicate zones per spoke cause split answers, which is the usual design mistake.

With VNet injection, the service's own compute is deployed into a subnet you provide, for example SQL Managed Instance, API Management in internal mode, or Databricks. You manage the subnet, its delegation, and its rules.

With a private endpoint, nothing of the service is deployed into your network. You only get a NIC that forwards privately to a service running elsewhere.

They solve opposite directions, and a fully private web app usually needs both.

DNS uses privatelink.azurewebsites.net, and the SCM (Kudu) site resolves through the same zone. Once the endpoint works, you can disable public access on the app.

Each storage service is a separate sub-resource, and one endpoint carries exactly one group ID. Using blob and file on the same account means two endpoints.

A data lake with hierarchical namespace is the classic case. Tools use both the blob and dfs endpoints, so you need an endpoint for each, plus the zones privatelink.blob.core.windows.net and privatelink.dfs.core.windows.net.

Only create the ones you use, since each endpoint is billed.

Use three kinds of policy effects at management group or subscription scope:

• Deny creation of resources that leave public network access enabled.
• Audit existing resources first, to see the impact before blocking.
• DeployIfNotExists to add the private DNS zone group to new endpoints so records register automatically.

Built-in definitions exist for most services, usually in the Network category. Roll out in audit mode, fix findings, then switch to deny. Use exemptions for the few resources that must stay public.

The limit is usually SNAT port capacity on the NAT IPs, since every consumer connection is translated.

1. Add NAT IP configurations. You can have up to 8, each adding about 64,000 ports.
2. Scale out the backend pool behind the Standard Load Balancer.
3. Watch for port exhaustion and unhealthy probes in metrics.
4. Enable TCP Proxy Protocol v2 if you need per-consumer visibility or throttling.

Front Door Premium can create a private endpoint from its own managed network to an origin such as a storage blob, an App Service, or an internal load balancer through a Private Link service.

1. Enable Private Link when adding the origin and give a request message.
2. The connection appears as Pending on the origin.
3. The origin owner approves it.
4. Disable public access on the origin so only Front Door can reach it.

Standard and Classic tiers do not support this.

Work through the path in order:

1. DNS: does the name resolve to the private IP?
2. State: is the connection Approved?
3. Port: can you open a TCP connection?
4. NSG/UDR: if network policies are on, do rules allow it?
5. Network Watcher: use connection troubleshoot or IP flow verify.
6. Target firewall: some services need the endpoint allowed explicitly.
7. On-premises: check routes over VPN or ExpressRoute.

Test-NetConnection mystorage.blob.core.windows.net -Port 443

Cost comes from two meters: an hourly charge per endpoint and a charge for data processed through it. Peering adds its own data charges.

• Share endpoints from a hub across spokes instead of one per app.
• Consolidate storage accounts where design allows.
• Delete orphaned or Disconnected endpoints.
• Use service endpoints for low-risk, Azure-only access.
• Use one AMPLS endpoint for Azure Monitor rather than several.

sequenceDiagram
  participant C as Consumer
  participant P as Azure control plane
  participant S as Private Link service
  C->>P: Create endpoint with alias
  P->>S: Check visibility
  S->>S: Match auto-approval list
  alt Subscription auto-approved
    S-->>C: Approved
  else Not listed
    S-->>C: Pending
    S->>S: Provider approves
    S-->>C: Approved
  end
  C->>S: Traffic via endpoint IP

Visibility decides who may request. The auto-approval list decides who skips manual approval. Once Approved, the NIC passes traffic to the service NAT IP and the load balancer.

A private endpoint adds a /32 system route in the VNet, with next hop type InterfaceEndpoint. A packet to the endpoint IP matches that route and is handled by Azure's software-defined network on the host, not by a gateway or appliance.

flowchart LR
  V["Client VM"] --> R["/32 route, InterfaceEndpoint/"]
  R --> N["Azure SDN on host"]
  N --> T["Target service"]

The path is one-way: only the consumer can start connections. The /32 route is also why it beats less specific UDRs unless network policies are enabled.

An endpoint lives in one region and points at one replica, so it does not fail over by itself. Pre-build the private path in the secondary region.

1. Create a VNet and subnet in the secondary region.
2. Create endpoints to the secondary replicas, for example blob_secondary for RA-GRS storage, or the secondary SQL server in a failover group.
3. Link the privatelink zones to both regions' VNets.
4. Test failover and DNS resolution regularly.

Out of the box, traffic goes straight to the endpoint because of its /32 route. To force it through the firewall:

1. Enable RouteTableEnabled or Enabled in privateEndpointNetworkPolicies on the endpoint subnet.
2. Add a UDR that sends the endpoint subnet prefix or endpoint IPs to the firewall.
3. Allow the flow with network rules on the private IP and port.
4. Turn on SNAT for these flows so return traffic stays symmetric.

The AKS cloud provider can create the Private Link service for you from annotations on an internal LoadBalancer Service.

apiVersion: v1
kind: Service
metadata:
  name: orders-api
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/azure-pls-create: "true"
    service.beta.kubernetes.io/azure-pls-name: "pls-orders"
spec:
  type: LoadBalancer
  ports:
    - port: 443
  selector:
    app: orders

Consumers then create a private endpoint to the service alias. Check the cloud-provider-azure docs for visibility and auto-approval annotations for your AKS version.