Two application teams created separate VNets for independent workloads. VNet-A uses 10.40.0.0/16 and VNet-B uses 10.40.128.0/17. The teams want to peer the VNets so both apps can communicate privately. What should the administrator do first?

Create the peering now and add a route table to one VNet later.

Peering cannot be established successfully between VNets with overlapping address spaces, even if routes are added later.

Add an NSG rule that allows traffic between the two address ranges.

Network security groups control traffic filtering, but they do not resolve overlapping IP ranges or enable peering.

Enable gateway transit on both VNets so overlapping ranges can route through a shared gateway.

Gateway transit does not permit overlapping address spaces. The VNets still must be uniquely addressed before peering.

What does this AZ-104 question test?

CIDR notation defines the prefix length.

What is the correct answer to this question?

The correct answer is: Renumber one VNet so its address space no longer overlaps before creating the peering. — Azure VNet peering requires each virtual network to have a unique, non-overlapping address space. In this scenario, 10.40.0.0/16 contains 10.40.128.0/17, so Azure will not allow the peering until one side is renumbered. The correct first action is to change one VNet to a different prefix and then create the peering. This is an addressing problem, not a routing or security rule problem. Why others are wrong: Route tables and NSGs cannot fix overlapping CIDRs because they operate after address assignment. Gateway transit also does not bypass the peering requirement for unique address spaces. The issue must be solved at the IP planning layer first, before any connectivity features can work.

What should I do if I get this AZ-104 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.