Courseiva
← AZ-104
Full test
Implement and Manage Virtual Networking →mediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

A company already uses the address space 10.20.0.0/16 for a hub virtual network and 10.21.0.0/16 on-premises. A new spoke virtual network will be peered to the hub and may later connect to the on-premises network. Which address space should the administrator choose for the spoke to avoid future routing conflicts?

⚠ Common exam trap

A common mix-up: candidates assume any address space outside the hub's /16 is safe, but they forget to check for overlap with the on-premises network (10.21.0.0/16) or incorrectly think that a smaller subnet within the hub's range (like 10.20.64.0/19) can be used if it is not currently in use, ignoring that Azure requires completely non-overlapping ranges for peered VNets.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

10.22.0.0/16

(10.22.0.0/16) is correct because it is a unique, non-overlapping address space that does not conflict with the existing hub VNet (10.20.0.0/16) or the on-premises network (10.21.0.0/16). When a spoke VNet is peered to the hub and later connected to on-premises via VPN or ExpressRoute, Azure requires that all peered and connected address spaces be unique to avoid routing conflicts. Choosing a completely separate /16 ensures no future overlap.

Answer analysis

Option-by-option breakdown

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

  • ✗

    10.20.64.0/19

    Why it's wrong here

    10.20.64.0/19 is a subnet that falls entirely inside the hub VNet's 10.20.0.0/16 range. Even though the /19 prefix is smaller than the hub's /16, every IP address from 10.20.64.0 through 10.20.95.255 is already part of the hub VNet. Deploying a spoke with this range would create an immediate address overlap, preventing successful VNet peering and causing routing conflicts. Azure will reject the spoke's address space during validation or fail to establish connectivity.

    When this WOULD be correct

    If the hub used 10.20.0.0/17 and on-premises used 10.20.128.0/17, then 10.20.64.0/19 would be a valid non-overlapping spoke address.

  • ✗

    10.21.0.0/16

    Why it's wrong here

    10.21.0.0/16 is not inside the hub VNet (10.20.0.0/16), so it avoids direct overlap with the hub. However, the company's on-premises network already uses 10.21.0.0/16, so this range would duplicate an existing connected network. Azure would see the spoke's address space as conflicting with the on-premises network, which is problematic for hybrid connectivity, site-to-site VPN, or ExpressRoute. When the spoke tries to communicate on-prem, the overlapping subnets can cause asymmetric routing or prevent the connection from being established, creating a serious design flaw.

    When this WOULD be correct

    This option would be correct if the on-premises network used a different address space (e.g., 10.30.0.0/16) and the spoke needed to be in a separate, non-overlapping range that is not already used by the hub or on-premises.

  • ✓

    10.22.0.0/16

    Why this is correct

    This range does not overlap with either the hub VNet or the on-premises network. It also provides a full /16, which leaves enough room for multiple subnets and future growth while keeping peering and hybrid connectivity straightforward.

  • ✗

    10.20.128.0/17

    Why it's wrong here

    10.20.128.0/17 is also inside the hub VNet's 10.20.0.0/16 address space, specifically covering the upper half from 10.20.128.0 to 10.20.255.255. The /17 prefix is larger than the hub's /16? Actually, a /17 is a smaller address range than a /16, but it still is a subset—every address in 10.20.128.0/17 already belongs to the hub. Overlapping address spaces like this cannot be peered with the hub; Azure requires unique, non-overlapping VNet ranges to avoid ambiguous routing and network isolation. This overlap would cause the peering attempt to fail, and even if forced, could lead to unpredictable traffic forwarding.

    When this WOULD be correct

    This option would be correct if the hub virtual network used a different address space, such as 10.22.0.0/16, and the spoke needed a non-overlapping range within the 10.20.0.0/16 block, or if the question asked for a subnet within the hub's address space.

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.

✓10.22.0.0/16Correct answer▾

Why this is correct

This range does not overlap with either the hub VNet or the on-premises network. It also provides a full /16, which leaves enough room for multiple subnets and future growth while keeping peering and hybrid connectivity straightforward.

✗10.20.64.0/19Wrong answer — click to see why▾

Why this is wrong here

10.20.64.0/19 overlaps with the hub's 10.20.0.0/16 address space, causing routing conflicts when peered.

★ When this WOULD be the correct answer

If the hub used 10.20.0.0/17 and on-premises used 10.20.128.0/17, then 10.20.64.0/19 would be a valid non-overlapping spoke address.

Why candidates choose this

Candidates may think a smaller subnet within the hub's range is acceptable, not realizing that overlapping address spaces cause routing conflicts in peering.

✗10.21.0.0/16Wrong answer — click to see why▾

Why this is wrong here

Option B (10.21.0.0/16) overlaps with the on-premises network address space (10.21.0.0/16), which would cause routing conflicts when the spoke connects to on-premises via the hub.

★ When this WOULD be the correct answer

This option would be correct if the on-premises network used a different address space (e.g., 10.30.0.0/16) and the spoke needed to be in a separate, non-overlapping range that is not already used by the hub or on-premises.

Why candidates choose this

Candidates may mistakenly think that using a different subnet within the same /16 as the hub is acceptable, or they may overlook the on-premises address space and focus only on the hub's range.

✗10.20.128.0/17Wrong answer — click to see why▾

Why this is wrong here

Option D (10.20.128.0/17) overlaps with the hub virtual network's address space 10.20.0.0/16, which would cause routing conflicts when peered.

★ When this WOULD be the correct answer

This option would be correct if the hub virtual network used a different address space, such as 10.22.0.0/16, and the spoke needed a non-overlapping range within the 10.20.0.0/16 block, or if the question asked for a subnet within the hub's address space.

Why candidates choose this

Candidates may mistakenly think that using a smaller subnet within the hub's range is acceptable, not realizing that peering requires non-overlapping address spaces to avoid routing conflicts.

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?”

About these practice questions

Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-104 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-104 exam.