Hub-and-Spoke Routing with Overlapping Address Space

What will not work. Adding 10.10.0.0/16 to the hub VNet address space is invalid because that prefix already exists on-premises and is being learned over the existing site-to-site connection. Azure will reject or effectively ignore an address space that collides with a route already present, and even if it were accepted, the two destinations would be indistinguishable - traffic to 10.10.1.5 could be delivered to either the existing datacenter or the acquired one. A second site-to-site connection on the same gateway does not solve this: the gateway routes by prefix, and two connections advertising the same prefix create an ambiguous or flapping path.

What will work. The overlapping space must be resolved before it reaches Azure. Options, in order of preference:

1. Renumber or NAT at the acquired site. Put a NAT device at the acquired datacenter edge that translates 10.10.0.0/16 to an unused range such as 10.30.0.0/16 before the tunnel. Azure then sees a unique prefix and routing is unambiguous. This is the cleanest option and requires no changes to existing Azure workloads.
2. Use a distinct summary for the acquired site if only part of its space is actually needed, and NAT or renumber only the reachable subset.
3. A separate VNet with its own gateway and peering, still requiring NAT or renumbering, because the collision is at the packet level, not the VNet level.

Also check. The acquired company's DNS suffixes, domain membership, and any services that embed IP addresses in configuration. Address overlap usually surfaces as a DNS or application problem even after routing is fixed.

Cause. Spoke-to-spoke traffic over VNet peering is direct only when the peering is configured to allow it and no route table overrides the system route. The route table change on the spokes almost certainly added a user-defined route (for example 0.0.0.0/0 or 10.0.0.0/8) pointing to a firewall appliance or the hub's NVA. A UDR takes precedence over the peering system route for the matching prefix, so spoke-to-spoke packets are now sent to the hub, inspected, and forwarded - adding a hop and doubling latency.

Restore direct paths.

1. Inspect effective routes on a spoke VM NIC (Get-AzEffectiveRouteTable or the portal's Effective routes blade) to confirm which UDR is capturing spoke-to-spoke traffic.
2. Narrow the UDR so it does not cover the other spokes' address spaces. If the intent was to force internet-bound traffic through the firewall, use 0.0.0.0/0 only, and rely on the more specific peering routes for 10.21.0.0/16 through 10.23.0.0/16. Longest-prefix match means the /16 peering routes win over 0.0.0.0/0.
3. If inspection of spoke-to-spoke traffic is genuinely required, accept the hub hop and place the firewall in the hub with an appropriate VM size and accelerated networking; do not expect direct peering performance.
4. Confirm allowVirtualNetworkAccess and allowForwardedTraffic are true on the relevant peerings, and that the firewall subnet has IP forwarding enabled on its NIC.

Judgement. The design question is whether spoke-to-spoke inspection is a requirement or an accident of a broad UDR. The exam expects you to read effective routes rather than assume peering implies direct flow.