Troubleshooting Lab: Create a virtual network (VNet)
Diagnostic Scenarios
Scenario 1 — Root Cause
An infrastructure team created a new VNet called vnet-producao in the brazilsouth region with the address space 10.10.0.0/16. They then created three subnets:
| Subnet | Prefix |
|---|---|
| snet-app | 10.10.1.0/24 |
| snet-data | 10.10.2.0/24 |
| snet-mgmt | 10.10.3.0/24 |
Two days later, the team attempted to add a fourth subnet called snet-firewall with the prefix 10.10.4.0/24. The operation failed. The engineer ran the command below to investigate:
az network vnet subnet list \
--resource-group rg-networking \
--vnet-name vnet-producao \
--output table
The output returned the three existing subnets without errors. The engineer then verified that the rg-networking resource group has an Azure policy applied that restricts resource creation to specific regions, but brazilsouth is on the allowed regions list. The subscription is active and within quota limits. The Azure portal displayed the following error message during the attempt:
The subnet 'snet-firewall' is invalid because its name is reserved for a specific Azure service.
Subnet name 'AzureFirewallSubnet' is required for Azure Firewall deployments.
Code: InvalidResourceName
What is the root cause of the failure to create the subnet?
A) The Azure policy applied to the resource group is blocking the creation of new subnets with custom names.
B) The name snet-firewall is not accepted by Azure because subnets intended for Azure Firewall require the exact name AzureFirewallSubnet.
C) The address space 10.10.0.0/16 is exhausted after creating the three previous subnets.
D) The subnet quota per VNet has been reached, preventing the creation of a fourth subnet.
Scenario 2 — Action Decision
The network team identified that VNet vnet-hub and VNet vnet-spoke-rh cannot establish peering. The investigation confirmed that the cause is an address space overlap: both use 172.16.0.0/16.
The environment has the following constraints:
vnet-hubhas 12 active production VMs with IPs within172.16.0.0/16vnet-spoke-rhwas created 2 hours ago and has no deployed resources yet- The available maintenance window is 4 hours, starting now
- The team has permission to recreate resources in
vnet-spoke-rh - There is no permission to modify
vnet-hubwithout level 2 change approval, which takes 48 hours
What is the correct action to take within the available maintenance window?
A) Recreate vnet-hub with a new address space and migrate the 12 VMs, taking advantage of the 4-hour window.
B) Add a second address space to vnet-hub to resolve the overlap without recreating resources.
C) Recreate vnet-spoke-rh with a different address space, such as 172.17.0.0/16, that doesn't conflict with vnet-hub.
D) Request level 2 change approval immediately and wait 48 hours to modify vnet-hub.
Scenario 3 — Root Cause
An engineer reported that when trying to deploy an Azure Bastion resource in an existing VNet called vnet-acesso, the deployment consistently fails. The VNet was created 3 months ago with address space 10.50.0.0/16 and contains the following subnets:
| Subnet | Prefix | Current Use |
|---|---|---|
| snet-vms | 10.50.1.0/24 | 18 active VMs |
| snet-appgw | 10.50.2.0/24 | Application Gateway |
| AzureBastionSubnet | 10.50.3.0/27 | Empty |
The engineer verified that:
- The subnet name is correct
- There is no NSG applied to the
AzureBastionSubnetsubnet - The subscription has available quota for Azure Bastion
- The Azure Bastion Standard SKU was selected
The error message returned by the portal is:
Deployment failed: The subnet '/subscriptions/.../AzureBastionSubnet'
does not have enough address space for the Azure Bastion resource.
Minimum required prefix length: /26.
Code: SubnetTooSmall
The engineer believes the problem is the missing NSG, as he read in an article that Azure Bastion requires specific NSG rules.
What is the real root cause of the failure?
A) The absence of an NSG on the AzureBastionSubnet subnet is preventing the Azure Bastion deployment.
B) The Standard SKU of Azure Bastion is not compatible with VNets that already have other deployed resources.
C) The /27 prefix of the AzureBastionSubnet subnet is smaller than the required minimum of /26 for Azure Bastion.
D) The address space 10.50.0.0/16 is not routable by Azure Bastion because it's a Class B private block.
Scenario 4 — Diagnostic Sequence
An engineer receives the following report: "We created a new VNet with peering to the hub VNet, but VMs in the new VNet cannot resolve DNS names of internal resources in the hub VNet."
The available investigation steps are:
- Verify that peering is configured on both sides and with
Connectedstatus - Check the DNS settings of the new VNet to identify which DNS server is being used
- Confirm that VMs in the new VNet can reach the IP of the configured DNS server
- Test name resolution directly from a VM in the new VNet using
nslookupordig - Verify if the organization's internal DNS server has a zone configured for the relevant internal domains
What is the correct investigation sequence for this symptom?
A) 4 → 1 → 2 → 3 → 5
B) 1 → 2 → 3 → 4 → 5
C) 2 → 1 → 3 → 5 → 4
D) 1 → 4 → 2 → 3 → 5
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message in the scenario is conclusive: InvalidResourceName with the description indicating that the subnet name is reserved for Azure Firewall use. Azure enforces that the subnet intended for Azure Firewall must be named exactly AzureFirewallSubnet. The name snet-firewall does not meet this requirement.
The information about the Azure policy restricting regions is irrelevant in this scenario, as brazilsouth is on the allowed list and the error message does not indicate a policy block. This detail was intentionally included to divert focus.
Alternative C is false because 10.10.0.0/16 can accommodate hundreds of /24 subnets. Alternative D is a plausible distractor, but the default subnet quota per VNet in Azure is 3,000, well above 4. The most dangerous distractor is A: an engineer following this path would spend time reviewing policies and opening tickets with the governance team without ever reaching the real cause.
Answer Key — Scenario 2
Answer: C
The cause is identified and the constraints are precise: vnet-hub cannot be modified without 48-hour approval, and vnet-spoke-rh was created 2 hours ago without any resources. The only action that is technically valid and operationally feasible within the 4-hour window is to recreate vnet-spoke-rh with an address space that doesn't conflict with vnet-hub.
Alternative A ignores the critical constraint: modifying vnet-hub requires level 2 approval. Even if the 4-hour window were technically sufficient, the action would be invalid within the environment's rules. Alternative B is technically incorrect: adding a second address space to vnet-hub doesn't resolve the overlap because vnet-spoke-rh also uses 172.16.0.0/16. Alternative D is valid as a process, but wastes the available maintenance window and ignores that the problem can be solved now without waiting 48 hours.
Answer Key — Scenario 3
Answer: C
The error message is direct: SubnetTooSmall with explicit indication that the minimum required prefix is /26. The AzureBastionSubnet subnet was created with /27, which provides only 32 addresses, below the minimum of 64 required by Azure Bastion.
The information that the engineer believes the problem is the missing NSG is an explicit trap. NSG in Azure Bastion is optional and its absence does not prevent deployment. This detail was included to test if the reader ignores the engineer's belief and reads the error log carefully.
Alternative B is false; the Standard SKU is compatible with shared VNets. Alternative D is technically absurd: RFC 1918 blocks are fully supported by Azure. The most dangerous distractor is A: an engineer following this direction would create and configure an NSG without solving the problem, wasting time in production.
Answer Key — Scenario 4
Answer: B
The correct sequence is 1 → 2 → 3 → 4 → 5, which follows the logic of progressive diagnosis from connectivity layer to application layer:
- First confirm that peering is active on both sides, as without this no communication is possible.
- Then check which DNS server is configured in the VNet, as this is the central point of the reported problem.
- Confirm that the DNS server is reachable from the VMs, validating network connectivity to the resolver.
- Only then test name resolution directly, as there is now a basis for interpreting the result.
- Finally, verify if the internal DNS server has the zone configured, which is an investigation on the server side, not the VNet side.
Alternative A starts with symptom testing without validating any support layer, which can lead to false conclusions. Alternative C skips peering validation, which is the prerequisite for everything. Alternative D reverses steps 2 and 4, testing resolution before knowing which DNS is being queried, making the diagnosis blind.
Troubleshooting Tree: Create a virtual network (VNet)
Color Legend:
- Dark blue: initial symptom or diagnostic entry point
- Medium blue: diagnostic question or decision point
- Red: identified cause
- Green: recommended action or resolution
- Orange: intermediate validation check
To use this tree when facing a real problem, start at the root node describing the general symptom. At each blue node, answer the question based on what you observe in the environment, without assuming the answer. Follow the corresponding path until you reach a red node, which identifies the cause, or a green node, which indicates the action to take. If the path leads to an orange node, perform the indicated verification before proceeding. The discipline of following the sequence without skipping steps is what differentiates a correct diagnosis from a hasty action.