Skip to main content

Technical Lab: Create and configure virtual networks and subnets

Questions​

Question 1 — Multiple Choice​

An infrastructure team needs to create a virtual network in Azure with support for at least 500 hosts in a single subnet, without wasting addresses unnecessarily. The available address space is 10.0.0.0/16.

Which subnet prefix meets the requirement with the least possible waste?

A) /22 B) /23 C) /24 D) /21

Question 2 — Technical Scenario​

An administrator created the following configuration in the Azure portal:

Virtual Network: vnet-prod
Address space:   10.10.0.0/16

Subnet: snet-app
Address range:   10.10.1.0/24

Subnet: snet-db
Address range:   10.10.1.128/25

When trying to save the configuration, the portal returns a validation error. What is the cause of the problem?

A) The /25 prefix is too small to be used in an Azure subnet. B) The ranges of snet-app and snet-db overlap, as 10.10.1.128/25 is contained within 10.10.1.0/24. C) The VNet address space is insufficient to support two subnets. D) Subnets with different prefixes cannot coexist in the same virtual network.

Question 3 — True or False​

In an Azure subnet, all IP addresses in the configured range are available for assignment to resources, as Azure does not reserve addresses within user subnets.

Question 4 — Technical Scenario​

An organization has two environments in different regions:

vnet-eastus   | 10.1.0.0/16 | East US
vnet-westus   | 10.1.0.0/16 | West US

The network team requests that the two VNets be connected via VNet Peering to allow direct communication between resources. The administrator tries to configure the peering and receives an error.

What is the root cause of the problem?

A) VNet Peering is not supported between different Azure regions. B) The address spaces of the two VNets overlap, which prevents peering. C) VNet Peering requires that the VNets be in the same Azure subscription. D) The /16 prefix is too large to be used in peering between regions.

Question 5 — Multiple Choice​

When creating a dedicated subnet for an Azure Bastion, which of the following requirements is mandatory and enforced by the service itself?

A) The subnet must be named AzureBastionSubnet and have a minimum prefix of /26. B) The subnet can have any name, as long as the prefix is /27 or smaller. C) The subnet must be named BastionSubnet and be in an exclusive VNet for the Bastion. D) The subnet must be named AzureBastionSubnet and have a minimum prefix of /29.

Answer Key and Explanations​

Answer Key — Question 1​

Answer: B

A /23 prefix provides 512 total addresses. Azure reserves 5 addresses in every subnet (network, broadcast, and three for internal services), resulting in 507 usable addresses, which meets the requirement of 500 hosts with minimal waste.

The /24 prefix provides only 251 usable addresses, insufficient for 500 hosts. The /22 prefix would deliver 1019 usable addresses, meeting the requirement but wasting more than half the capacity. The /21 would be even more excessive. The correct logic is to identify the smallest power of 2 that, after subtracting Azure's 5 reserved addresses, still satisfies the requirement.

Answer Key — Question 2​

Answer: B

The range 10.10.1.128/25 covers addresses from 10.10.1.128 to 10.10.1.255, which are a direct subset of the range 10.10.1.0/24 (which covers 10.10.1.0 to 10.10.1.255). Subnets within the same VNet must have non-overlapping and non-nested ranges.

The other distractors represent common misconceptions: Azure supports prefixes as small as /29; the /16 space accommodates numerous subnets; and subnets with different prefixes coexist normally. The key point is that Azure validates subnet overlap at creation time, and nested ranges are treated as overlap.

Answer Key — Question 3​

False

Azure reserves 5 addresses in each subnet, regardless of size:

AddressUse reserved by Azure
First (e.g., .0)Network address
Second (e.g., .1)Default gateway
Third (e.g., .2)DNS mapped to Azure
Fourth (e.g., .3)DNS mapped to Azure
Last (e.g., .255)Broadcast

This behavior directly impacts capacity planning. In a /29 subnet, for example, there are 8 total addresses, but only 3 remain available for resources. Ignoring this reservation leads to provisioning errors when the subnet apparently "should have space".

Answer Key — Question 4​

Answer: B

VNet Peering requires that the address spaces of the involved VNets be completely distinct and non-overlapping. Since both use 10.1.0.0/16, Azure cannot establish routing between them without destination ambiguity.

Distractor A is incorrect because Global VNet Peering allows peering between different regions since 2019. Distractor C is incorrect because peering between different subscriptions is supported. Distractor D has no technical foundation, as the prefix size is not a restriction for peering. The root cause is exclusively address overlap, and the solution requires redesigning the address space before configuring peering.

Answer Key — Question 5​

Answer: A

Azure Bastion enforces two non-negotiable requirements for its subnet: the name must be exactly AzureBastionSubnet (with this exact spelling, including capitalization) and the prefix must be /26 or larger (i.e., /26, /25, /24, etc.). A /27 prefix would result in only 59 usable addresses, insufficient for Bastion to operate correctly in scale scenarios.

Distractor D is the most dangerous, as /29 is accepted in generic subnets but rejected for Bastion. Distractor C confuses with Gateway Subnet behavior, which also requires a specific name (GatewaySubnet) but doesn't require an exclusive VNet. Confusing the requirements of dedicated subnets for different services is a frequent error on the AZ-104 exam.