A VNet peering attempt between VNet-A and VNet-B fails because both VNets include 10.40.0.0/16. VNet-B hosts active workloads, so the team wants to readdress it without downtime. Which two actions should the administrator take? Select two.

Enable gateway transit on both VNets to bypass the overlap check.

Gateway transit changes routing behavior, but it does not remove the address-space overlap restriction for peering.

Create a private endpoint in VNet-A so the peering can use private connectivity.

Private endpoints are for PaaS service access, not for resolving overlapping CIDR blocks between VNets.

Associate a route table with VNet-B to force Azure to accept the peering.

Route tables influence packet forwarding, but they do not change VNet peering validation requirements.

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: Add a new non-overlapping address space to VNet-B. — Azure VNet peering cannot be created when address spaces overlap. The fix is to introduce a non-overlapping address range for the affected VNet and migrate workloads into that new space before removing the conflicting prefix. This keeps services available while the network is readdressed. Once the overlap is gone, the peering operation can succeed because Azure now sees two distinct IP spaces. Why others are wrong: Gateway transit, private endpoints, and route tables solve different networking problems and do not change the peering validation rule. Azure checks the VNet address spaces themselves, not routes or service endpoints, before allowing peering. The overlap must be removed from the CIDR design first.

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.