Technical Lab: Plan and implement network segmentation and address spaces
Questionsβ
Question 1 β Multiple Choiceβ
An architecture team needs to plan the address space for a Virtual Network (VNet) in Azure. The VNet will be divided into four subnets: one for application VMs, one for database, one for an Azure Application Gateway v2, and one for an Azure Bastion. The team discusses which CIDR range should be reserved for the Application Gateway v2.
What is the correct minimum subnet size requirement for Application Gateway v2?
A) /29, since Application Gateway v2 requires at least 3 usable addresses
B) /28, since Application Gateway v2 requires a dedicated subnet with at least 100 available addresses
C) /24, since Application Gateway v2 shares the subnet with other resources and needs ample space
D) /27, since Application Gateway v2 requires a dedicated subnet with at least 27 available addresses
Question 2 β Technical Scenarioβ
An engineer configures peering between two VNets in the same region:
- VNet-A:
10.1.0.0/16 - VNet-B:
10.1.128.0/17
After configuring peering on both sides, resources in the VNets cannot communicate with each other. No NSG rules are blocking traffic.
What is the most likely cause of the failure?
A) Peering between VNets in the same region does not support automatic routing and requires UDRs
B) The address spaces of the two VNets overlap, preventing peering establishment
C) Peering was configured only on one side and needs to be enabled on both VNets separately
D) VNets with /16 and /17 prefixes cannot be peered because the prefix sizes are incompatible
Question 3 β True or Falseβ
Statement: In an Azure Virtual Network, it is possible to add additional address spaces to an existing VNet without having to previously remove already provisioned subnets or active peering connections.
Is the statement True or False?
Question 4 β Technical Scenarioβ
An organization operates three isolated environments in Azure: Production, Development, and DMZ. Each environment is a separate VNet. The team needs to ensure that:
- DMZ can communicate with Production and Development
- Production and Development do not communicate directly with each other
The architect proposes the following design:
VNet-Prod <--> VNet-DMZ
VNet-Dev <--> VNet-DMZ
VNet-Prod <--> VNet-Dev (no direct peering)
A developer argues that since VNet-Prod and VNet-Dev are both peered with VNet-DMZ, traffic between them will automatically flow through the DMZ as a hub.
What is the correct assessment of this proposal?
A) The developer is correct: transitive peering is natively supported by Azure when a central VNet acts as a hub
B) The developer is incorrect: VNet peering in Azure is not transitive, but traffic between Prod and Dev can flow through DMZ if UDRs and an NVA or Azure Firewall are configured in the DMZ
C) The developer is incorrect: the only way to allow communication between Prod and Dev is to create a direct peering between them
D) The developer is correct, but only if all three VNets are in the same Azure region
Question 5 β Multiple Choiceβ
A team plans to segment a VNet with CIDR 10.0.0.0/16 into functional subnets. Azure reserves five IP addresses in each subnet. Consider the subnet 10.0.1.0/24:
Which are the addresses reserved by Azure in this subnet?
A) 10.0.1.0, 10.0.1.1, 10.0.1.2, 10.0.1.3, and 10.0.1.255
B) 10.0.1.0, 10.0.1.1, 10.0.1.2, 10.0.1.254, and 10.0.1.255
C) 10.0.1.1, 10.0.1.2, 10.0.1.3, 10.0.1.4, and 10.0.1.255
D) 10.0.1.0, 10.0.1.1, 10.0.1.128, 10.0.1.254, and 10.0.1.255
Answer Key and Explanationsβ
Answer Key β Question 1β
Answer: B
Application Gateway v2 requires a dedicated subnet and Microsoft recommends it has at least a /24 prefix for production environments, but the documented minimum functional requirement is /28 for smaller instances. The critical point is that the subnet must be exclusive to the Application Gateway v2, meaning no other resources can be allocated in it. A /29 provides only 3 usable addresses (discounting Azure's 5 reserves), which is insufficient to accommodate the service's automatic scaling. A /27 is larger than /28, but the documented minimum requirement is /28. Choosing /29 would result in deployment failure or inability to scale, while /24 is a production best practice recommendation, not the required minimum.
Answer Key β Question 2β
Answer: B
Azure does not allow peering between VNets whose address spaces overlap. In the described scenario, 10.1.0.0/16 covers the range 10.1.0.0 to 10.1.255.255, and 10.1.128.0/17 covers 10.1.128.0 to 10.1.255.255. The second range is entirely contained within the first, which constitutes complete overlap. Peering simply cannot be established under this condition, regardless of NSGs or routing configurations. The conceptual error in alternatives A and D is confusing routing or prefix limitations with the fundamental restriction of address overlap. Alternative C is a real and common error, but doesn't apply here because the statement affirms that peering was configured on both sides.
Answer Key β Question 3β
Answer: False
This is an important and frequently underestimated limitation. To add new address spaces to a VNet that has active peerings, it is necessary to remove existing peerings before making the change and recreate them afterward. Azure prevents modification of a peered VNet's address space to avoid inconsistencies in partner VNets' routing tables. Existing subnets within the already allocated space do not need to be removed, but the dependency on peerings is the real restriction. Ignoring this behavior in expansion planning can cause unexpected unavailability during the maintenance window.
Answer Key β Question 4β
Answer: B
VNet peering in Azure is not transitive by default. This means that even though VNet-Prod and VNet-Dev are both peered with VNet-DMZ, traffic between Prod and Dev does not automatically flow through the DMZ. Each peering is a point-to-point relationship and Azure does not route packets through an intermediate VNet without explicit configuration. To enable transitive communication using the DMZ as a hub, it is necessary to deploy an NVA (Network Virtual Appliance) or Azure Firewall in the VNet-DMZ and configure UDRs (User Defined Routes) in the Prod and Dev subnets pointing to this device as the next hop. Alternative C is wrong because there are other means besides direct peering. Alternatives A and D contradict the documented service behavior.
Answer Key β Question 5β
Answer: A
Azure reserves exactly five addresses in each subnet, with specific functions:
| Address | Function |
|---|---|
10.0.1.0 | Network address (subnet identification) |
10.0.1.1 | Default gateway reserved by Azure |
10.0.1.2 | Azure internal DNS |
10.0.1.3 | Reserved for future use by Azure |
10.0.1.255 | Broadcast address (not used, but reserved) |
The most common misconception, represented by alternative B, is assuming that 10.0.1.254 is reserved as in the classic networking model, which does not occur in Azure. Reserved addresses are always the first four and the last one. Choosing B would result in allocating 10.0.1.3 as a VM address, which Azure would silently never assign, causing confusion in capacity planning.