Troubleshooting Lab: Plan and configure subnet delegation
Diagnostic Scenarios
Scenario 1 — Root Cause
An infrastructure team successfully deployed Azure SQL Managed Instance in a subnet called snet-sqlmi three weeks ago. The subnet is configured with the 10.2.1.0/24 block, has an associated NSG and UDR, and the Microsoft.Sql/managedInstances delegation was correctly applied.
Last week, the team attempted to provision a second managed instance in the same subnet to serve a new workload. The provisioning failed with the following error:
Deployment failed. Subnet 'snet-sqlmi' does not have enough free IP addresses
to allocate resources for the new managed instance.
The team checks the subnet status and gets the following output:
Address space : 10.2.1.0/24
Total IPs : 256
Reserved (Azure): 5
In use : 238
Available : 13
The networking team reports that the NSG has 47 inbound and outbound rules configured, and the UDR contains 12 route entries. An engineer suggests that NSG rules are consuming virtual IP addresses and proposes removing redundant rules to free up space.
What is the root cause of the problem?
A) The NSG with 47 rules is consuming virtual IP addresses in the subnet, reducing the available space for new instances.
B) The /24 block was sized without considering that each SQL Managed Instance consumes a significant number of IP addresses beyond the main address, and the available space is insufficient for a second instance.
C) The Microsoft.Sql/managedInstances delegation limits the subnet to a single active instance, preventing the provisioning of a second instance regardless of the address space.
D) The UDR with 12 route entries is fragmenting the subnet's address space and preventing the allocation of contiguous blocks needed for SQL Managed Instance.
Scenario 2 — Action Decision
The cause of the problem has been identified: the snet-webapp subnet was configured with the Microsoft.Web/serverFarms delegation, but the team also needs to deploy, in the same subnet, a set of virtual machines for internal monitoring agents. The environment is production, in continuous operation. The App Service integrated to the subnet is operational and serving requests from end users.
The team has the following documented constraints:
- App Service unavailability during business hours is not allowed
- The available maintenance window is from 02h to 04h local time
- The
snet-webappsubnet has only 18 available IP addresses - There is an empty
snet-monitoringsubnet, with10.3.5.0/26block, no delegation configured, available in the same VNet
What is the correct action to take at this time?
A) Remove the delegation from the snet-webapp subnet immediately to allow deployment of monitoring VMs, and reconfigure the delegation after deployment.
B) Deploy the monitoring VMs directly in the snet-webapp subnet, as the Microsoft.Web/serverFarms delegation allows coexistence of other resources in certain contexts.
C) Deploy the monitoring VMs in the snet-monitoring subnet, which has no delegation and is available in the same VNet, without changing the production subnet configuration.
D) Wait for the maintenance window, remove the App Service Plan, delete the delegation, deploy the VMs and recreate the App Service Plan with new VNet integration.
Scenario 3 — Root Cause
A cloud architect receives the following report from a development team:
"We configured the delegation correctly, created the App Service Plan and tried to do the VNet integration, but the portal keeps saying there are no available subnets for selection, even with the delegated subnet visible in the list."
The architect analyzes the configuration and collects the following information:
VNet: vnet-app-prod
Region: East US
Subnet: snet-appint
Address: 10.4.2.128/28
Delegation: Microsoft.Web/serverFarms
NSG: nsg-appint (associated)
UDR: none
App Service Plan:
Name: asp-prod-01
SKU: B1 (Basic)
Region: Brazil South
OS: Windows
The NSG associated with the subnet has Azure's default rules and no custom blocking rules. The subnet has 9 available IP addresses. The delegation was applied two days ago without errors.
What is the root cause of the problem?
A) The /28 block is insufficient for App Service VNet integration, which requires at least a /26 block.
B) The NSG without custom rules is preventing integration because default rules block App Service management traffic.
C) The App Service Plan is in a different region from the VNet, and regional VNet integration requires both to be in the same region.
D) The Microsoft.Web/serverFarms delegation requires a UDR to be associated with the subnet before VNet integration can be completed.
Scenario 4 — Collateral Impact
A team identifies that the snet-aci subnet is out of available address space, preventing new container group provisioning. To solve the problem, the team decides to delete the subnet and recreate it with a larger /23 block, maintaining the same Microsoft.ContainerInstance/containerGroups delegation.
The action is executed successfully: the old subnet is removed, the new one is created, the delegation is reapplied, and new container groups are provisioned without errors.
What secondary consequence can this action cause?
A) The delegation reapplied to a newly created subnet is treated by Azure as a new configuration and may have a propagation period of up to 24 hours before accepting deployments.
B) All container groups that were running in the original subnet permanently lose their network connectivity, as their private IP addresses were bound to the deleted subnet.
C) The new subnet with /23 block now automatically requires an associated UDR, as subnets larger than /24 with active delegation require explicit route control.
D) Azure interprets the new subnet as a subnet with no delegation history and ignores the reapplied delegation configuration until a resource is manually deployed.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The command output clearly shows that 238 of the 251 usable addresses are already in use, leaving only 13. The Azure SQL Managed Instance is notoriously intensive in IP address consumption: each instance consumes dozens of addresses for management nodes, listeners, internal replicas, and managed service infrastructure components. A second instance typically requires between 32 and more than 100 addresses depending on configuration, making 13 addresses insufficient.
The decisive clue is in the command output: the space is genuinely exhausted by actual usage, not by any technical malfunction.
Information about the NSG with 47 rules and the UDR with 12 entries are irrelevant information purposefully included. NSG rules and UDR entries do not consume subnet IP addresses; they operate on the control plane and data plane, respectively, without affecting available address space.
The most dangerous distractor is A, as the engineer in the statement already suggests this incorrect action. Acting on this hypothesis would waste time and not solve the real problem. Alternative C is incorrect because delegation does not impose instance limits per subnet; the limit is address capacity. Alternative D confuses route fragmentation with IP exhaustion, two completely different problems.
Answer Key — Scenario 2
Answer: C
The scenario presents an already identified cause (incompatibility between delegation and resource type) and a clear set of constraints. The snet-monitoring subnet is empty, without delegation, in the same VNet, and was designed exactly for monitoring workloads. Deploying VMs in that subnet solves the problem without touching the production configuration.
Alternative A is the most dangerous: removing delegation from a subnet with App Service in production, outside the maintenance window, would cause immediate service unavailability. This directly violates the documented constraint in the statement.
Alternative B is based on an incorrect premise. The Microsoft.Web/serverFarms delegation does not allow coexistence with VMs in the same subnet; the delegated subnet is exclusive for network interfaces managed by App Service.
Alternative D describes a technically valid sequence in other contexts, but violates the constraint of not causing unavailability outside the maintenance window, besides being unnecessarily destructive when an impact-free solution is available.
Answer Key — Scenario 3
Answer: C
The determining clue is in the region comparison: the VNet vnet-app-prod is in East US and the App Service Plan asp-prod-01 is in Brazil South. App Service regional VNet integration requires the App Service Plan and VNet to be in the same Azure region. When there's region divergence, the portal doesn't list the subnet as available for selection, even if delegation is correctly applied.
The correct delegation, NSG without blocks, and IP availability are all confirmations that the subnet configuration itself is correct. The problem is in the region incompatibility between the plan and the network.
Alternative A is a plausible distractor because the /28 block provides only 11 usable addresses, which could be insufficient in some scenarios. However, the Azure portal doesn't filter subnets by block size during VNet integration selection; the observed blocking occurs before this verification, for region reasons. Alternative B is incorrect because Azure's default rules allow the management traffic needed for App Service. Alternative D is incorrect because the Microsoft.Web/serverFarms delegation doesn't require UDR as a prerequisite.
Answer Key — Scenario 4
Answer: B
When a subnet is deleted, all network resources bound to it immediately and permanently lose their connectivity. ACI container groups that were running in the original subnet had their private IP addresses allocated in that subnet. With deletion, these resources go into network failure state without possibility of automatic recovery. The solution would require recreating the container groups in the new subnet.
This is the real and relevant collateral impact: the action solves the address space problem but destroys existing resources' connectivity.
Alternative A is incorrect because delegations don't have propagation period after reapplication; delegation takes effect immediately. Alternative C invents a restriction that doesn't exist: the /23 block size doesn't impose automatic UDR requirement. Alternative D is incorrect because Azure doesn't treat reapplied delegations differently from original delegations; the configuration is immediately valid.
Troubleshooting Tree: Plan and configure subnet delegation
Color Legend:
| Color | Meaning |
|---|---|
| Dark blue | Initial symptom or observed failure |
| Blue | Diagnostic question |
| Red | Identified cause |
| Orange | Validation or intermediate correction action |
| Green | Confirmed resolution |
When facing an actual provisioning failure in a delegated subnet, start from the root node and answer each diagnostic question based on what is directly observable: delegation exists, service is correct, IPs are available, resource is compatible, regions match, network rules allow traffic. Each branch leads to a specific cause with a corresponding action. The goal is to eliminate hypotheses progressively until reaching the green resolution node through the shortest possible path.