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.

• ✗

  Create the peering now and let Azure automatically route overlapping prefixes.

  Why it's wrong here

  VNet peering in Azure performs an address-space validation at creation time: if any prefix overlaps between the two VNets, the peering request is rejected outright. There is no routing preference or automatic longest-prefix matching that overrides this; overlapping address spaces are a supported failure condition, not a routing ambiguity. Therefore, attempting to peer the VNets as-is will simply fail, and Azure will not route anything.

  When this WOULD be correct

  If the question described a scenario where both VNets have non-overlapping address spaces but need to exchange routes, and the administrator wants to simplify routing, then creating the peering and letting Azure automatically manage routes (via system routes) would be correct.

• ✓

  Add a new non-overlapping address space to VNet-B, create replacement subnets there, and migrate workloads gradually.

  Why this is correct

  Adding a second, non-overlapping address space to VNet-B is the correct remediation because Azure permits multiple address ranges per VNet as long as they do not collide with peered networks. You create fresh subnets in the new range, migrate workloads onto them, and then remove the old overlapping range once it is empty. This resolves the conflict and lets peering succeed without downtime or IP fragmentation.

• ✗

  Attach a route table to VNet-B so traffic to VNet-A is forced through a firewall appliance.

  Why it's wrong here

  User-defined routes and forced tunneling can steer traffic through a firewall or network virtual appliance, but they cannot change the fundamental prerequisite that peered VNets must have non-overlapping address spaces. Because VNet peering is never even established when prefix conflicts exist, there is no effective route table that can be applied to 'fix' the overlap. Route tables operate on existing route paths, not on peering validation, so this option is entirely ineffective.

  When this WOULD be correct

  If the question involved controlling traffic flow between peered VNets (e.g., to inspect or filter traffic), attaching a route table with a firewall appliance would be correct to enforce routing policies.

• ✗

  Create a private endpoint between the two VNets so Azure ignores the overlap during connectivity checks.

  Why it's wrong here

  A private endpoint provides a managed, private IP address for a specific PaaS resource (for example, Azure SQL Database or Blob Storage) within your virtual network. It does not alter VNet-to-VNet peering constraints, and it cannot make two VNets with overlapping address spaces routable to each other. The overlap remains, so peering creation still fails; private endpoints are a connectivity model for Azure services, not a substitute for VNet peering.

  When this WOULD be correct

  When you need to connect to an Azure PaaS service (e.g., Storage, SQL Database) from a VNet without exposing it to the public internet, and you want the traffic to stay within the Microsoft backbone.

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

Same concept, more angles

4 more ways this is tested on AZ-104

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.