Technical Lab: Configure access to private endpoints
Questions
Question 1 — Multiple Choice
A development team needs an application hosted in a VNet to access an Azure Storage account via Private Endpoint. After creating the endpoint, the application continues to resolve the storage account name to the public IP. What is the most likely cause of this behavior?
A. The Private Endpoint was created in a different subnet from the application, which prevents private resolution.
B. Integration with a Private DNS Zone was not configured, so the public DNS still responds to queries.
C. The Network Security Group of the subnet blocks traffic on port 443, preventing communication with the endpoint.
D. The A record of the Private DNS Zone was manually created with the public IP instead of the private IP of the endpoint.
Question 2 — Technical Scenario
An organization configured a Private Endpoint for an Azure SQL Database in a production VNet. Now they want to allow VNets from other regions to access the same endpoint. The current topology uses VNet Peering between the VNets. The team reports that the peered VNets cannot resolve or reach the private endpoint.
What is the correct action to resolve the name resolution problem?
A. Create a new Private Endpoint in each destination VNet, pointing to the same Azure SQL Database.
B. Link the Private DNS Zone of the endpoint to the VNet of each region that needs access.
C. Enable the "Allow Gateway Transit" option in the peering to automatically propagate private DNS zones.
D. Recreate the Private Endpoint with global scope enabled, which extends DNS resolution to peered VNets automatically.
Question 3 — True or False
After disabling public network access on an Azure resource (such as a storage account or Azure SQL Database), any client outside the VNet where the Private Endpoint is provisioned completely loses the ability to reach the resource, even if the client has the correct credentials and is on a network connected via VPN Gateway to the same VNet.
Question 4 — Technical Scenario
A network engineer executes the following command on a VM within the VNet where the Private Endpoint was created:
nslookup minha-conta.blob.core.windows.net
The returned output is:
Server: 168.63.129.16
Address: 168.63.129.16
Non-authoritative answer:
Name: minha-conta.privatelink.blob.core.windows.net
Address: 52.168.112.45
The address 52.168.112.45 is a public IP. The Private Endpoint was created and has Succeeded status. What is the correct diagnosis?
A. The Private Endpoint has pending approval status, which is why traffic is still routed to the public IP.
B. The Private DNS Zone privatelink.blob.core.windows.net is not linked to the VM's VNet, therefore the public DNS responds to the CNAME query.
C. Azure DNS (168.63.129.16) is not compatible with Private Endpoint resolutions and should be replaced with a custom DNS.
D. The storage account still has public access enabled, which makes Azure DNS always prefer the public IP.
Question 5 — Multiple Choice
When creating a Private Endpoint, the Target sub-resource field varies according to the destination service. For an Azure Storage account, there are multiple available sub-resources (blob, file, queue, table, dfs, web). What is the direct consequence of creating only one Private Endpoint pointing to the blob sub-resource?
A. Private access is restricted only to the SMB protocol; other protocols continue using the public endpoint.
B. Only the Blob service endpoint receives a private IP; other services in the account (file, queue, etc.) remain accessible only through the public endpoint.
C. Azure automatically blocks all other sub-resources of the storage account as a complementary security measure.
D. The Private Endpoint covers all sub-resources of the storage account, since the parent resource is the account itself, not the individual service.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Integration with a Private DNS Zone is the mechanism that replaces public DNS resolution with the private IP of the endpoint. When the Azure resource is accessed by its default hostname (e.g., minha-conta.blob.core.windows.net), Azure responds with an intermediate CNAME in the privatelink domain. If a corresponding Private DNS Zone is not linked to the VNet, this CNAME continues to be resolved by public DNS, returning the public IP of the service.
Option A is wrong because different subnets within the same VNet do not prevent DNS resolution. Option C would describe a connectivity failure, not name resolution. Option D is technically unlikely as an operational error, since automatic integration creates the A record with the correct IP of the Private Endpoint's NIC.
Answer Key — Question 2
Answer: B
VNet Peering allows layer 3 connectivity between VNets, but does not propagate DNS configurations between them. Each VNet resolves names using its own configured DNS servers. For peered VNets to resolve the Private Endpoint name to the private IP, the Private DNS Zone must be linked to each VNet that needs to perform the resolution.
Option A would create unnecessary redundant endpoints and generate additional private IPs, which is not the correct approach for the described scenario. Option C confuses "Allow Gateway Transit" with DNS propagation; these mechanisms are independent. Option D does not exist: Private Endpoints do not have global scope that automatically propagates DNS.
Answer Key — Question 3
False
The statement is false. A client on a network connected via VPN Gateway to the VNet where the Private Endpoint is provisioned can reach the resource, since traffic traverses the VPN tunnel and reaches the VNet as if the client were locally connected to it. The critical point is that the client will also need to resolve the name to the private IP, which requires that the DNS server used by the on-premises client forward queries for the privatelink domain to Azure DNS or to a DNS resolver within the VNet. Disabling public access protects against internet access, not against access via properly configured private connectivity.
Answer Key — Question 4
Answer: B
The nslookup output shows that the DNS server 168.63.129.16 (Azure DNS) resolved the CNAME privatelink.blob.core.windows.net to a public IP. This indicates that Azure DNS did not find a private A record for this domain within the VNet context, which happens when the Private DNS Zone privatelink.blob.core.windows.net is not linked to the VM's VNet. Without this link, Azure DNS forwards the resolution to public DNS servers, which return the IP of the storage's public endpoint.
Option A is unlikely, since the problem statement indicates "Succeeded" status. Option C is wrong: 168.63.129.16 is Azure's default resolver and is fully compatible with Private Endpoints when the DNS zone is correctly linked. Option D is incorrect because the described behavior is about DNS resolution, not preference based on public access availability.
Answer Key — Question 5
Answer: B
Each sub-resource of a storage account represents a distinct service endpoint with its own FQDN and therefore requires a separate Private Endpoint and an entry in the corresponding Private DNS Zone. Creating a Private Endpoint for blob exposes only *.blob.core.windows.net via private IP. Other services (file, queue, table, etc.) remain resolving to public IPs, unless public access has been explicitly disabled or additional Private Endpoints have been created for them.
Option A confuses sub-resources with transport protocols. Option C is incorrect: Azure does not automatically block other sub-resources when creating a Private Endpoint. Option D represents the most common misconception: believing that the Private Endpoint covers the entire resource, when in fact it is always created at the sub-resource level.