Skip to main content

Technical Lab: Configure access to service endpoints

Questions​

Question 1 — Multiple Choice​

An infrastructure team needs to ensure that a virtual machine in a specific subnet accesses Azure Storage directly through Microsoft's network, without going through the public internet. At the same time, the Storage Account should reject connections originating from other subnets or from the internet.

Which combination of configurations correctly meets this requirement?

A) Enable the Service Endpoint for Microsoft.Storage on the VM's subnet and, in the Storage Account, configure a virtual network rule allowing only that subnet.

B) Enable the Service Endpoint for Microsoft.Storage on the VM's subnet and leave the Storage Account with public access enabled for all networks.

C) Create a Private Endpoint for the Storage Account in the VM's subnet and enable the Service Endpoint for Microsoft.Storage on the same subnet as redundancy.

D) Enable the Service Endpoint for Microsoft.Storage at the entire VNet level and configure the Storage Account to accept traffic only from the VNet's public IP addresses.

Question 2 — Technical Scenario​

An engineer configures a Service Endpoint for Microsoft.Sql on a subnet and updates the Azure SQL Database rules to allow access only from that subnet. After configuration, the VMs in the subnet can access the database normally. However, an application hosted on Azure App Service (on a different plan, without VNet integration) starts receiving connection refused errors.

What is the most likely cause of this behavior?

A) The Service Endpoint changed the source IP address of the VMs, causing the SQL firewall to recognize only the new service prefix and block other sources.

B) The App Service uses public IP addresses to communicate with the SQL Database, and the network rule now restricts access only to the subnet with Service Endpoint configured.

C) The Service Endpoint automatically disabled existing IP-based firewall rules on the Azure SQL Database, blocking all external connections.

D) The absence of a Service Endpoint on the App Service prevents any outbound traffic from reaching the Azure SQL Database, regardless of firewall rules.

Question 3 — True or False​

Enabling a Service Endpoint on a subnet assigns the subnet a dedicated public IP address, which the destination service uses to identify and authorize traffic coming from that subnet.

Question 4 — Technical Scenario​

Consider the configuration below applied to a subnet in an Azure VNet:

{
  "serviceEndpoints": [
    {
      "service": "Microsoft.Storage",
      "locations": ["brazilsouth"]
    }
  ]
}

A developer reports that VMs in this subnet can access the Storage Account located in brazilsouth, but fail when trying to access a second Storage Account located in eastus, even though both accounts are configured to accept the subnet.

What is the cause of the problem and how to fix it?

A) The Service Endpoint is configured only for the brazilsouth region; it's necessary to add the eastus region or use the value * to cover all regions.

B) The Service Endpoint doesn't support multiple Storage Accounts per subnet; it's necessary to create a separate subnet for each storage account.

C) The Storage Account in eastus needs a Service Endpoint of type Microsoft.Storage.Global instead of Microsoft.Storage.

D) The problem is in the network rules of the Storage Account in eastus, which need to reference the complete Resource ID of the subnet, not just the name.

Question 5 — Multiple Choice​

When comparing Service Endpoints and Private Endpoints for access to Azure PaaS services, which statement correctly describes a fundamental difference between the two features?

A) The Service Endpoint exposes the PaaS service through a private IP address within the VNet, while the Private Endpoint routes traffic through Microsoft's backbone without changing the destination IP address.

B) The Private Endpoint creates a network interface with private IP within the VNet for the service, while the Service Endpoint maintains the service's public IP address as destination, but routes traffic through Microsoft's backbone.

C) The Service Endpoint and Private Endpoint offer the same connectivity model, differing only in cost and the need for custom DNS.

D) The Private Endpoint requires prior enabling of a Service Endpoint on the subnet to work, as it depends on the optimized route through Microsoft's backbone created by the Service Endpoint.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: A

Explanation:

Enabling the Service Endpoint for Microsoft.Storage on the subnet makes traffic originating from that subnet toward Azure Storage be routed through Microsoft's backbone, and the source IP address seen by the service becomes the subnet prefix (virtual network identity), not a public IP.

For the Storage Account to reject all other sources, it's necessary to combine the Service Endpoint with a virtual network rule in the Storage Account firewall explicitly pointing to that subnet. Without this rule, the Service Endpoint by itself doesn't restrict access.

Alternative B ignores the need for restriction at the destination. Alternative C confuses the two features: Private Endpoint and Service Endpoint have distinct architectures and don't complement each other for redundancy. Alternative D is incorrect because Service Endpoints are enabled per subnet, not per VNet, and Storage Accounts don't filter by public IP addresses of VNets.

Answer Key — Question 2​

Answer: B

Explanation:

When the Azure SQL Database has its network configured to accept only connections coming from a subnet with Service Endpoint, connections from sources external to the VNet are blocked. The Azure App Service, without VNet integration configured, makes outbound calls using public IP addresses managed by Microsoft, which don't belong to the authorized subnet.

The misconception represented by alternative A is common: the Service Endpoint doesn't change the source IP of VMs in a way that blocks other sources; it only ensures that subnet traffic uses the backbone and is identified by the subnet prefix at the destination. Alternative C is false: the Service Endpoint doesn't disable existing firewall rules. Alternative D is incorrect because the App Service can have outbound blocked by the SQL firewall, but the cause is not the absence of Service Endpoint on the App Service itself.

Answer Key — Question 3​

Answer: False

Explanation:

The Service Endpoint does not assign a dedicated public IP address to the subnet. What occurs is different: traffic starts being routed through Microsoft's backbone to the destination service, but the destination IP address is still the service's public address. From the destination service's perspective (like Azure Storage), the identified source is the subnet's private address prefix (the VNet's address space), not a dedicated public IP.

This distinction is central to understanding why the Service Endpoint doesn't offer network isolation as strong as the Private Endpoint, which does provision an interface with private IP within the VNet.

Answer Key — Question 4​

Answer: A

Explanation:

The locations property in the Service Endpoint defines in which regions the endpoint is active. A configuration with "locations": ["brazilsouth"] enables optimized routing through the backbone only for service instances in that region. Attempts to access a Storage Account in eastus through the same Service Endpoint fail because the endpoint doesn't cover that region.

The fix is to add "eastus" to the locations array or use "*" to cover all regions, depending on the adopted security policy.

Alternative B is incorrect: there's no limit of Storage Accounts per subnet via Service Endpoint. Alternative C is a plausible distractor, but Microsoft.Storage.Global is not a valid Service Endpoint type for this scenario. Alternative D diverts the problem to the Storage Account rules, which doesn't correspond to the root cause described in the scenario.

Answer Key — Question 5​

Answer: B

Explanation:

This is the fundamental architectural difference between the two features:

AspectService EndpointPrivate Endpoint
Destination IP addressService's public IPPrivate IP within the VNet
Network interface created in VNetNoYes (NIC with private IP)
Need for private DNSNoYes (recommended)
Service accessible from internetCan be, if not restrictedNo, by default

Alternative A reverses the definitions of the two features. Alternative C is incorrect because the connectivity models are fundamentally different: the Private Endpoint isolates the service in the private network, while the Service Endpoint only optimizes routing without removing the service's public endpoint. Alternative D is a frequent misconception: the Private Endpoint is independent of the Service Endpoint and doesn't require it to be previously enabled on the subnet.