4 of the 10 questions we have for this objective, shown with the answer and the reasoning.
Design and implement Azure Private Link service and Azure private endpoints
Tidewater Media creates a private endpoint named pe-sttidewaterarchive-blob that targets the blob sub-resource of the storage account sttidewaterarchive. The endpoint is placed in VNet-Media, which uses the default Azure-provided DNS. The team wants the private endpoint to add a private DNS zone group so that the FQDN sttidewaterarchive.blob.core.windows.net resolves to the private IP address for all virtual machines in VNet-Media.
Which private DNS zone should you create and link to VNet-Media?
- Aprivatelink.blob.core.windows.netThe public name sttidewaterarchive.blob.core.windows.net resolves to a CNAME in the privatelink.blob.core.windows.net zone, so the private zone must use exactly that name for Azure DNS to return the private IP address.
- Bblob.core.windows.netCreating a private zone with the public zone name would override every storage account name in the VNet and break resolution for all other blob endpoints; it is not the recommended zone.
- Cprivatelink.file.core.windows.netThis is the correct zone for the file sub-resource (Azure Files), not for blob.
- Dprivatelink.core.windows.netThere is no single privatelink zone for all storage services; each sub-resource has its own zone such as privatelink.blob.core.windows.net or privatelink.queue.core.windows.net.
Why: Private endpoint DNS integration relies on the fact that the public FQDN of a Private Link enabled resource returns a CNAME to a privatelink subdomain. If a private DNS zone with that exact privatelink name is linked to the virtual network, Azure DNS answers the query with the A record for the private endpoint instead of continuing to the public IP. A private DNS zone group attached to the private endpoint keeps that A record up to date automatically. The deciding detail is the sub-resource: blob maps to privatelink.blob.core.windows.net, and every other storage service has its own zone, so the file zone and the generic names are the traps.
Design and implement Azure Private Link service and Azure private endpoints
Orchard Payments runs a licensing API on four virtual machines in subnet snet-api (10.80.1.0/24) of VNet-Provider. Partner companies in other Microsoft Entra tenants must consume the API through private endpoints in their own virtual networks, and the API must never be exposed on a public IP address. You are preparing VNet-Provider so that an Azure Private Link service can be created in front of the API.
Which three actions should you perform? Each correct answer presents part of the solution.
- APlace the virtual machines behind a Standard SKU internal Azure Load Balancer with a frontend IP in VNet-Provider.A Private Link service can only be attached to the frontend IP configuration of a Standard SKU internal load balancer; this is the mandatory anchor for the service.
- BPlace the virtual machines behind a Basic SKU internal Azure Load Balancer.Basic load balancers are not supported by Private Link service, and the Basic SKU is retired for new deployments.
- CCreate a subnet named snet-pls-nat (10.80.9.0/27) and set privateLinkServiceNetworkPolicies to Disabled on it.The Private Link service needs NAT IP addresses from a subnet in the provider VNet, and network policies for Private Link service must be disabled on that subnet before the service can be created.
- DCreate the Private Link service and reference the frontend IP configuration of the load balancer and the NAT subnet.The Private Link service resource binds the load balancer frontend to one or more NAT IP addresses; this is what produces the alias that partners use to create their private endpoints.
- ECreate a public Standard Load Balancer and restrict its frontend with a network security group.Private Link service requires an internal load balancer; a public frontend would expose the API on the internet, which the scenario forbids.
Why: Azure Private Link service lets a provider publish a service that sits behind a Standard internal load balancer so that consumers in any subscription or tenant can reach it through a private endpoint. Three building blocks are required: the Standard internal load balancer, a NAT subnet with privateLinkServiceNetworkPolicies disabled that supplies the source NAT addresses the backend sees, and the Private Link service itself, which references the load balancer frontend and the NAT subnet. The deciding constraints are cross-tenant consumption and no public exposure, which rule out a public load balancer. The Basic SKU is the classic SKU trap; it is neither supported by Private Link service nor available for new deployments.
Design and implement Azure Private Link service and Azure private endpoints
Granite Retail connects its datacenter to VNet-Hub (10.100.0.0/16) through ExpressRoute private peering. VNet-Hub is linked to the private DNS zone privatelink.database.windows.net, which holds records for several Azure SQL private endpoints. On-premises Windows DNS servers currently forward unknown names to the internet, so on-premises clients resolve sql-granite-orders.database.windows.net to a public IP and are refused. The solution must not require administrators to maintain copies of the private endpoint records on the on-premises DNS servers.
Which two actions should you perform? Each correct answer presents part of the solution.
- ADeploy an Azure DNS Private Resolver in VNet-Hub with an inbound endpoint in a dedicated subnet such as snet-dns-in (10.100.250.0/28).The inbound endpoint gives on-premises resolvers a routable private IP address in Azure that answers queries using Azure DNS, including the linked private zones.
- BConfigure a conditional forwarder on the on-premises DNS servers for database.windows.net that forwards to the inbound endpoint IP address.Forwarding the public zone name to Azure lets Azure DNS follow the CNAME into privatelink.database.windows.net and return the private IP, with no records to maintain on-premises.
- CConfigure a conditional forwarder on the on-premises DNS servers for database.windows.net that forwards to 168.63.129.16.168.63.129.16 is a virtual IP that is reachable only from inside an Azure virtual network; on-premises resolvers cannot reach it over ExpressRoute.
- DCreate a primary zone named privatelink.database.windows.net on the on-premises DNS servers and add A records for each private endpoint.This resolves the names but requires administrators to copy and maintain every record manually, which the scenario explicitly rules out.
- EDeploy an Azure DNS Private Resolver outbound endpoint and a ruleset that forwards database.windows.net to the on-premises DNS servers.An outbound endpoint sends queries from Azure to on-premises; the requirement is the reverse direction, so the ruleset would not help on-premises clients.
Why: On-premises clients cannot query Azure-provided DNS directly, so you need a resolver inside the virtual network that is reachable over the private connection. The Azure DNS Private Resolver inbound endpoint fills that role without any virtual machines, answering from the private DNS zones linked to its virtual network. The on-premises servers then forward the public zone name, database.windows.net, to that inbound endpoint so that Azure DNS can follow the CNAME chain into privatelink.database.windows.net. The deciding constraint is no manual record maintenance, which eliminates hosting the privatelink zone on-premises. The common traps are forwarding to 168.63.129.16, which is not routable from outside Azure, and confusing the inbound and outbound endpoint directions.
Design and implement Azure Private Link service and Azure private endpoints
Granite Retail has a private endpoint for the Azure SQL server sql-granite-orders in subnet snet-pe of VNet-App (10.90.0.0/16). A private DNS zone named privatelink.database.windows.net exists in the resource group rg-dns and contains an A record for sql-granite-orders that points to 10.90.8.4. Virtual machines in VNet-App use Azure-provided DNS, yet nslookup sql-granite-orders.database.windows.net on those machines returns a public IP address, and connections fail because public network access is disabled on the server.
What should you do?
- AAdd a private DNS zone group to the private endpoint that references the privatelink.database.windows.net zone.A zone group only keeps the A record in the zone up to date, and the record already exists; it does not link the zone to VNet-App, so queries from the VNet still bypass the zone.
- BCreate a virtual network link named link-vnet-app in the privatelink.database.windows.net zone that targets VNet-App.A private DNS zone only answers queries from virtual networks it is linked to. The zone and record are correct, so the missing piece is the virtual network link to VNet-App; Azure DNS then returns 10.90.8.4 when following the public CNAME.
- CChange the connection string to use sql-granite-orders.privatelink.database.windows.net.Clients must keep using the public FQDN; Azure SQL rejects logins that use the privatelink FQDN by design, because the SQL gateway needs the server.database.windows.net name to route the login, and the name would still not resolve until the zone is linked to VNet-App.
- DCreate a CNAME record for sql-granite-orders in the public database.windows.net zone that points to the private endpoint.You do not own the public database.windows.net zone, and a CNAME cannot point to an IP address; the public CNAME to the privatelink name already exists and is managed by Microsoft.
Why: A private DNS zone has no effect on a virtual network until a virtual network link is created between the zone and that network. In this scenario the zone name and the A record are already correct, and the machines use Azure-provided DNS, so the only reason the public CNAME chain ends at a public IP is that VNet-App is not linked to privatelink.database.windows.net. The deciding clue is that the zone lives in a different resource group, which often means it was created for another network and never linked to this one. Using the privatelink name directly in the connection string is a trap: Azure SQL rejects logins that use the privatelink FQDN, and the name still would not resolve.