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 that allows traffic between the two VNets.

  Why it's wrong here

  Network security groups (NSGs) are stateful packet filters applied to subnets or NICs, but they only operate on traffic that Azure can already route between peered networks. VNet peering creation first validates that the configured address spaces do not overlap; with both VNets using 10.30.0.0/16, the peering cannot be established at all. Because no peering link exists, the NSG would never see inter-VNet traffic, and it cannot change the overlapping address space in any way.

  When this WOULD be correct

  An administrator needs to restrict traffic between two peered VNets to specific ports or IPs; adding an NSG on the subnet or NIC would enforce that security policy.

• ✓

  Reconfigure VNet-Shared to use a non-overlapping address range, then recreate its subnets and migrate workloads.

  Why this is correct

  Azure VNet peering requires the two address spaces to be unique and non-overlapping. If any prefix overlaps, the peering cannot be created. The correct fix is to renumber one VNet by introducing a different address range, rebuilding or moving subnets as needed, and then removing the conflicting range. This addresses the root cause instead of trying to work around it with security or routing settings.

• ✗

  Rename VNet-Shared so Azure treats it as a different network.

  Why it's wrong here

  VNet names are Azure Resource Manager labels used for identification and management; they are not part of the network-layer routing decision. The peering validation compares the CIDR ranges (both 10.30.0.0/16), not the resource names, so renaming or recreating VNet-Shared with a different label leaves the identical overlapping address space in place. Because the conflict is purely one of IP prefixes, a name change cannot satisfy Azure's peering requirement and the peering will still be rejected.

  When this WOULD be correct

  If the question involved a naming conflict (e.g., two VNets with the same name in different resource groups) and the goal was to avoid confusion in Azure Portal, renaming one would resolve the conflict without affecting address spaces.

• ✗

  Enable gateway transit on both VNets so Azure can route around the overlap.

  Why it's wrong here

  Gateway transit lets a peered VNet borrow an existing VPN gateway from a hub VNet, but it requires a successful VNet peering link and does not excuse overlapping address spaces. The peering validation checks the VNet address prefixes before any gateway or routing configuration is considered, so the overlap between the two 10.30.0.0/16 ranges causes the peering attempt to fail outright. Even if transit were somehow configured, Azure would have no unique destination route for the duplicated prefix, creating ambiguous routing rather than a workaround.

  When this WOULD be correct

  This option would be correct if the VNets had non-overlapping address spaces and the goal was to allow VNet-Shared to use a VPN gateway in VNet-Prod for connectivity to on-premises networks, with gateway transit enabled on VNet-Prod and use remote gateways on VNet-Shared.

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