A team is creating a new spoke VNet that will later be peered to an existing hub VNet and connected to on-premises networks. The proposed address space for the spoke is 10.60.1.0/24. The hub already uses 10.60.0.0/16. What should the administrator do before deploying the spoke?
VNet peering requires non-overlapping address spaces. Because 10.60.1.0/24 is contained inside the hub's 10.60.0.0/16 range, the spoke cannot be safely peered as proposed. The correct fix is to pick a different CIDR block that does not overlap with the hub or any other connected network, such as 10.61.1.0/24.
Why this answer
Option B is correct because VNet address spaces must not overlap when peered or connected via VPN/ExpressRoute. The proposed spoke address 10.60.1.0/24 falls within the hub's 10.60.0.0/16 range, creating an overlap that would prevent successful peering and routing. A non-overlapping address space like 10.61.1.0/24 ensures unique IP ranges, allowing proper route propagation and connectivity.
Exam trap
The trap here is that candidates mistakenly think a smaller subnet within a larger address space is acceptable for VNet peering, but Azure requires completely non-overlapping address spaces to avoid routing ambiguity.
How to eliminate wrong answers
Option A is wrong because using a subnet that is a subset of the hub's address space still causes overlap; Azure VNet peering requires non-overlapping address spaces regardless of subnet size. Option C is wrong because a private endpoint does not separate routing tables; it provides private connectivity to PaaS services and does not resolve address space overlap issues. Option D is wrong because enabling gateway transit on the hub peering is a configuration step done after the VNets are created and peered, not a prerequisite for deploying the spoke; it also does not fix overlapping address spaces.