Technical Lab: Configure service endpoints for Azure platform as a service (PaaS)
Questions
Question 1 — Multiple Choice
A development team needs to ensure that an Azure SQL Database is accessible only from a specific subnet in a Virtual Network, without exposing the service to the public internet. The administrator enables a service endpoint for Microsoft.Sql on the subnet.
What is the immediate effect of this configuration from a network traffic perspective?
A) Traffic between the subnet and Azure SQL Database now flows through a private IP address within the VNet, completely eliminating any route through the internet.
B) Traffic remains on Microsoft's backbone network, but the source IP address visible to Azure SQL Database is still the subnet's public address.
C) Traffic now uses a private IP address dynamically allocated within the subnet, replacing the VNet's public address.
D) The service endpoint redirects traffic via VPN Gateway, ensuring additional encryption between the subnet and the PaaS service.
Question 2 — Technical Scenario
An administrator configures a service endpoint for Microsoft.Storage on a subnet called snet-app. Then, accesses the Storage Account and adds the following firewall rule to the resource:
Virtual networks: snet-app (VNet: vnet-prod)
Firewall: No public IP added
Default action: Deny
After the configuration, an application hosted on a VM within snet-app tries to access the Storage Account and receives a connection refused error.
What is the most likely cause of the problem?
A) The service endpoint for Microsoft.Storage has not propagated yet, as the process can take up to 24 hours to take effect.
B) The VM is using a Network Security Group (NSG) that blocks outbound traffic on port 443 for the Storage service prefix.
C) The service endpoint was enabled on the subnet, but the Storage Account still doesn't have the network rule configured to allow traffic originating specifically from snet-app.
D) The Storage Account with Default action: Deny requires a Private Endpoint and is not compatible with service endpoints.
Question 3 — True or False
A service endpoint enabled on a subnet automatically protects the associated PaaS service, blocking all external internet access as soon as it is activated, regardless of any additional configuration on the destination resource.
(True / False)
Question 4 — Technical Scenario
An organization uses the following architecture:
VNet A (East US region)
snet-backend --> service endpoint: Microsoft.KeyVault
VNet B (West US region) [peering with VNet A]
snet-frontend
An application hosted on snet-frontend (VNet B) needs to access Azure Key Vault configured to accept connections only via service endpoint from snet-backend.
The administrator claims that, since there is peering between the VNets, traffic from snet-frontend will be automatically forwarded through the service endpoint of snet-backend and access to Key Vault will be allowed.
What is the error in this statement?
A) Peering between VNets in different regions is not supported by Azure, so the connectivity itself is invalid.
B) Service endpoints are not transitive: traffic originating from snet-frontend does not use the endpoint configured in snet-backend, and Key Vault will reject the connection.
C) Azure Key Vault does not support service endpoints, only Private Endpoints, making the entire configuration invalid.
D) VNet peering requires that the service endpoint be enabled on the entire VNet, not on individual subnets, which invalidates the current configuration.
Question 5 — Multiple Choice
An administrator needs to decide between using a service endpoint or a Private Endpoint to expose an Azure Storage Account exclusively to internal workloads. Considering the criteria below, which scenario technically justifies choosing the service endpoint instead of the Private Endpoint?
| Criteria | Scenario requirement |
|---|---|
| Private IP in VNet namespace | Not mandatory |
| On-premises access via VPN | Not necessary |
| Solution cost | Minimize |
| Access scope | Only one subnet |
A) When the requirement is that the Storage Account has a private IP address resolvable via DNS within the VNet.
B) When the solution must support access to the Storage Account from an on-premises network connected via ExpressRoute.
C) When the goal is to restrict access to the Storage Account to a specific subnet with the lowest cost and no need for a dedicated private IP.
D) When the organization requires that traffic to the Storage Account never transits through Microsoft's public backbone, even logically.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
When a service endpoint is enabled, traffic between the subnet and the PaaS service is routed directly through Microsoft's backbone, without passing through the public internet. However, the source IP address that the PaaS service sees is still the VNet's public IP address, not a private IP.
Alternative A describes the behavior of a Private Endpoint, not a service endpoint. With Private Endpoint, the service receives a private IP within the VNet and traffic never uses public address. Alternative C invents a dynamic private IP allocation behavior that doesn't exist. Alternative D confuses service endpoint with VPN Gateway, which are completely distinct mechanisms.
Understanding this distinction is critical for correctly choosing between service endpoint and Private Endpoint in scenarios that require private IP for DNS resolution or on-premises access.
Answer Key — Question 2
Answer: B
The service endpoint configuration and Storage Account firewall rule are correct. The overlooked point is the NSG on the subnet or VM's NIC. By default, NSGs block outbound traffic that is not explicitly allowed. After enabling a service endpoint, it's necessary to add an outbound rule in the NSG that allows traffic to the corresponding Service Tag (in this case, Storage), if the outbound policy is restrictive.
Alternative A is false: service endpoints take effect within minutes, not 24 hours. Alternative C describes a real configuration error, but the statement explicitly affirms that the network rule was added correctly. Alternative D is incorrect because service endpoints and Default action: Deny are fully compatible.
Answer Key — Question 3
Answer: False
Enabling a service endpoint on a subnet does not automatically restrict access to the PaaS service. The endpoint only changes traffic routing and enables the possibility of using VNet-based rules on the destination resource. To effectively block external access, you must separately configure firewall or virtual network rules on the PaaS resource itself (such as Storage Account, Key Vault, or SQL Database), setting Default action: Deny and allowing only the desired subnets.
Confusing endpoint activation with automatic access restriction application is one of the most common operational errors on this topic, and can result in PaaS resources exposed to the internet even after the endpoint is enabled.
Answer Key — Question 4
Answer: B
Service endpoints are not transitive. Each subnet that needs access to a PaaS service via endpoint must have the endpoint enabled directly on it. The fact that VNet A and VNet B are peered does not make traffic originating from snet-frontend be treated as if it came from snet-backend.
In practice, Key Vault will receive the connection with origin from snet-frontend, which doesn't have endpoint enabled nor is listed in Key Vault's network rules, resulting in rejection. Alternative A is false: Global VNet Peering between different regions is supported. Alternative C is false: Key Vault supports both service endpoints and Private Endpoints. Alternative D describes a behavior that doesn't exist in Azure; endpoints are configured per subnet, and this granularity is valid and expected.
Answer Key — Question 5
Answer: C
The service endpoint is the technically appropriate choice when the requirements are: restrict access to a specific subnet, minimize costs (service endpoints have no additional cost, unlike Private Endpoints which charge per hour and per data processed) and there's no need for dedicated private IP or access from on-premises networks.
Alternative A describes exactly the use case for a Private Endpoint, which is the only one that provides a private IP resolvable via DNS within the VNet. Alternative B also requires Private Endpoint, as service endpoints are not reachable from on-premises networks via VPN or ExpressRoute. Alternative D is a requirement that neither service endpoint nor Private Endpoint meets as described: traffic always uses Microsoft's infrastructure, but service endpoints still use public IPs logically.