mediummultiple choiceObjective-mapped

A company needs to peer VNet-Prod, which uses 10.30.0.0/16, with VNet-Shared, which uses 10.30.64.0/18. The peering creation fails with an address-space overlap error. The team can renumber the shared environment, but they do not want to change any addresses in VNet-Prod. What should the administrator do before retrying the peering?

Question 1mediummultiple choice
Full question →

A company needs to peer VNet-Prod, which uses 10.30.0.0/16, with VNet-Shared, which uses 10.30.64.0/18. The peering creation fails with an address-space overlap error. The team can renumber the shared environment, but they do not want to change any addresses in VNet-Prod. What should the administrator do before retrying the peering?

Answer choices

Why each option matters

Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.

A

Distractor review

Add an NSG that allows traffic between the two VNets.

NSGs filter traffic after connectivity exists, but they do not resolve overlapping address spaces.

B

Best answer

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

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.

C

Distractor review

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

VNet names are only labels and have no effect on address-space validation or peering rules.

D

Distractor review

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

Gateway transit helps share an existing gateway, but it does not allow peering networks with overlapping IP ranges.

Common exam trap

Common exam trap: usable hosts are not the same as total addresses

Subnetting questions often tempt you into counting all addresses. In normal IPv4 subnets, the network and broadcast addresses are not usable host addresses.

Technical deep dive

How to think about this question

Subnetting questions test whether you can identify the network, broadcast address, usable range, mask and correct subnet. Slow down enough to calculate the block size correctly.

KKey Concepts to Remember

  • CIDR notation defines the prefix length.
  • Block size helps identify subnet boundaries.
  • Network and broadcast addresses are not usable hosts in normal IPv4 subnets.
  • The required host count determines the smallest suitable subnet.

TExam Day Tips

  • Write the block size before choosing the subnet.
  • Check whether the question asks for hosts, subnets or a specific address range.
  • Do not confuse /24, /25, /26 and /27 host counts.

Related practice questions

Related AZ-104 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

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: Reconfigure VNet-Shared to use a non-overlapping address range, then recreate its subnets and migrate workloads. — Azure VNet peering requires each virtual network to have unique, non-overlapping address spaces. The failure happens before traffic policies or gateway settings matter. Because VNet-Prod must stay unchanged, the administrator should renumber VNet-Shared by assigning a new, non-overlapping CIDR block, moving or recreating subnets, and migrating workloads to the new address space. After the overlap is removed, peering can be created successfully. Why others are wrong: NSGs do not influence whether Azure allows the peering object to be created. Renaming a VNet changes only metadata, not its IP ranges. Gateway transit is for sharing a gateway across peerings; it does not bypass the fundamental requirement that peered VNets cannot overlap in address space.

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.

Discussion

Loading comments…

Sign in to join the discussion.