AZ-104 Implement and Manage Virtual Networking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Add an NSG rule to allow traffic between the two VNets.

  Why it's wrong here

  Network security groups (NSGs) provide stateful filtering of traffic at the subnet or network interface level based on source/destination IP, port, and protocol. They can be used to permit or deny traffic, but they are evaluated only for traffic that is actually routable between connected networks. Because the overlapping address spaces prevent the peering from being established at all, an NSG rule cannot create a route or resolve the conflict; the peering request will fail before any NSG evaluation occurs.

  When this WOULD be correct

  An NSG rule to allow traffic would be correct if VNet peering is already established but traffic is blocked. For example, two peered VNets with non-overlapping address spaces where default NSG rules deny inter-VNet traffic, and you need to allow specific communication.

• ✓

  Change one VNet to use a non-overlapping address space.

  Why this is correct

  For VNet peering to succeed, the address spaces of both virtual networks must be unique and must not overlap. Overlapping CIDR blocks make it impossible for Azure's routing engine to determine where to deliver traffic, so the peering request fails. You must either add a non-overlapping address range to one VNet or, if the existing overlapping range is in use, create a new VNet with a non-overlapping address space and migrate resources. Only then can Azure establish the bidirectional peering connection between the two VNets.

• ✗

  Create a private endpoint in each VNet.

  Why it's wrong here

  A private endpoint assigns a private IP address to an Azure PaaS service from a subnet in your VNet, enabling secure in-bound access to that service. It does not extend your VNet's address space, create a peering link, or in any way modify the CIDR range of a virtual network. Since the problem is that the two VNets' address spaces overlap, private endpoints leave that underlying conflict intact and the peering will still fail.

  When this WOULD be correct

  A question where two VNets need to securely connect to an Azure SQL Database without exposing it to the public internet, and the VNets have non-overlapping address spaces. Creating a private endpoint in each VNet would allow private connectivity to the database.

• ✗

  Attach a route table to both subnets.

  Why it's wrong here

  A route table with user-defined routes controls outbound traffic from a subnet by overriding system routes with a specified next hop type. It can influence where packets are sent, but it operates only after a virtual network connection exists and cannot change the address space of a VNet. The peering creation process will still reject the configuration because Azure requires non-overlapping address spaces at the control plane, independent of any routing table.

  When this WOULD be correct

  A route table would be correct if VNet peering was established but traffic between subnets in different VNets was not flowing due to asymmetric routing or missing user-defined routes (UDRs) to force traffic through a network virtual appliance (NVA).

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question