Courseiva
Implement and Manage Virtual NetworkingmediumMultiple ChoiceObjective-mapped

AZ-104 Implement and Manage Virtual Networking Practice Question

A company is creating a new spoke virtual network that will be peered to an existing hub VNet. The hub uses 10.40.0.0/16, and an on-premises network already uses 10.41.0.0/16. The spoke must support about 120 endpoints now and should allow room for growth. Which address space should you assign to the new spoke VNet?

⚠ Common exam trap

The trap here is that candidates often overlook the on-premises address space (10.41.0.0/16) and mistakenly choose an overlapping range like 10.41.128.0/24, assuming only the hub VNet's address space must be avoided.

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.42.0.0/24

(10.42.0.0/24) is correct because it provides 256 IP addresses (251 usable) for the spoke, which exceeds the requirement of ~120 endpoints with room for growth, and it does not overlap with the hub VNet (10.40.0.0/16) or the on-premises network (10.41.0.0/16). This ensures successful VNet peering without IP address conflicts.

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.40.64.0/25

    Why it's wrong here

    10.40.64.0/25 is a /25 subnet, giving only 128 total addresses and about 123 usable in Azure. While that might initially hold 120 VMs, it leaves almost no room for growth and would be fully consumed by the stated requirement. More critically, this range is a subset of the hub's 10.40.0.0/16 address space, so the spoke and hub would have overlapping IP ranges, which Azure VNet peering does not permit.

    When this WOULD be correct

    This option would be correct if the question asked for a subnet within the hub VNet (e.g., 'Which subnet should you create in the hub VNet for a new application tier?') and the hub VNet's address space is 10.40.0.0/16, with no on-premises overlap.

  • 10.42.0.0/24

    Why this is correct

    10.42.0.0/24 is a private RFC1918 range that does not overlap the hub VNet or on-premises addresses, so VNet peering will succeed. With 251 usable Azure IPs, it easily supports the required 120 endpoints and allows subnets to be carved for future workloads. The /24 prefix also provides flexibility to expand without reconfiguring the new spoke.

  • 10.41.128.0/24

    Why it's wrong here

    10.41.128.0/24 falls inside the on-premises network's 10.41.0.0/16 CIDR block. If you use this range for the spoke, Azure cannot establish a Site-to-Site VPN or ExpressRoute path to on-premises because overlapping address spaces create ambiguous routes. The peering itself might technically succeed, but traffic destined for on-premises would be incorrectly routed or dropped, so this range must be avoided.

    When this WOULD be correct

    This option would be correct if the on-premises network used a different address space (e.g., 10.42.0.0/16) and the hub VNet used 10.40.0.0/16, with no overlap, and the spoke needed a /24 subnet for about 120 endpoints with room for growth.

  • 192.168.10.0/26

    Why it's wrong here

    192.168.10.0/26 is a valid private subnet but contains only 64 IP addresses, with about 59 usable after Azure's reserved IPs. That is far below the 120 endpoints you need now, and it cannot accommodate any future expansion without redesigning the network. A /26 is better suited for smaller workloads, not for a spoke intended to host a production endpoint count of 120 or more.

    When this WOULD be correct

    This option would be correct in a scenario where the spoke VNet needs to support fewer than 62 endpoints (e.g., a small test environment) and there is no requirement for future growth, and the hub/on-premises networks use different address spaces that do not overlap with 192.168.10.0/26.

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.42.0.0/24Correct answer

Why this is correct

10.42.0.0/24 is a private RFC1918 range that does not overlap the hub VNet or on-premises addresses, so VNet peering will succeed. With 251 usable Azure IPs, it easily supports the required 120 endpoints and allows subnets to be carved for future workloads. The /24 prefix also provides flexibility to expand without reconfiguring the new spoke.

10.40.64.0/25Wrong answer — click to see why

Why this is wrong here

Option A (10.40.64.0/25) overlaps with the hub VNet's address space 10.40.0.0/16, which would cause a peering conflict. Azure requires non-overlapping address spaces for peered VNets.

★ When this WOULD be the correct answer

This option would be correct if the question asked for a subnet within the hub VNet (e.g., 'Which subnet should you create in the hub VNet for a new application tier?') and the hub VNet's address space is 10.40.0.0/16, with no on-premises overlap.

Why candidates choose this

Candidates may think that using a subset of the hub's address space is acceptable for a spoke, or they may focus on the /25 size being sufficient for 120 endpoints without checking for overlap with the hub.

10.41.128.0/24Wrong answer — click to see why

Why this is wrong here

Option C (10.41.128.0/24) overlaps with the on-premises network 10.41.0.0/16, which would cause routing conflicts when peered with the hub VNet.

★ 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.42.0.0/16) and the hub VNet used 10.40.0.0/16, with no overlap, and the spoke needed a /24 subnet for about 120 endpoints with room for growth.

Why candidates choose this

Candidates might choose this because it is a /24 subnet (providing 254 addresses) and they overlook the overlap with the on-premises network, focusing only on avoiding conflict with the hub VNet.

192.168.10.0/26Wrong answer — click to see why

Why this is wrong here

Option D (192.168.10.0/26) provides only 62 usable IP addresses, which is insufficient for the required 120 endpoints plus growth. Additionally, using a private IP range from 192.168.x.x is not necessary and may cause routing conflicts if other networks use that range.

★ When this WOULD be the correct answer

This option would be correct in a scenario where the spoke VNet needs to support fewer than 62 endpoints (e.g., a small test environment) and there is no requirement for future growth, and the hub/on-premises networks use different address spaces that do not overlap with 192.168.10.0/26.

Why candidates choose this

Candidates may choose this because 192.168.x.x is a familiar private IP range often used in small networks, and they might overlook the specific endpoint count requirement or assume a /26 subnet is sufficient without calculating the actual number of usable addresses.

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

This AZ-104 question is part of Courseiva's 1,049-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.

Variation 1. A company wants to peer a new spoke virtual network to an existing hub VNet. The hub uses 10.40.0.0/16, and the new spoke was created with 10.40.128.0/17 because that range seemed available in the branch office plan. Peering creation fails. What should the administrator do?

medium
  • A.Add a second address prefix to the spoke VNet and keep the overlapping range.
  • B.Change the spoke VNet to a non-overlapping address space before peering.
  • C.Enable gateway transit on the hub VNet before retrying peering.
  • D.Create custom DNS records for the spoke VNet so the address ranges no longer conflict.

Why B: VNet peering requires that the address spaces of the peered virtual networks do not overlap. The hub uses 10.40.0.0/16, and the spoke uses 10.40.128.0/17, which is a subset of the hub’s range. Azure blocks peering when there is any overlap to prevent routing conflicts. The correct fix is to change the spoke VNet to a non-overlapping address space, such as a different RFC 1918 range like 10.1.0.0/16, before attempting to peer.

Variation 2. A company wants to peer a new spoke virtual network with an existing hub VNet. The hub uses 10.20.0.0/16. The spoke was created with 10.20.1.0/24 because that range was still available in the IPAM spreadsheet. VNet peering creation fails. What should the administrator do first?

medium
  • A.Enable gateway transit on the hub and retry the peering.
  • B.Add a route table to the spoke subnet so the networks can communicate.
  • C.Change the spoke VNet address space to a non-overlapping range, then recreate or update peering.
  • D.Configure a custom DNS server in the spoke to translate the overlapping range.

Why C: VNet peering in Azure requires that the address spaces of the peered virtual networks do not overlap. The hub uses 10.20.0.0/16, and the spoke uses 10.20.1.0/24, which is a subset of the hub's range. This overlap causes the peering creation to fail. The administrator must first change the spoke's address space to a non-overlapping range (e.g., 10.21.0.0/24) and then recreate or update the peering.

Variation 3. A company plans a new spoke virtual network that must be peered to an existing hub VNet using 10.0.0.0/16. The spoke will need two subnets: one sized for about 120 VMs and another for about 40 VMs. The new address space must not overlap the hub or the on-premises range 10.1.0.0/16. Which VNet address space is the best choice?

medium
  • A.10.0.1.0/24
  • B.10.1.0.0/22
  • C.10.2.0.0/22
  • D.10.0.0.0/24

Why C: (10.2.0.0/22) is correct because it provides a non-overlapping address space with the hub VNet (10.0.0.0/16) and on-premises (10.1.0.0/16). The /22 prefix offers 1024 IP addresses, which is sufficient for subnets supporting 120 VMs and 40 VMs, while avoiding any overlap with the existing ranges.

Variation 4. 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?

medium
  • A.Add an NSG that allows traffic between the two VNets.
  • B.Reconfigure VNet-Shared to use a non-overlapping address range, then recreate its subnets and migrate workloads.
  • C.Rename VNet-Shared so Azure treats it as a different network.
  • D.Enable gateway transit on both VNets so Azure can route around the overlap.

Why B: VNet peering requires that the address spaces of the two VNets do not overlap. VNet-Prod uses 10.30.0.0/16, which includes the range 10.30.64.0/18 used by VNet-Shared, causing the overlap error. The only way to resolve this without changing VNet-Prod is to reconfigure VNet-Shared to use a non-overlapping address range, which involves deleting and recreating its subnets and migrating workloads, as stated in option B.

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.