Skip to main content

Technical Lab: Create private endpoints

Questions​

Question 1 — Multiple Choice​

A development team needs an application hosted in a virtual network to access an Azure Storage account privately, without traffic going through the public internet. After creating the private endpoint for the storage account, tests show that the endpoint's name resolution still returns the public IP address of the service.

What is the most likely cause of this behavior?

A) The private endpoint was created in a subnet that doesn't have a Network Security Group (NSG) associated.

B) Integration with Private DNS Zone was not configured, and the client's DNS continues to resolve the service FQDN to the public IP.

C) The storage resource doesn't have the firewall enabled, so private routing is not automatically activated.

D) The private endpoint needs to be associated with a Public IP to function as the virtual network's entry point.

Question 2 — Technical Scenario​

A company has the following configuration:

Virtual Network: vnet-prod (10.0.0.0/16)
  Subnet: snet-data (10.0.1.0/24)
    - Private Endpoint: pe-sqldb → points to Azure SQL Database
    - Network Security Group: nsg-data (associated with subnet)

NSG Rules (Inbound):
  Priority 100 | Source: 10.0.0.0/16 | Dest: * | Port: 443 | Allow
  Priority 200 | Source: *           | Dest: * | Port: *   | Deny

The application in subnet snet-app (10.0.2.0/24) cannot connect to the SQL Database via private endpoint on port 1433. DNS resolves correctly to the private IP 10.0.1.5.

What is the cause of the problem?

A) The NSG is blocking port 1433, as the Allow rule only covers port 443.

B) Private endpoints don't work in subnets that have NSG associated by default.

C) The snet-data subnet needs to have Network Policies enabled for the NSG to be respected by the private endpoint.

D) The SQL Database FQDN must be manually registered in the application's hosts file when NSGs are present.

Question 3 — True or False​

When creating a private endpoint for an Azure service, it's possible for the same resource (for example, a storage account) to have multiple private endpoints associated with different virtual networks, including in distinct Azure regions.

True or False?

Question 4 — Technical Scenario​

An architect needs to expose an internal service developed by the company itself, hosted behind an Azure Standard Load Balancer internal, so that business partners in other subscriptions can consume it privately, without VNet Peering.

After reviewing available options, he considers creating a private endpoint in the partners' environments.

Which Azure resource must be configured on the provider side to make this possible?

A) A Virtual Network Gateway with transit routing mode enabled.

B) An Azure Private Link Service, associated with the internal Standard Load Balancer, to expose the service as a target for private endpoints.

C) A Service Endpoint in the provider's subnet, with access policy restricted to partner subscriptions.

D) An Azure Application Gateway with WAF, configured as frontend for the internal service.

Question 5 — Multiple Choice​

When provisioning a private endpoint, the administrator needs to choose the target sub-resource during creation. In the case of an Azure Storage account, different sub-resources represent distinct endpoints.

Which statement correctly describes the behavior of this model?

A) Each sub-resource corresponds to an independent storage service (blob, file, queue, table), and a single private endpoint covers all of them simultaneously.

B) The sub-resource defines which storage service will be accessed via private IP; to access blob and file privately, two separate private endpoints are required.

C) The sub-resource is just an organizational label and doesn't affect traffic routing or DNS resolution.

D) A private endpoint created for the blob sub-resource also automatically enables private access to the dfs sub-resource, making it unnecessary to create a second endpoint for Data Lake Storage Gen2.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

Explanation:

  • The private endpoint receives a private IP within the subnet, but for clients to resolve the service FQDN to this private IP, it's necessary to integrate the correct Private DNS Zone (for example, privatelink.blob.core.windows.net for Storage Blob). Without this integration, Microsoft's public DNS returns the service's public IP, and traffic never reaches through the private path.
  • Alternative A is incorrect because the absence of NSG doesn't prevent name resolution; it only impacts packet flow. Alternative C confuses resource firewall (which controls access) with DNS resolution. Alternative D is conceptually wrong: private endpoints are, by definition, entities without public IP.
  • Choosing the wrong alternative in this scenario would result in traffic continuing through the public internet, violating security requirements and possibly generating unexpected egress costs.

Answer Key — Question 2​

Answer: A

Explanation:

  • The NSG Allow rule exclusively covers port 443. Azure SQL Database uses port 1433 (TCP), which is not covered by any permissive rule. The Deny rule at priority 200 blocks all other traffic, including port 1433.
  • Alternative B inverts reality: NSGs work in subnets with private endpoints normally, as long as Network Policies are enabled. By default, they are disabled, which means the NSG would be ignored. However, since DNS already resolves correctly and the problem is connectivity at the transport layer, the described behavior points to port blocking, not disabled policy. Alternative C addresses exactly this detail: with disabled policies, the NSG wouldn't be applied, which would produce the opposite effect (connection working even without explicit rule). Alternative D has no technical foundation.
  • This scenario reinforces that reviewing NSG rules by specific port is essential before investigating more complex causes.

Answer Key — Question 3​

Answer: True

Explanation:

  • The same Azure resource can be the target of multiple private endpoints without quantity restriction by design. Each private endpoint resides in a specific virtual network subnet and receives its own private IP in that address space. There's no impediment for virtual networks in different regions to create their own private endpoints pointing to the same resource.
  • This behavior is precisely what enables multi-region or multi-subscription architectures where the same centralized service is consumed privately by multiple isolated environments.
  • The non-obvious point here is that the limitation of "one endpoint per network" doesn't exist; what must be managed is the private DNS zone in each environment to ensure correct resolution in each consumer network.

Answer Key — Question 4​

Answer: B

Explanation:

  • The Azure Private Link Service is the component that allows a service provider to expose it as a destination for private endpoints in third-party subscriptions. It's associated with the Standard Load Balancer internal (not Basic), and generates an alias that consumers use when creating their private endpoints, without needing peering or direct connectivity between VNets.
  • Alternative A deals with network connectivity between sites, not service exposure via Private Link. Alternative C uses Service Endpoints, which are a different mechanism: they extend the virtual network's identity to the service, but don't create a routable private IP for third parties in other subscriptions. Alternative D introduces a load balancing and WAF component that doesn't solve the isolation requirement between subscriptions without peering.
  • Understanding the distinction between Private Link Service (provider side) and private endpoint (consumer side) is fundamental for designing shared service architectures in Azure.

Answer Key — Question 5​

Answer: B

Explanation:

  • Each sub-resource of a storage account represents an independent service endpoint: blob, file, queue, table, web, dfs. When creating a private endpoint, the administrator selects exactly which of these services will be exposed via private IP. For private access to two distinct services, such as blob and file, two separate private endpoints are required, each with its own DNS entry in the corresponding zone.
  • Alternative A is wrong because a single private endpoint does not cover multiple sub-resources simultaneously. Alternative C is wrong because the sub-resource directly determines which DNS entry is created (for example, privatelink.blob.core.windows.net versus privatelink.file.core.windows.net) and therefore affects resolution and routing. Alternative D is incorrect: blob and dfs are distinct sub-resources; an account with hierarchical namespace (Data Lake Gen2) requires a specific private endpoint for dfs if access via ADLS needs to be private.
  • This granular model gives the administrator precise control over which data planes are accessible through the private network, without exposing unnecessary services.