5.2.1. Service Endpoint Configuration

A service endpoint changes how a subnet reaches an Azure service, not what the service is called. Once enabled, Azure installs a more specific system route for that service's prefixes pointing at the Microsoft backbone, and the subnet's traffic stops leaving through the internet path. The service still keeps its public IP and public DNS name — only the route changes. That single fact explains almost every service endpoint exam answer.

Because the source address the service now sees is the VM's private IP rather than a SNAT'd public one, the service's own firewall has to be told to trust the subnet. This is why configuration is always two-sided:

Steps:

1. Enable the service endpoint on the subnet, naming the service (for example Microsoft.Storage).
2. On the service resource, add a virtual network rule allowing that subnet — and remove the broad public access it was relying on before.

Miss the second step and nothing breaks yet, because public access is still open; miss the first and the VNet rule rejects everything, because the service never sees the private source address. Enabling is quick but not instantaneous, and traffic to that service may be briefly interrupted while the routes update.

⚠️ Exam Trap: Service endpoints are free and require no DNS change, which is exactly what separates them from private endpoints. If a scenario mentions on-premises clients, the answer is not a service endpoint — the route only exists inside the virtual network.