Technical Lab: Create a virtual network (VNet)
Questions
Question 1 — Multiple Choice
You are designing an architecture in Azure with the following requirements: the main VNet should have an address space of 10.0.0.0/16, and a dedicated subnet for Azure Bastion should be created within it.
Which of the statements below correctly describes a mandatory requirement for this subnet?
A) The subnet must be named BastionSubnet and can use any /27 prefix or larger within the VNet space.
B) The subnet must be named AzureBastionSubnet and requires a minimum /26 prefix.
C) The subnet must be named AzureBastionSubnet and can use any prefix as long as it has at least 16 available addresses.
D) The subnet can have any name, as long as a bastion=true tag is applied and the prefix is /27 or larger.
Question 2 — Technical Scenario
An engineer creates two VNets in the same subscription and same region:
vnet-app:10.1.0.0/16vnet-data:10.1.128.0/17
After configuring VNet peering between them, resources in vnet-app cannot communicate with resources in vnet-data.
What is the most likely cause of the problem?
A) Peering between VNets in the same region is not supported by Azure; VPN Gateway is required.
B) The address spaces of the two VNets overlap, which invalidates the peering.
C) The peering was configured in only one direction and needs to be enabled on both VNets.
D) VNets in the same subscription require manual approval of peering through the governance portal.
Question 3 — True or False
Statement: After a VNet is created in Azure, the initial address space can be expanded by adding additional address ranges without needing to recreate the VNet, as long as the new ranges don't overlap with existing ones.
True or False?
Question 4 — Technical Scenario
A team needs to deploy a solution that requires the following resources within a single VNet:
- A subnet for application VMs:
10.2.1.0/24 - A subnet for Azure Application Gateway v2:
10.2.2.0/24 - A subnet for Azure Firewall:
10.2.3.0/24
During deployment, creating the subnet for Azure Firewall fails. The engineer verifies that the /24 prefix is available within the VNet and there's no overlap.
What is the most likely cause of the failure?
A) Azure Firewall requires its subnet to be in a dedicated VNet, separate from other workloads.
B) The Azure Firewall subnet name must be AzureFirewallSubnet.
C) The /24 prefix is too large for Azure Firewall, which accepts a maximum of /26.
D) Azure Firewall cannot coexist in the same VNet as Application Gateway v2.
Question 5 — Multiple Choice
You need to create a VNet in Azure using Azure CLI. Analyze the command below:
az network vnet create \
--name vnet-producao \
--resource-group rg-networking \
--location eastus \
--address-prefixes 192.168.0.0/16
A subnet named snet-frontend with prefix 192.168.1.0/24 should be created along with the VNet in the same command.
Which parameter should be added to meet this requirement?
A) --subnet-name snet-frontend --subnet-prefix 192.168.1.0/24
B) --subnet snet-frontend --cidr 192.168.1.0/24
C) --subnets snet-frontend=192.168.1.0/24
D) --subnet-name snet-frontend --subnet-address-prefix 192.168.1.0/24
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Bastion requires its subnet to have the exact name AzureBastionSubnet, with no variations. Additionally, the minimum accepted prefix is /26, which provides 64 IP addresses to accommodate the service's scale.
Alternative A is wrong in the subnet name. Alternative C ignores the minimum /26 prefix requirement, as "16 available addresses" would correspond to a /28, which is insufficient. Alternative D is incorrect because the name is mandatory and tags don't replace this structural requirement.
Choosing a prefix smaller than /26 or a different name results in Azure Bastion resource deployment failure, not just a warning.
Answer Key — Question 2
Answer: B
Azure requires that the address spaces of two peered VNets be completely distinct, with no overlap. The 10.1.128.0/17 block is contained within 10.1.0.0/16, which characterizes direct overlap. Peering is not established in this situation.
Alternative C is a common misconception: regional peering indeed needs to be configured on both sides, but this isn't the cause here, as the overlap prevents peering before this step. Alternative A is false; VNet peering in the same region is fully supported. Alternative D doesn't correspond to any actual Azure behavior.
This scenario is classic in projects where subnets from different VNets are planned without centralized IPAM control.
Answer Key — Question 3
Answer: True
Azure allows adding new address ranges to an existing VNet without recreating it. This operation is non-destructive: existing resources and subnets are not affected. The only requirement is that new ranges don't overlap with those already associated with the VNet.
This behavior is relevant in architectures that grow over time and need to accommodate new subnets without complete redesign. The common misconception is believing that the address space is immutable after creation, which would lead to decisions to unnecessarily over-provision the initial prefix.
Answer Key — Question 4
Answer: B
Azure Firewall requires its subnet to have the exact name AzureFirewallSubnet. Any other name causes resource deployment to fail, regardless of prefix or address availability.
Alternative C contains an inversion: the minimum required prefix for Azure Firewall is /26, so a /24 is perfectly valid and larger than the minimum. Alternative A is false; Azure Firewall can coexist with other resources in the same VNet. Alternative D is also false; there's no coexistence restriction between Azure Firewall and Application Gateway v2 in the same VNet.
This is a recurring error in automated deployments via IaC when the subnet name is freely parameterized.
Answer Key — Question 5
Answer: D
Azure CLI uses --subnet-name for the subnet name and --subnet-address-prefix for the CIDR block when the subnet is created along with the VNet in the az network vnet create command.
Alternative A uses --subnet-prefix, which is not the correct parameter for this command. Alternative B uses --subnet and --cidr, parameters that don't exist in this context. Alternative C uses key-value pair syntax that doesn't correspond to Azure CLI.
Confusing --subnet-prefix with --subnet-address-prefix is a common error when migrating from memory between CLI versions or when using autocomplete without checking updated documentation.