Technical Lab: Choose when to use a service endpoint
Questions
Question 1 — Multiple Choice
A development team maintains an application hosted in a subnet of a Virtual Network in Azure. This application needs to access an Azure Storage Account with the following requirement: traffic should not traverse the public internet, but the team wants to maintain operational simplicity without managing additional private IP addresses or private DNS zones.
Which approach best meets these requirements?
A) Configure a Private Endpoint for the Storage Account in the application subnet.
B) Enable a Service Endpoint of type Microsoft.Storage in the subnet and restrict the Storage Account firewall to accept only that subnet.
C) Associate a Network Security Group (NSG) to the subnet with an outbound rule blocking all traffic except to the Storage Account's public IP.
D) Use a User-Defined Route (UDR) to redirect Storage Account traffic through a Network Virtual Appliance (NVA).
Question 2 — Technical Scenario
An architect is reviewing the configuration below of a Virtual Network with Service Endpoints enabled:
VNet: vnet-prod (10.0.0.0/16)
Subnet: snet-app (10.0.1.0/24)
Service Endpoint: Microsoft.KeyVault
Subnet: snet-data (10.0.2.0/24)
No Service Endpoint configured
The Key Vault is configured with the following network policy:
Allow access from: Selected networks
Virtual Networks:
- vnet-prod / snet-app
Firewall (IP Rules): no rules
A VM in the snet-data subnet tries to access the Key Vault via SDK and receives a 403 Forbidden error. The architect claims that simply moving the VM to snet-app will solve the problem.
Is this statement correct? What is the most accurate technical explanation?
A) It's not correct. The Service Endpoint needs to be enabled in the Key Vault, not in the subnet.
B) It's correct. The Service Endpoint in snet-app ensures that any VM in it can access the Key Vault without additional authentication.
C) It's correct. Moving the VM to snet-app makes traffic exit through an authorized path, but the VM still needs identity permission (like RBAC) to access secrets.
D) It's not correct. Service Endpoints don't work with Azure Key Vault, only with Storage and SQL.
Question 3 — True or False
Statement: When a Service Endpoint is enabled in a subnet, resources within that subnet start accessing the target Azure service through a private IP address assigned to the subnet, completely eliminating the use of public IP addresses in the traffic path.
True or False?
Question 4 — Technical Scenario
A company has workloads in two regions: East US and West Europe. In East US, there's a VNet with Service Endpoint enabled for Microsoft.Sql. The Azure SQL database is hosted in West Europe.
The team observes that after enabling the Service Endpoint and restricting the SQL Server firewall to accept only the subnet from East US, application connections start failing intermittently.
What is the most likely cause of the problem?
A) Service Endpoints are restricted to the same region as the VNet and don't cover services in different regions by default, requiring explicit enablement of cross-region access in the endpoint or using another mechanism.
B) The Azure SQL firewall doesn't support restrictions by subnet from another region; only IP rules are accepted in these cases.
C) The Service Endpoint routes traffic through the public internet when source and destination are in different regions, which is blocked by the subnet's default NSG.
D) The failure occurs because Service Endpoints of type Microsoft.Sql require the database to be in the same subscription as the VNet.
Question 5 — Multiple Choice
When comparing Service Endpoints and Private Endpoints for protecting access to an Azure Storage Account from a VNet, which statement correctly describes a fundamental difference between the two approaches?
A) Service Endpoints expose the Storage Account with a private IP within the VNet, while Private Endpoints keep the service's public IP visible on the network.
B) With Service Endpoints, the Storage Account remains accessible from the public internet unless its firewall is explicitly configured to deny this access; with Private Endpoints, access is inherently restricted to the private scope.
C) Private Endpoints are managed at the subnet level, while Service Endpoints create a dedicated network resource with its own IP within the VNet.
D) Service Endpoints require a private DNS zone to function correctly, while Private Endpoints use Azure's default public DNS resolution.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
A Service Endpoint enabled in the subnet redirects traffic destined for the Azure service through Microsoft's backbone network, without exposure to the public internet. Combined with the Storage Account firewall restriction to accept only that subnet, the isolation requirement is met with minimal configuration.
Alternative A (Private Endpoint) also prevents internet traffic, but introduces a dedicated private IP, a NIC in the VNet, and in most cases, a private DNS zone for correct resolution. This goes beyond the simplicity required in the scenario.
Alternative C doesn't prevent internet routing; it only blocks certain destinations at the NSG level, without optimizing the traffic path. Alternative D adds unnecessary complexity and doesn't directly address the requirement of not traversing the public internet.
Answer Key — Question 2
Answer: C
The architect's statement is partially correct from a networking perspective: moving the VM to snet-app makes traffic exit through the subnet that has the Service Endpoint enabled and is authorized in the Key Vault firewall. This resolves the network blocking.
However, the Service Endpoint does not grant content access permission. Key Vault uses Azure RBAC (and legacy access policies) to control who can read, write, or list secrets. The VM still needs an identity with the appropriate role (e.g., Key Vault Secrets User). Alternative C captures both dimensions: the network path and identity control.
Alternative D is a common distractor, but incorrect: Service Endpoints support Microsoft.KeyVault normally. Alternative B is dangerous because it suggests that Service Endpoints replace authentication, which is never true.
Answer Key — Question 3
Answer: False
This is one of the most frequent confusions about Service Endpoints. Traffic does not use a private IP assigned to the subnet. What happens is that the source IP address of requests becomes the VNet's private IP (instead of the resource's public IP), but the target Azure service is still reached through its public endpoint (service's public IP), with traffic routed through Microsoft's backbone network.
This distinction is fundamental: Service Endpoints optimize the path and restrict who can access the service, but don't eliminate the service's public address. This is exactly why Private Endpoints exist as a complementary solution: they actually assign a private IP to the service within the VNet.
Answer Key — Question 4
Answer: A
By default, a Service Endpoint enabled in a subnet covers the service in the same region as the VNet. To access an Azure service in another region, it's necessary to verify if the endpoint type supports cross-regional access and, when supported, explicitly enable this option. For Microsoft.Sql, Azure offers support for paired regions, but this needs to be configured.
Since the SQL Server firewall was configured to accept only that subnet, and the Service Endpoint doesn't cover the service in the West Europe region by default, connections are rejected because traffic isn't recognized as originating from an authorized endpoint.
Alternative B is incorrect: Azure SQL firewall does support restrictions by subnet from other regions when the endpoint is correctly configured. Alternative C is incorrect because Service Endpoints always route through Microsoft's backbone, never through the public internet. Alternative D is a non-existent restriction.
Answer Key — Question 5
Answer: B
This is the most important operational difference between the two approaches. A Service Endpoint does not automatically disable public access to the service: the Storage Account continues with its public endpoint active. To restrict access, it's necessary to explicitly configure the service firewall to deny traffic that doesn't come from authorized networks. If this configuration is forgotten, the service remains accessible from the internet.
A Private Endpoint, on the other hand, creates a private network interface within the VNet with a dedicated IP. Access to the service through this endpoint is intrinsically private; public access can be disabled independently, but the Private Endpoint itself doesn't depend on additional firewall rules to ensure private route isolation.
Alternative A reverses the logic of the two solutions. Alternative C describes the opposite of what happens: it's the Private Endpoint that creates a dedicated network resource with its own IP, not the Service Endpoint. Alternative D reverses the DNS dependency: it's the Private Endpoint that typically requires a private DNS zone for correct resolution.