This chapter covers subnet delegation in Azure, a critical networking feature that allows you to designate a subnet for exclusive use by specific Azure PaaS services. On the AZ-104 exam, subnet delegation appears in roughly 5-10% of questions, often intertwined with service endpoints, private endpoints, and VNet integration. Understanding delegation is essential for scenarios involving managed databases, file shares, or container instances that require network isolation. We will explore the mechanism, configuration, and common pitfalls to ensure you can confidently answer exam questions and design secure, scalable networks.
Jump to a section
Imagine a large office building (your VNet) with multiple floors (subnets). The building owner (you, the Azure administrator) controls access and general maintenance. However, certain floors are leased to specific tenants (Azure PaaS services like Azure SQL Managed Instance or Azure NetApp Files) that need to manage their own infrastructure within that space. To allow this, you delegate a floor to a tenant by giving them a key card that grants them exclusive rights to install their own equipment (deploy resources), modify the floor plan (create subnets within the delegated subnet), and control access (manage network security groups) within that floor. Importantly, the tenant cannot break through the walls to adjacent floors or the building's main electrical room (the rest of the VNet and Azure backbone). You, as the owner, can still inspect the floor (monitor traffic) but cannot reconfigure the tenant's setup. If you delegate a floor but the tenant never moves in, the space remains unused but cannot be used by other tenants. This mirrors subnet delegation: you designate a subnet for a specific Azure service, granting that service the permissions to create and manage resources within that subnet, while you retain visibility and control over the subnet's boundaries and connectivity.
What is Subnet Delegation and Why Does It Exist?
Subnet delegation is an Azure Virtual Network (VNet) feature that allows you to explicitly designate a subnet for use by a specific Azure PaaS service. When you delegate a subnet, you grant that service the necessary permissions to create and manage network resources within that subnet – such as network interfaces, load balancers, or additional subnets – without requiring you to manually intervene. This is essential for services that need to inject themselves into your VNet to provide network-level isolation, performance, or security guarantees.
Before delegation, if you wanted to run a managed database like Azure SQL Managed Instance, you had to create a dedicated subnet and manually configure network security groups (NSGs) and route tables to allow the service to function. This was error-prone and required deep knowledge of the service's requirements. Delegation automates this by letting the service manage its own networking within the delegated subnet, while you retain control over the subnet's boundaries (e.g., what traffic enters/exits).
How Subnet Delegation Works Internally
When you delegate a subnet to a service, Azure performs several actions:
Resource Provider Registration: The service's resource provider must be registered in your subscription. Azure checks this and, if not registered, may prompt you to register it.
Subnet Properties Update: The subnet's delegations property is updated with an entry containing the service's name and actions. For example, Microsoft.Sql/managedInstances or Microsoft.Web/serverFarms.
Permissions Grant: The service's Azure Active Directory (Azure AD) service principal is granted a set of permissions on the subnet. These permissions are defined by the service and typically include Microsoft.Network/virtualNetworks/subnets/join/action and Microsoft.Network/networkInterfaces/write.
Resource Reservation: The subnet is flagged as delegated, which prevents you from creating other resources directly (like VMs) in that subnet. Only the delegated service can create resources there.
Service Management: The service can now create subnets within the delegated subnet (if it supports sub-delegation), attach network security groups, or configure routes. You, as the administrator, can still create NSGs and route tables and associate them with the delegated subnet, but the service may override or manage its own.
Key Components, Values, Defaults, and Timers
- Delegation Name: A friendly name you provide, e.g., mySqlDelegation. This is purely for identification.
- Service Name: The Azure service resource provider namespace and resource type. Common examples:
- Microsoft.Sql/managedInstances – Azure SQL Managed Instance
- Microsoft.Web/serverFarms – Azure App Service (for VNet integration)
- Microsoft.ContainerInstance/containerGroups – Azure Container Instances
- Microsoft.Netapp/volumes – Azure NetApp Files
- Microsoft.HardwareSecurityModules/dedicatedHSMs – Azure Dedicated HSM
- Delegation Actions: A list of actions the service is allowed to perform on the subnet. For example, Microsoft.Network/networkInterfaces/* and Microsoft.Network/virtualNetworks/subnets/join/action. These are predefined by the service and not configurable.
- Subnet Size: The delegated subnet must have a minimum size of at least /28 (16 IP addresses) for most services, but some services require larger sizes (e.g., Azure SQL Managed Instance requires a minimum of /27 (32 IP addresses)). The exam often tests these minimums.
- Subnet State: After delegation, the subnet cannot be used for general-purpose resources. You cannot create VMs, internal load balancers, or other resources directly. This is enforced by Azure.
- Delegation Removal: To remove a delegation, you must first ensure no resources are deployed in the subnet by the delegated service. Then you can remove the delegation via portal, CLI, or PowerShell. The subnet returns to a general-purpose state.
Configuration and Verification Commands
Azure CLI – Create a delegated subnet:
az network vnet subnet create \
--name mySubnet \
--resource-group myRG \
--vnet-name myVNet \
--address-prefixes 10.0.1.0/27 \
--delegations myDelegation=Microsoft.Sql/managedInstancesAzure CLI – Add delegation to existing subnet:
az network vnet subnet update \
--name mySubnet \
--resource-group myRG \
--vnet-name myVNet \
--delegations myDelegation=Microsoft.Sql/managedInstancesAzure CLI – View delegation:
az network vnet subnet show \
--name mySubnet \
--resource-group myRG \
--vnet-name myVNet \
--query delegationsPowerShell – Create delegated subnet:
$vnet = Get-AzVirtualNetwork -Name myVNet -ResourceGroupName myRG
$subnet = Add-AzVirtualNetworkSubnetConfig `
-Name mySubnet `
-AddressPrefix 10.0.1.0/27 `
-DelegationName myDelegation `
-ServiceName Microsoft.Sql/managedInstances `
-VirtualNetwork $vnet
$vnet | Set-AzVirtualNetworkInteraction with Related Technologies
Service Endpoints: Service endpoints extend your VNet identity to Azure services over the Microsoft backbone. They do not require delegation. Delegation is for services that need to inject resources into your VNet, not just access them.
Private Endpoints: Private endpoints create a private IP in your VNet for an Azure service. They do not require delegation; they are simply a network interface (NIC) in a subnet. Delegation is for services that manage their own NICs and subnets.
NSGs and Route Tables: You can associate NSGs and route tables with a delegated subnet, but the delegated service may create its own NSGs or override routes. For example, Azure SQL Managed Instance creates its own NSG with required rules. You cannot modify those NSGs directly.
VNet Peering: Delegated subnets can be peered, but the delegated service's resources may have limitations. For example, Azure SQL Managed Instance does not support VNet peering across regions.
Exam Trap Patterns
Confusing Delegation with Service Endpoints: Many candidates think delegation is required for all PaaS services. It is only required for services that need to deploy resources into your VNet (like managed instances). Service endpoints and private endpoints do not require delegation.
Assuming Delegation Allows Any Resource: Delegation does not allow you to create VMs in the subnet. Only the delegated service can create resources. You cannot create a VM in a delegated subnet.
Forgetting Minimum Subnet Size: The exam loves to test the minimum size for specific services. For Azure SQL Managed Instance, it's /27 (32 IPs). For Azure App Service, it's /28 (16 IPs). For Azure NetApp Files, it's /28 as well.
Overlooking Resource Provider Registration: If the service's resource provider is not registered, delegation will fail. The exam may present a scenario where delegation fails and you need to register the provider.
Summary of Mechanism
Subnet delegation is a declarative way to hand over control of a subnet to an Azure service. It works by updating the subnet's properties with the service's identity and allowed actions. The service then uses its Azure AD identity to manage resources in that subnet. You retain visibility and can apply network policies at the subnet boundary, but the internal management is delegated.
Identify Service Requirements
Before delegating a subnet, determine which Azure PaaS service requires deployment. Each service has specific requirements: minimum subnet size, supported regions, and whether it supports VNet integration. For example, Azure SQL Managed Instance requires a dedicated subnet with a minimum of 32 IP addresses (/27) and cannot be used for any other resources. Check the service documentation for its delegation service name (e.g., Microsoft.Sql/managedInstances). Also ensure the service's resource provider is registered in your subscription. You can check with: `az provider list --query "[?namespace=='Microsoft.Sql'].registrationState"`.
Create or Select Subnet
Choose an existing subnet or create a new one in your VNet. The subnet must have an address range that meets the service's minimum size and cannot overlap with other subnets. It should be dedicated to the service – no other resources should be planned for that subnet. For Azure SQL Managed Instance, the subnet must be empty before delegation. If you try to delegate a subnet that already has resources (like VMs), the operation will fail. Create the subnet with the appropriate address prefix, e.g., 10.0.1.0/27 for a managed instance.
Apply Delegation Configuration
Using Azure Portal, CLI, or PowerShell, set the delegation property on the subnet. In the portal, navigate to the subnet, select 'Delegate subnet', choose the service from the dropdown (e.g., 'Microsoft.Sql/managedInstances'), and provide a delegation name. Using CLI: `az network vnet subnet update --name mySubnet --resource-group myRG --vnet-name myVNet --delegations myDelegation=Microsoft.Sql/managedInstances`. The delegation name is arbitrary but should be descriptive. After this step, the subnet is flagged as delegated. You can verify by viewing the subnet's delegations property.
Deploy the PaaS Service
Now deploy the Azure service that will use the delegated subnet. For example, create an Azure SQL Managed Instance and specify the subnet in the networking configuration. The service will automatically create the required network interfaces, load balancers, or additional subnets within the delegated subnet. You do not need to manually create any network resources. The service may also configure its own NSGs and route tables. During deployment, the service's resource provider uses its Azure AD permissions to join the subnet and create resources. If the deployment fails, check that the subnet is properly delegated and that the service's resource provider is registered.
Verify and Monitor Delegated Subnet
After deployment, verify the subnet's status. Use `az network vnet subnet show` to see the delegations and any subnets created by the service (if applicable). Monitor the subnet for any changes. You cannot modify the service's internal resources, but you can view them. For example, you can see the network interfaces created by Azure SQL Managed Instance in the delegated subnet. Ensure that no unauthorized resources are created. If you need to remove the delegation, you must first delete the service's resources from the subnet. Then remove the delegation using `az network vnet subnet update --remove delegations`.
Enterprise Scenario 1: Migrating On-Premises SQL Server to Azure SQL Managed Instance
A large financial services company is migrating its on-premises SQL Server databases to Azure SQL Managed Instance for better performance and reduced maintenance. The company requires network isolation to meet compliance standards. They create a VNet with a dedicated subnet delegated to Microsoft.Sql/managedInstances. The subnet is sized at /27 to accommodate 32 IP addresses, more than enough for the managed instance and its internal resources. After delegation, they deploy the managed instance, which automatically creates a network interface and an internal load balancer within the subnet. The company then configures a site-to-site VPN to connect their on-premises network to the VNet, allowing applications to access the database securely. They also associate a network security group (NSG) with the subnet to restrict inbound traffic from other VNets. However, they cannot modify the NSG rules created by the managed instance itself. One common issue is that if the subnet is too small, the managed instance deployment fails. The company initially used a /28 subnet and had to recreate it. This scenario highlights the importance of correct subnet sizing and delegation.
Enterprise Scenario 2: Hosting Containerized Applications with Azure Container Instances
A SaaS startup uses Azure Container Instances (ACI) to run microservices in a serverless manner. They want their containers to have static IP addresses within their VNet for integration with other resources. They create a subnet delegated to Microsoft.ContainerInstance/containerGroups. The subnet is sized /28 (16 IPs) which is the minimum for ACI. After delegation, they deploy container groups with network profiles that reference the delegated subnet. Each container group gets a private IP from the subnet. The startup also configures a route table on the subnet to direct traffic to a network virtual appliance (NVA) for inspection. However, they discover that ACI creates its own network interfaces, and those interfaces are not visible in the portal (they are managed by the service). This is expected. A common pitfall is that if the subnet is used by other resources, ACI deployment fails. The startup learned to keep the subnet dedicated. They also found that scaling containers requires sufficient IP addresses in the subnet.
Enterprise Scenario 3: Using Azure NetApp Files for High-Performance File Shares
A media production company uses Azure NetApp Files (ANF) to store large video files. ANF requires a delegated subnet to create its volumes. They create a VNet with a subnet delegated to Microsoft.Netapp/volumes, sized /28. After delegation, they create an ANF account and a capacity pool, then provision a volume. The volume gets an IP address from the delegated subnet. The company mounts the volume on Linux VMs in a different subnet using NFS. They also configure a service endpoint for Azure Storage to allow the VMs to access storage without public internet. One challenge is that ANF volumes cannot be moved to a different subnet after creation. If the company needs to expand, they must plan the subnet size carefully. They initially used a /29 subnet (8 IPs) which was insufficient, causing deployment failure. This scenario emphasizes planning subnet size ahead of time.
What AZ-104 Tests on Subnet Delegation
The AZ-104 exam objectives under 'Configure and manage virtual networking' (Objective 4.1) include subnet delegation. Specifically, you should know:
Which services require subnet delegation (e.g., Azure SQL Managed Instance, Azure Container Instances, Azure App Service, Azure NetApp Files).
The minimum subnet sizes for these services (e.g., /27 for SQL Managed Instance, /28 for many others).
The difference between delegation, service endpoints, and private endpoints.
How to configure delegation using Azure Portal, CLI, and PowerShell.
That delegated subnets cannot contain general-purpose resources like VMs.
That you can still apply NSGs and route tables to delegated subnets, but the service may manage its own.
Common Wrong Answers and Why Candidates Choose Them
'You can delegate a subnet to any Azure service.' – Wrong. Only specific services support delegation. Candidates confuse delegation with service endpoints, which work with many services.
'Delegated subnets require a minimum size of /28 for all services.' – Wrong. Azure SQL Managed Instance requires /27. The exam tests this specific exception.
'You can create a VM in a delegated subnet if you use the same service.' – Wrong. Delegation grants permissions to the service, not to you. You cannot create any resources directly.
'Delegation is needed for private endpoints.' – Wrong. Private endpoints use a standard subnet; delegation is optional. Candidates mix up the two concepts.
Specific Numbers and Terms to Memorize
Minimum subnet size for Azure SQL Managed Instance: /27 (32 IP addresses).
Minimum subnet size for Azure App Service: /28 (16 IP addresses).
Minimum subnet size for Azure Container Instances: /28 (16 IP addresses).
Minimum subnet size for Azure NetApp Files: /28 (16 IP addresses).
Service names: Microsoft.Sql/managedInstances, Microsoft.Web/serverFarms, Microsoft.ContainerInstance/containerGroups, Microsoft.Netapp/volumes.
The delegation property is set on the subnet, not the VNet.
Edge Cases and Exceptions
Subnet with existing resources: If you try to delegate a subnet that already has resources (e.g., a VM), the operation fails. You must ensure the subnet is empty.
Multiple delegations: A subnet can only be delegated to one service at a time. You cannot delegate to multiple services.
Removing delegation: You must first delete all resources created by the delegated service. Then you can remove the delegation property.
Resource provider registration: If the service's resource provider is not registered, delegation fails. The exam may present a scenario where you need to register the provider first.
How to Eliminate Wrong Answers
If a question mentions 'delegation' and the service is not in the allowed list (e.g., Azure VMs, Azure Load Balancer), that answer is wrong.
If the question implies you can create a VM in a delegated subnet, it's wrong.
If the question suggests delegation is required for service endpoints or private endpoints, it's wrong.
If the subnet size is less than the service's minimum, it's wrong.
Use the underlying mechanism: delegation is about granting the service permission to manage its own resources in that subnet. Any answer that contradicts this principle is incorrect.
Subnet delegation is required only for Azure PaaS services that deploy resources into your VNet (e.g., Azure SQL Managed Instance, Azure Container Instances).
A delegated subnet cannot contain any other resources (like VMs); it is dedicated to the delegated service.
The minimum subnet size for Azure SQL Managed Instance is /27 (32 IP addresses); for most other services, it is /28 (16 IP addresses).
You can still associate NSGs and route tables with a delegated subnet, but the service may manage its own.
To remove a delegation, you must first delete all resources created by the service in that subnet.
Only one delegation is allowed per subnet; you cannot delegate to multiple services.
The service's resource provider must be registered in your subscription before delegation can succeed.
Subnet delegation is different from service endpoints and private endpoints; do not confuse them on the exam.
These come up on the exam all the time. Here's how to tell them apart.
Subnet Delegation
Grants the service permission to manage resources in the subnet.
Requires a dedicated subnet with minimum size (e.g., /27 for SQL MI).
Only for specific services that inject into VNet.
Subnet cannot be used for general resources.
Service manages its own network interfaces.
Service Endpoints
Extends VNet identity to the service over Microsoft backbone.
No dedicated subnet needed; uses existing subnet routes.
Works with many Azure services (e.g., Storage, SQL DB).
Subnet remains usable for other resources.
No resource injection; only traffic routing.
Mistake
Subnet delegation is required for all Azure PaaS services to communicate with a VNet.
Correct
Only specific services that need to deploy resources into your VNet require delegation. Most PaaS services can be accessed via service endpoints or private endpoints without delegation.
Mistake
After delegation, you cannot apply any NSGs or route tables to the subnet.
Correct
You can still apply NSGs and route tables to a delegated subnet. However, the delegated service may also create its own NSGs and routes, and you cannot modify those.
Mistake
A delegated subnet can be used for general-purpose resources like VMs if you are an administrator.
Correct
No. Delegation restricts the subnet to only the delegated service. Even as an administrator, you cannot create VMs or other resources directly in that subnet.
Mistake
You can delegate a subnet to multiple services at once.
Correct
A subnet can only be delegated to one service at a time. If you need multiple services, you must use separate subnets.
Mistake
The minimum subnet size for all delegated services is /28.
Correct
The minimum subnet size varies by service. For example, Azure SQL Managed Instance requires /27 (32 IP addresses), while many others require /28 (16 IP addresses). Always check the service documentation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Subnet delegation is a feature that allows you to designate a specific subnet for exclusive use by a particular Azure PaaS service. When delegated, the service gains permissions to create and manage network resources within that subnet, such as network interfaces and load balancers. This is used for services like Azure SQL Managed Instance, Azure Container Instances, and Azure NetApp Files that need to inject themselves into your VNet for network isolation.
Services that require subnet delegation include: Azure SQL Managed Instance (Microsoft.Sql/managedInstances), Azure App Service (Microsoft.Web/serverFarms) for VNet integration, Azure Container Instances (Microsoft.ContainerInstance/containerGroups), Azure NetApp Files (Microsoft.Netapp/volumes), and Azure Dedicated HSM (Microsoft.HardwareSecurityModules/dedicatedHSMs). Always check the latest documentation as the list may expand.
Azure SQL Managed Instance requires a minimum subnet size of /27 (32 IP addresses). This is larger than the typical /28 required by many other services. Using a smaller subnet will cause deployment to fail. Plan your address space accordingly.
No. Once a subnet is delegated, it becomes dedicated to the delegated service. You cannot create VMs, internal load balancers, or any other resources directly in that subnet. Only the delegated service can create resources there.
To remove a delegation, first delete all resources deployed by the delegated service in that subnet. Then, in the Azure Portal, go to the subnet, select 'Delegate subnet', and set it to 'None'. Using CLI: `az network vnet subnet update --name mySubnet --resource-group myRG --vnet-name myVNet --remove delegations`. After removal, the subnet can be used for general resources.
Subnet delegation grants a service permissions to manage resources within a subnet, requiring a dedicated subnet. Service endpoints extend your VNet identity to Azure services over the Microsoft backbone, without requiring a dedicated subnet. Delegation is for services that deploy into your VNet; service endpoints are for accessing services from your VNet.
Yes, you can associate an NSG with a delegated subnet. However, the delegated service may also create its own NSGs and you cannot modify those. Your NSG applies to traffic at the subnet boundary, but the service's internal traffic is managed by its own rules.
You've just covered Subnet Delegation in Azure — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?