Implement and manage virtual networking practice questions

Azure reserves 5 IP addresses in every subnet: x.x.x.0 (network), x.x.x.1 (default gateway), x.x.x.2 and x.x.x.3 (mapped for Azure DNS), and the last address (broadcast).

A /24 contains 256 addresses. Subtracting Azure's 5 reserved addresses leaves 251 assignable. The 254 distractor is the traditional networking answer that only subtracts network and broadcast — the most common wrong answer on this question. 256 ignores reservations entirely, and 250 over-counts the reservation.

1. Compute the raw subnet size: 2^(32 - prefix length); for /24 that is 256.
2. Subtract Azure's 5 reserved addresses (first four addresses plus the last one).
3. Size subnets with this overhead in mind — this is also why Azure's smallest supported subnet is a /29, which yields only 3 usable addresses.

Exam tip: Azure reserves 5 IPs in every subnet, so a /24 gives you 251 usable addresses, not 254.

Because Azure reserves 5 addresses in every subnet, the smallest subnet prefix Azure supports is /29, which leaves 3 usable addresses out of 8.

/29 is both the minimum Azure allows and exactly sufficient for three NICs (8 total minus 5 reserved = 3 usable). /30 and /32 fail because their raw size cannot even cover Azure's 5 reservations, so Azure rejects them. /28 is valid but larger than necessary, so it does not satisfy the smallest-size constraint in the question.

1. Recall the Azure subnet limits: smallest is /29, largest is /2.
2. Work out usable addresses as (2^(32 - prefix)) minus 5 reserved.
3. Match the usable count to the number of NICs you must place, and leave growth headroom when the workload might scale.

Exam tip: The smallest Azure subnet is /29 — 8 addresses minus 5 reserved leaves 3 usable.

VNet peering is non-transitive: if A is peered with B and B is peered with C, A cannot communicate with C through B. In hub-spoke designs, spoke-to-spoke traffic requires either direct peering between spokes or user-defined routes that send traffic through a network virtual appliance or Azure Firewall in the hub.

The only thing missing in this scenario is a path between the spokes — the two existing peerings do not compose into one. The NSG distractor fails because default rules allow VNet (including peered) traffic. The global peering distractor describes an unrelated limitation. The subscription distractor is false because peering spans subscriptions and tenants.

1. Map the peerings: Spoke1↔Hub and Hub↔Spoke2 exist, but no Spoke1↔Spoke2 relationship or route does.
2. Remember the rule: peering never forwards traffic onward to a third VNet on its own.
3. Fix it by peering the spokes directly, or by deploying an NVA or Azure Firewall in the hub and adding UDRs in each spoke that point spoke-to-spoke traffic at it.

Exam tip: Peering is non-transitive — spokes peered to the same hub cannot talk to each other without direct peering or an NVA route.

Gateway transit lets peered VNets share one VPN or ExpressRoute gateway: the gateway-owning VNet enables "Allow gateway transit" and the consuming VNet enables "Use remote gateways". This is the standard hub-spoke pattern for hybrid connectivity.

From the spoke's perspective, the correct switch is "Use remote gateways" — it consumes the hub's gateway and receives its routes. Deploying a gateway per spoke contradicts the least-effort constraint. "Allow gateway transit" belongs on the hub side, not the spoke. Changing peering to global addresses region scope, not gateway sharing.

1. On the hub-to-spoke peering, enable "Allow gateway transit" so the hub offers its gateway.
2. On the spoke-to-hub peering, enable "Use remote gateways" so the spoke consumes it.
3. Verify the spoke VMs' effective routes now include the on-premises prefixes via the virtual network gateway next hop.
4. Note the constraint: a VNet using remote gateways cannot also have its own gateway.

Exam tip: Hub sets "Allow gateway transit"; spoke sets "Use remote gateways" — that pairing shares one gateway across the topology.

Azure VNet peering requires the address spaces of the two VNets to be completely non-overlapping. With identical or overlapping prefixes, Azure cannot build unambiguous routes, so the peering is rejected.

Re-addressing one VNet (for example, moving VNet-B to 10.1.0.0/16) is the only fix — overlap is a hard blocker. Resource group location is irrelevant to peering. A VNet-to-VNet VPN suffers the same overlap problem and adds cost. "Allow forwarded traffic" is a post-creation peering option unrelated to address planning.

1. Identify the overlap by comparing both VNets' address spaces in the portal or with az network vnet show.
2. Plan a new non-overlapping range for one VNet from your IPAM scheme.
3. Update that VNet's address space (this may require removing or re-addressing subnets and attached resources in the conflicting range).
4. Create the peering again once the ranges are disjoint.

Exam tip: Overlapping address space is a hard blocker for VNet peering — plan unique CIDR ranges across every VNet you may ever connect.

VNet peering comes in two flavors: regional (same region) and global (different regions). Both route traffic privately across Microsoft's backbone infrastructure between private IP addresses, with no gateways, no tunnels, and no public internet exposure.

The defining benefit of global peering is private, backbone-only, low-latency connectivity between regions without gateways. The IPsec distractor confuses peering with VNet-to-VNet VPN connections. The gateway-requirement distractor inverts peering's value proposition. The same-region-only distractor denies that global peering exists.

1. Choose peering (regional or global) when you need private VM-to-VM connectivity and do not need encryption in transit by an IPsec device.
2. Create the peering from both VNets (or one operation that configures both directions) — no gateway resources are needed.
3. Remember the notable global-peering limitation: resources behind a Basic internal load balancer are not reachable across a global peering.

Exam tip: Global VNet peering privately connects VNets across regions over Microsoft's backbone — no gateways, no internet.