Managing DNS in a hybrid environment (Azure + On-premises) can feel like a high-stakes game of “telephone.” As of 2026, the industry standard has moved away from the old “DNS Forwarder VMs” and settled on the Azure DNS Private Resolver.

Here are the primary resolution patterns you should know to keep your traffic flowing smoothly over VPN or ExpressRoute.

1. The Modern Hub-Spoke Pattern (Azure DNS Private Resolver)

This is the recommended architecture. It uses a managed service instead of VMs, reducing overhead and providing built-in high availability.

How it Works:

• Azure to On-Prem: You create an Outbound Endpoint in your Hub VNet and a Forwarding Ruleset. You link this ruleset to your Spoke VNets. When an Azure VM tries to resolve internal.corp.com, Azure DNS sees the rule and sends the query to your on-premises DNS servers.
• On-Prem to Azure: You create an Inbound Endpoint (a static IP in your VNet). On your local Windows/Linux DNS servers, you set up a Conditional Forwarder for Azure zones (like privatelink.blob.core.windows.net) pointing to that Inbound Endpoint IP.

2. The “Private Link” Pattern (Split-Brain Avoidance)

One of the biggest “gotchas” in hybrid setups is resolving Azure Private Endpoints. If you aren’t careful, your on-premises machine might resolve the public IP of a storage account instead of the private one.

• The Pattern: Always forward the public service suffix (e.g., blob.core.windows.net) to the Azure Inbound Endpoint, not just the privatelink version.
• Why: Azure DNS is “smart.” If you query the public name from an authorized VNet, it automatically checks for a matching Private DNS Zone and returns the private IP. If you only forward the privatelink zone, local developers have to change their connection strings, which is a massive headache.

3. Legacy DNS Forwarder Pattern (IaaS VMs)

While largely replaced by the Private Resolver, some organizations still use Domain Controllers or BIND servers sitting in a Hub VNet.

4. Key Configuration Rules for 2026

• The 168.63.129.16 Rule: This is the “Magic IP” for Azure DNS. You cannot query this IP directly from on-premises. You must use an Inbound Endpoint as a bridge.
• VNet Delegation: Remember that the subnets used for Private Resolver endpoints must be delegated specifically to Microsoft.Network/dnsResolvers. You can’t put VMs or other resources in those subnets.
• Avoid Recursive Loops: Never point an Azure Outbound Forwarder to an on-premises server that is also configured to forward those same queries back to Azure. This creates a “DNS death loop” that will drop your resolution performance to zero.

Pro-Tip: If you are using Azure Virtual WAN, the DNS Private Resolver can be integrated into the Hub, allowing all connected spokes and branches to share the same resolution logic without redundant configurations.

Starting a fresh greenfield deployment?

For a greenfield deployment in 2026, you have the advantage of skipping the “technical debt” of legacy VM forwarders. The goal is a Hub-and-Spoke architecture using the Azure DNS Private Resolver.

This setup ensures that your on-premises office and your Azure cloud act as a single, cohesive network for naming.

1. The Essential Architecture

In a greenfield setup, you should centralize the resolver in your Hub VNet.

• Inbound Endpoint: Provides a static IP address in your Hub VNet. Your on-premises DNS servers (Windows/BIND) will use this as a Conditional Forwarder.
• Outbound Endpoint: A dedicated egress point that Azure DNS uses to send queries out to your on-premises DNS.
• Forwarding Ruleset: A logic engine where you define: “If a query is for corp.local, send it to On-Prem IP 10.50.0.4.”

2. Step-by-Step Implementation Strategy

Step 1: Subnet Design (Non-Negotiable)

The Private Resolver requires two dedicated subnets in your Hub VNet. They cannot contain any other resources (no VMs, no Gateways).

• Subnet 1 (Inbound): Min /28. Delegate to Microsoft.Network/dnsResolvers.
• Subnet 2 (Outbound): Min /28. Delegate to Microsoft.Network/dnsResolvers.

Step 2: The “Private Link” Rule of Thumb

To avoid the common “2026 DNS Trap” where resolution fails for Private Endpoints, do not just forward privatelink zones.

• On-Prem Config: Create conditional forwarders for the public suffixes (e.g., blob.core.windows.net, database.windows.net) pointing to your Azure Inbound Endpoint IP.
• Why? This allows the Azure Resolver to handle the logic. If a Private Endpoint exists, it returns the private IP. If not, it returns the public IP. This keeps your application connection strings identical regardless of where the app sits.

Step 3: Global Reach (Spoke VNets)

You don’t need a resolver in every spoke.

• Link your Forwarding Ruleset to every Spoke VNet.
• This instantly gives all spokes the ability to resolve on-premises names without changing their DNS server settings from “Azure Provided.”

3. Financial Blueprint (2026 Pricing)

Budgeting for this is straightforward but requires awareness of the “Base Fee.”

4. Greenfield “Gotchas” to Avoid

• DNS Loops: Never link a Forwarding Ruleset to the same VNet where the Inbound Endpoint lives if that ruleset contains a rule pointing back to that Inbound Endpoint. You’ll create a recursive loop that crashes resolution.
• The 168.63.129.16 Myth: In 2026, some older documentation still suggests querying the Azure WireServer IP directly from on-prem. This will not work. Traffic to this IP is only routable within the Azure backbone.
• Subnet Sizing: While /28 is the minimum, if you plan on a massive global architecture with dozens of endpoints, consider a /27 to avoid future re-addressing headaches.

deploy this via Terraform

Deploying a Private DNS Resolver via Terraform requires a specific sequence of resources. In a greenfield scenario, you’ll likely want to use the Azure Verified Modules (AVM) or the standard azurerm provider resources.

Here is the “cleanest” implementation using standard azurerm resources for a Hub-and-Spoke architecture.

1. Subnet Delegation (The Foundation)

You cannot use standard subnets. You must delegate them to Microsoft.Network/dnsResolvers.

Terraform

# Inbound Subnet
resource "azurerm_subnet" "dns_inbound" {
  name                 = "snet-dns-inbound"
  resource_group_name  = azurerm_resource_group.hub.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.0.10.0/28"]
  delegation {
    name = "delegation"
    service_delegation {
      name    = "Microsoft.Network/dnsResolvers"
      actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    }
  }
}
# Outbound Subnet
resource "azurerm_subnet" "dns_outbound" {
  name                 = "snet-dns-outbound"
  resource_group_name  = azurerm_resource_group.hub.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.0.10.16/28"]
  delegation {
    name = "delegation"
    service_delegation {
      name    = "Microsoft.Network/dnsResolvers"
      actions = ["Microsoft.Network/virtualNetworks/subnets/join/action"]
    }
  }
}

2. The Resolver & Endpoints

The Resolver itself is just a container; the endpoints do the heavy lifting.

Terraform

resource "azurerm_private_dns_resolver" "main" {
  name                = "res-hub-dns"
  resource_group_name = azurerm_resource_group.hub.name
  location            = azurerm_resource_group.hub.location
  virtual_network_id  = azurerm_virtual_network.hub.id
}
resource "azurerm_private_dns_resolver_inbound_endpoint" "inbound" {
  name                    = "inbound-endpoint"
  private_dns_resolver_id = azurerm_private_dns_resolver.main.id
  location                = azurerm_private_dns_resolver.main.location
  ip_configurations {
    subnet_id                    = azurerm_subnet.dns_inbound.id
    private_ip_allocation_method = "Dynamic" # Azure will assign an IP from the subnet
  }
}
resource "azurerm_private_dns_resolver_outbound_endpoint" "outbound" {
  name                    = "outbound-endpoint"
  private_dns_resolver_id = azurerm_private_dns_resolver.main.id
  location                = azurerm_private_dns_resolver.main.location
  subnet_id               = azurerm_subnet.dns_outbound.id
}

3. Forwarding Rulesets (The “Logic”)

This is where you tell Azure to send traffic to your on-premises DNS servers.

Terraform

resource "azurerm_private_dns_resolver_dns_forwarding_ruleset" "onprem" {
  name                                       = "ruleset-onprem"
  resource_group_name                        = azurerm_resource_group.hub.name
  location                                   = azurerm_resource_group.hub.location
  private_dns_resolver_outbound_endpoint_ids = [azurerm_private_dns_resolver_outbound_endpoint.outbound.id]
}
resource "azurerm_private_dns_resolver_forwarding_rule" "corp_local" {
  name                      = "rule-corp-local"
  dns_forwarding_ruleset_id = azurerm_private_dns_resolver_dns_forwarding_ruleset.onprem.id
  domain_name               = "corp.local." # Note the trailing dot
  enabled                   = true
  target_dns_servers {
    ip_address = "10.50.0.4" # Your On-Prem DNS Server IP
    port       = 53
  }
}

4. Linking to Spokes

To make this work for your entire environment, you must link the ruleset to your spoke VNets.

Terraform

resource "azurerm_private_dns_resolver_virtual_network_link" "spoke_links" {
  name                      = "link-spoke-app"
  dns_forwarding_ruleset_id = azurerm_private_dns_resolver_dns_forwarding_ruleset.onprem.id
  virtual_network_id        = azurerm_virtual_network.spoke_app.id
}

Important Terraform Considerations for 2026:

• Trailing Dots: Always include the trailing dot in domain_name (e.g., internal.com.). If omitted, some versions of the provider may show a perpetual “diff” in your plan.
• IP Outputs: Since the Inbound Endpoint uses dynamic allocation, use an output block to capture the IP address. You’ll need this IP to configure the conditional forwarders on your On-Premises DNS servers.Terraformoutput "dns_inbound_ip" { value = azurerm_private_dns_resolver_inbound_endpoint.inbound.ip_configurations[0].private_ip_address }
• Lifecycle Management: Endpoints can take 10-15 minutes to deploy. If you are running this in a CI/CD pipeline, ensure your timeout settings are sufficient.

Does your current Terraform setup include a central “Hub” module where this configuration would live?

In Microsoft Azure, networking strategy revolves around how you connect virtual networks (VNets) and how data actually travels between them. Understanding this is key to building a scalable, secure environment.

1. VNet Peering: The Fundamentals

VNet Peering connects two Azure Virtual Networks over the Microsoft backbone network. Once peered, the two networks behave as one for connectivity purposes.

• Regional Peering: Connects VNets within the same Azure region.
• Global Peering: Connects VNets across different Azure regions.

Key Characteristics:

• Low Latency: Traffic stays on the private Microsoft fiber; it never touches the public internet.
• Performance: Offers the same high-bandwidth connection as if the resources were in the same network.
• No Gateway Required: Unlike VPNs, peering doesn’t require a virtual network gateway unless you are “chaining” transit traffic.

2. Common Peering Strategies

Hub-and-Spoke Topology

This is the “gold standard” for enterprise architecture.

• The Hub: A central VNet that hosts shared services (Firewalls, ExpressRoute gateways, DNS).
• The Spokes: Individual VNets (e.g., for different departments or apps) that peer with the Hub.
• The Benefit: It centralizes security and reduces costs by sharing expensive resources like an Azure Firewall.

Mesh Topology

Every VNet is peered directly to every other VNet.

• Use Case: Small environments with very few VNets (3 or less).
• The Downside: It becomes a management nightmare as you scale, because peering is not transitive. If VNet A is peered with B, and B is peered with C, A and C cannot talk to each other unless you peer them directly or use a “Transit” setup.

3. Understanding Traffic Flow

How data moves depends heavily on your User Defined Routes (UDRs) and Gateway Transit settings.

Default Flow (Direct)

In a simple peering, traffic flows directly from VM-A to VM-B. Azure handles the routing automatically via “System Routes.”

Hub-and-Spoke with Transit

If you want Spokes to communicate with each other or the internet through the Hub, you must configure:

1. Allow Gateway Transit: Set on the Hub peering.
2. Use Remote Gateways: Set on the Spoke peering.
3. Network Virtual Appliance (NVA): Usually a Firewall in the Hub. You must create a UDR on the Spoke subnets to “force” traffic to the Firewall’s IP address instead of letting it go direct.

Traffic Flow Table

4. Crucial Constraints

• Overlapping Address Space: You cannot peer two VNets if their IP address ranges overlap.
• Transitivity: Peering is strictly 1:1. To move traffic “through” a VNet to another destination, you must use a Network Virtual Appliance (like Azure Firewall) or Azure Route Server.

In a multi-region Azure architecture, the strategy shifts from connecting individual workloads to connecting entire regional ecosystems. As of 2026, the industry standard has moved toward high-automation models to manage the complexity of cross-region routing.

There are two primary ways to architect this: Global Hub-and-Spoke and Azure Virtual WAN.

1. Global Hub-and-Spoke (Self-Managed)

In this model, you replicate the Hub-and-Spoke design in every region where you have a footprint and then link the hubs together.

The Strategy

• Regional Hubs: Each region (e.g., East US, West Europe) has its own Hub VNet containing a local Azure Firewall and Gateway.
• Hub Peering: You connect the Hubs using Global VNet Peering.
• Full Mesh vs. Chain: Ideally, all Hubs are peered to each other (Full Mesh of Hubs) to ensure the lowest latency and avoid “bottlenecking” through a third region.

Traffic Flow

• Inter-Region Spoke-to-Spoke: To go from Spoke A (Region 1) to Spoke B (Region 2), the traffic flow is:Spoke A → Hub 1 (Firewall) → Global Peering → Hub 2 (Firewall) → Spoke B.
• Routing Logic: This requires meticulous User-Defined Routes (UDRs) on every spoke subnet to ensure traffic knows the “Next Hop” is the local Hub Firewall for remote region ranges.

2. Azure Virtual WAN (Microsoft-Managed)

Virtual WAN (vWAN) is a managed networking service that replaces the manual Hub-and-Spoke with a “plug-and-play” global transit architecture.

The Strategy

• The Virtual Hub: Microsoft manages the Hub VNet for you. You don’t manage the underlying VMs or scaling; you just toggle features (VPN, ExpressRoute, Firewall).
• Automated Peering: When you connect a Spoke VNet to a Virtual Hub, the routing is automatically propagated.
• Any-to-Any Connectivity: By default, all spokes connected to any hub in the vWAN can talk to each other globally via the Microsoft backbone.

Traffic Flow

• Simplified Path: Traffic moves from a Spoke to its local Virtual Hub, which then uses the Global Mesh (automatically maintained by Azure) to reach a Spoke in another region.
• Managed Routing: You don’t need to write dozens of UDRs. The vWAN “Hub Router” handles BGP propagation across regions automatically.

Key Differences for 2026

Important Change: Default Outbound Access (March 2026)

As of March 31, 2026, Azure has retired “default outbound access” for new VNets. In a multi-region setup, you can no longer rely on VMs simply “finding” the internet.

The Strategy Update: You must now explicitly define an egress path. In a multi-region architecture, this is typically done by routing all regional internet traffic through the local Hub’s Azure Firewall or by attaching an Azure NAT Gateway to each spoke subnet for high-performance, non-inspected traffic.

Would you like to see a sample User-Defined Route (UDR) configuration for a cross-region Hub-and-Spoke setup, or are you leaning more toward the managed Virtual WAN approach?

Since you’re interested in the “how-to,” let’s look at the User-Defined Route (UDR) configuration for a cross-region Hub-and-Spoke setup. This is the manual way to “force” traffic through your security stack.

Scenario

• Region 1 (East US): Hub VNet (10.1.0.0/16) with a Firewall at 10.1.0.4.
• Region 2 (West US): Hub VNet (10.2.0.0/16) with a Firewall at 10.2.0.4.
• Spoke A (in East US): Subnet range 10.1.10.0/24.

1. The Route Table Logic

To get Spoke A (East US) to talk to a Spoke in West US, the packet needs instructions. Without a UDR, the packet will try to go directly via Global Peering, but if you have a Firewall, it will be blocked or dropped because there is no return path.

Example UDR for Spoke A (East US)

You would create a Route Table and associate it with the subnets in Spoke A:

2. The Traffic Flow (Step-by-Step)

When a VM in Spoke A (East US) sends a packet to Spoke B (West US):

1. Source Check: The VM looks at its Route Table. It sees the 10.2.0.0/16 prefix points to 10.1.0.4 (Local Hub Firewall).
2. First Hop: Packet travels to the East US Firewall. The Firewall inspects it against your Network Rules.
3. Global Transit: The Firewall sees the destination is in West US. It sends the packet across the Global VNet Peering to the West US Hub.
4. Second Hop: The West US Firewall receives the packet, inspects it again (if desired), and forwards it to the destination VM in the West US Spoke.
5. Return Path: Symmetric routing is critical. The West US Spoke must have a mirrored UDR pointing East US traffic (10.1.0.0/16) to the West US Hub Firewall (10.2.0.4).

3. Comparison: Manual UDR vs. Virtual WAN (vWAN)

If writing these tables for 50 spokes sounds like a headache, that’s exactly why Azure Virtual WAN exists.

Pro-Tip: The “Gateway Subnet” Exception

Never associate a UDR with the GatewaySubnet in your Hub unless you are very experienced with BGP. Doing so can “break” the connection between your On-Premises VPN and your Azure VNets by creating circular routing loops.

Given the complexity of managing cross-region UDRs, are you currently leaning toward building this manually for more granular control, or does the automation of Virtual WAN sound like a better fit for your scale?

VNet Peering

Q: What is the difference between regional and global VNet peering? Are there any restrictions with global peering?

Regional VNet peering connects two VNets within the same Azure region. Global VNet peering connects VNets across different Azure regions.

Restrictions with global peering:

• Basic Load Balancer — Resources behind a Basic Load Balancer in one VNet cannot be reached from a globally peered VNet. Standard Load Balancer works fine.
• Latency — Global peering crosses region boundaries, so latency is higher than regional peering. You need to account for this in latency-sensitive workloads.
• Cost — Global peering incurs data transfer charges in both directions, whereas regional peering charges are lower.
• No transitive routing — Same as regional peering, traffic does not flow transitively through a peered VNet without additional configuration.

Q: Can peered VNets communicate transitively by default? How would you work around this?

No — transitive routing is not supported natively in VNet peering. If Spoke A is peered to the Hub, and Spoke B is peered to the Hub, Spoke A cannot reach Spoke B directly through the Hub by default.

To work around this, you have two main options:

1. Azure Firewall or NVA in the Hub — Route traffic from Spoke A through the Hub firewall, which then forwards it to Spoke B. This requires User Defined Routes (UDRs) on both Spokes pointing their traffic to the firewall’s private IP as the next hop. This is the most common enterprise approach and has the added benefit of traffic inspection.
2. Azure Virtual WAN — Virtual WAN supports transitive routing natively, making it a cleaner option when you have many Spokes and don’t want to manage UDRs manually.

Q: Spoke A and Spoke B are peered to the Hub. Can Spoke A reach Spoke B? What needs to be in place?

Not by default. To enable this:

• Deploy Azure Firewall (or an NVA) in the Hub VNet
• Create a UDR on Spoke A’s subnet with a route: destination = Spoke B’s address space, next hop = Azure Firewall private IP
• Create a mirror UDR on Spoke B’s subnet: destination = Spoke A’s address space, next hop = Azure Firewall private IP
• Configure Azure Firewall network rules to allow the traffic between Spoke A and Spoke B
• Enable “Use Remote Gateway” or “Allow Gateway Transit” on the peering connections as needed for routing to propagate correctly

This gives you transitive connectivity with centralized inspection — a core benefit of Hub-and-Spoke.

Q: When would you choose VNet peering over VPN Gateway or ExpressRoute for VNet-to-VNet connectivity?

• VNet Peering — Best for Azure-to-Azure connectivity. It uses the Microsoft backbone, offers the lowest latency, highest throughput, and is the simplest to configure. Use it whenever both VNets are in Azure.
• VPN Gateway (VNet-to-VNet) — Used when you need encrypted tunnels between VNets, or when connecting across different Azure tenants/subscriptions where peering may be complex. Higher latency and limited throughput compared to peering.
• ExpressRoute — Used for on-premises to Azure connectivity over a private, dedicated circuit. Not typically used for VNet-to-VNet unless traffic must flow through on-premises for compliance or inspection reasons.

In short: always prefer peering for Azure-to-Azure, and reserve VPN/ExpressRoute for hybrid or cross-tenant scenarios.

DNS Architecture

Q: Can you explain the difference between Azure Public DNS and Azure Private DNS Zones, and when you would use each?

Azure Public DNS is used to host publicly resolvable domain names — for example, resolving http://www.yourcompany.com from the internet. Anyone on the internet can query it.

Azure Private DNS Zones, on the other hand, are only resolvable within a VNet or linked VNets. They are used for internal name resolution — for example, resolving a private endpoint for a storage account like mystorageaccount.privatelink.blob.core.windows.net from inside your network, without exposing it publicly.

You use Public DNS when you need external-facing resolution, and Private DNS Zones when you need secure, internal name resolution for resources that should never be reachable from the internet.

Q: How does DNS resolution work for a VM inside a VNet — what is the default behavior, and when would you override it?

By default, Azure provides a built-in DNS resolver at the special IP 168.63.129.16. Every VM in a VNet uses this address automatically. It can resolve Azure-internal hostnames and any Private DNS Zones linked to that VNet.

You would override this default when:

• You need to resolve on-premises hostnames from Azure (hybrid scenarios)
• You need conditional forwarding to route specific domain queries to specific DNS servers
• You are using a centralized custom DNS server (e.g., a DNS forwarder VM or Azure DNS Private Resolver) to control and log all DNS traffic across the environment

In those cases, you configure a custom DNS server address at the VNet level, pointing VMs to your centralized resolver instead.

Q: What is conditional forwarding, and how would you set it up to resolve on-premises domain names from Azure?

Conditional forwarding is a DNS rule that says: “For queries matching this specific domain, forward them to this specific DNS server instead of resolving them normally.”

For example, if your on-premises domain is corp.contoso.local, you would configure your Azure DNS resolver to forward any query for corp.contoso.local to your on-premises DNS server IP.

The setup typically looks like this:

• Deploy Azure DNS Private Resolver with an outbound endpoint in your Hub VNet
• Create a DNS forwarding ruleset with a rule: corp.contoso.local → forward to on-premises DNS IP
• Associate the ruleset with the relevant VNets
• Ensure the on-premises DNS server can be reached over ExpressRoute or VPN

Q: A client reports that their Azure VM cannot resolve a private endpoint hostname. What are the first things you check?

I would systematically check the following:

1. Private DNS Zone linkage — Is the Private DNS Zone (e.g., privatelink.blob.core.windows.net) linked to the VNet the VM is in? Without the link, the zone is invisible to that VNet.
2. A record presence — Does the Private DNS Zone actually contain an A record pointing to the private endpoint’s IP?
3. Custom DNS configuration — If the VNet uses a custom DNS server, is that server forwarding queries for privatelink.* domains to Azure’s resolver (168.63.129.16)? This is a very common misconfiguration.
4. nslookup / dig from the VM — Run nslookup <hostname> on the VM to see what IP is being returned. If it returns the public IP instead of the private IP, the DNS zone is not being picked up correctly.
5. Network connectivity — Even if DNS resolves correctly, confirm NSG rules and routing aren’t blocking traffic to the private endpoint IP.

Q: How would you use Azure DNS Private Resolver, and how does it differ from a traditional DNS forwarder running on a VM?

Azure DNS Private Resolver is a fully managed, highly available DNS service that handles inbound and outbound DNS resolution without requiring you to manage VMs.

• The inbound endpoint allows on-premises clients to send DNS queries into Azure and resolve Private DNS Zones — something that wasn’t possible before without a forwarder VM.
• The outbound endpoint with forwarding rulesets allows Azure VMs to forward specific domain queries (e.g., on-premises domains) to external DNS servers.

Compared to a forwarder VM, DNS Private Resolver is:

• Fully managed — no patching, no VM maintenance, no availability concerns
• Scalable — handles high query volumes automatically
• Integrated — natively understands Azure Private DNS Zones without extra configuration
• More secure — no need to open management ports on a VM

The main reason teams still use forwarder VMs is legacy architecture or specific advanced configurations not yet supported by Private Resolver.

🔵 VNet Peering

Q: What is the difference between regional and global VNet peering? Are there any restrictions with global peering?

Regional VNet peering connects two VNets within the same Azure region. Global VNet peering connects VNets across different Azure regions.

Restrictions with global peering:

• Basic Load Balancer — Resources behind a Basic Load Balancer in one VNet cannot be reached from a globally peered VNet. Standard Load Balancer works fine.
• Latency — Global peering crosses region boundaries, so latency is higher than regional peering. You need to account for this in latency-sensitive workloads.
• Cost — Global peering incurs data transfer charges in both directions, whereas regional peering charges are lower.
• No transitive routing — Same as regional peering, traffic does not flow transitively through a peered VNet without additional configuration.

Q: Can peered VNets communicate transitively by default? How would you work around this?

No — transitive routing is not supported natively in VNet peering. If Spoke A is peered to the Hub, and Spoke B is peered to the Hub, Spoke A cannot reach Spoke B directly through the Hub by default.

To work around this, you have two main options:

1. Azure Firewall or NVA in the Hub — Route traffic from Spoke A through the Hub firewall, which then forwards it to Spoke B. This requires User Defined Routes (UDRs) on both Spokes pointing their traffic to the firewall’s private IP as the next hop. This is the most common enterprise approach and has the added benefit of traffic inspection.
2. Azure Virtual WAN — Virtual WAN supports transitive routing natively, making it a cleaner option when you have many Spokes and don’t want to manage UDRs manually.

Q: Spoke A and Spoke B are peered to the Hub. Can Spoke A reach Spoke B? What needs to be in place?

Not by default. To enable this:

• Deploy Azure Firewall (or an NVA) in the Hub VNet
• Create a UDR on Spoke A’s subnet with a route: destination = Spoke B’s address space, next hop = Azure Firewall private IP
• Create a mirror UDR on Spoke B’s subnet: destination = Spoke A’s address space, next hop = Azure Firewall private IP
• Configure Azure Firewall network rules to allow the traffic between Spoke A and Spoke B
• Enable “Use Remote Gateway” or “Allow Gateway Transit” on the peering connections as needed for routing to propagate correctly

This gives you transitive connectivity with centralized inspection — a core benefit of Hub-and-Spoke.

Q: When would you choose VNet peering over VPN Gateway or ExpressRoute for VNet-to-VNet connectivity?

• VNet Peering — Best for Azure-to-Azure connectivity. It uses the Microsoft backbone, offers the lowest latency, highest throughput, and is the simplest to configure. Use it whenever both VNets are in Azure.
• VPN Gateway (VNet-to-VNet) — Used when you need encrypted tunnels between VNets, or when connecting across different Azure tenants/subscriptions where peering may be complex. Higher latency and limited throughput compared to peering.
• ExpressRoute — Used for on-premises to Azure connectivity over a private, dedicated circuit. Not typically used for VNet-to-VNet unless traffic must flow through on-premises for compliance or inspection reasons.

In short: always prefer peering for Azure-to-Azure, and reserve VPN/ExpressRoute for hybrid or cross-tenant scenarios.

🔵 Hub-and-Spoke Network Design

Q: Explain the Hub-and-Spoke topology. What lives in the Hub, and what lives in the Spokes?

Hub-and-Spoke is a network design pattern where a central VNet (the Hub) acts as the connectivity and security backbone, and multiple Spoke VNets connect to it via peering.

The Hub hosts shared, centralized services:

• Azure Firewall or NVA for traffic inspection and internet egress control
• VPN Gateway or ExpressRoute Gateway for on-premises connectivity
• Azure DNS Private Resolver
• Bastion for secure VM access
• Shared monitoring and logging infrastructure

The Spokes host workload-specific resources:

• Application VMs, AKS clusters, App Services
• Databases and storage
• Each Spoke is isolated — it can only communicate outside its boundary through the Hub, which enforces security policies

This model gives you centralized governance and security without duplicating shared services in every workload environment.

Q: How do you enforce traffic inspection through the Hub for Spoke-to-internet traffic?

• Deploy Azure Firewall in the Hub VNet
• On each Spoke subnet, create a UDR with a default route: 0.0.0.0/0 → next hop = Azure Firewall private IP
• This forces all outbound internet traffic from Spoke VMs through the firewall before it exits
• On the Hub, configure Azure Firewall application and network rules to define what traffic is allowed out
• Enable Azure Firewall DNS proxy if you want centralized DNS logging as well

For Spoke-to-Spoke, additional UDRs point inter-spoke traffic to the firewall as described earlier.

Q: A new business unit needs to be onboarded into your existing Hub-and-Spoke architecture. Walk me through the steps.

1. IP planning — Allocate a non-overlapping address space for the new Spoke VNet from the enterprise IP plan
2. Create the Spoke VNet — Deploy it in the appropriate subscription under the correct Management Group
3. Establish peering — Create bidirectional peering between the new Spoke and the Hub (allow gateway transit on Hub side, use remote gateway on Spoke side if needed)
4. Configure UDRs — Apply route tables on the Spoke subnets to direct internet and cross-spoke traffic through the Hub firewall
5. DNS configuration — Point the Spoke VNet’s DNS settings to the centralized DNS Private Resolver in the Hub
6. Firewall rules — Add rules in Azure Firewall to permit the business unit’s required traffic flows
7. Azure Policy — Ensure the new subscription inherits enterprise policies (e.g., no public IPs, required tags, allowed regions)
8. Private DNS Zone links — Link relevant Private DNS Zones to the new Spoke VNet for private endpoint resolution
9. Connectivity testing — Validate DNS resolution, internet egress, and any required on-premises connectivity

🔵 Landing Zones & Enterprise Network Governance

Q: What is an Azure Landing Zone, and how does networking fit into it?

An Azure Landing Zone is a pre-configured, governed Azure environment that provides the foundation for hosting workloads securely and at scale. It is designed following Microsoft’s Cloud Adoption Framework (CAF) and covers identity, governance, security, networking, and management.

Networking is one of the most critical components. In the CAF Landing Zone model:

• A Connectivity subscription hosts the Hub VNet, gateways, firewall, and DNS infrastructure
• Landing Zone subscriptions host Spoke VNets for individual workloads or business units
• All networking is governed centrally — workload teams cannot create arbitrary public IPs or peer VNets outside the approved architecture
• Azure Policy enforces these constraints automatically

Q: What role do Azure Policy and Management Groups play in enforcing network governance?

Management Groups create a hierarchy of subscriptions (e.g., Root → Platform → Landing Zones → Business Units). Policies applied at a Management Group level automatically inherit down to all subscriptions beneath it.

Azure Policy enforces guardrails such as:

• Deny creation of public IP addresses in Spoke subscriptions
• Require all VNets to use a specific custom DNS server
• Deny VNet peering unless it connects to the approved Hub
• Enforce NSG association on every subnet
• Require private endpoints for PaaS services like Storage and SQL

Together, they ensure that even if a workload team has Contributor access to their subscription, they cannot violate the network architecture — the policies block non-compliant actions automatically.

Q: How would you manage IP address space allocation across multiple subscriptions to avoid conflicts?

This is an area where discipline and tooling are both essential:

• Centralized IP plan — Maintain a master IP address management (IPAM) document or tool (e.g., Azure’s native IPAM feature in preview, or third-party tools like Infoblox or NetBox) that tracks all allocated ranges across subscriptions
• Non-overlapping ranges per Spoke — Assign each Landing Zone a dedicated, non-overlapping CIDR block from a master supernet (e.g., 10.0.0.0/8 split into /16 per region, then /24 per Spoke)
• Azure Policy — Use policy to deny VNet creation if the address space conflicts with known ranges or falls outside the approved supernet
• Automation — When onboarding new Landing Zones via Pulumi or other IaC, automatically pull the next available range from the IPAM system rather than relying on manual assignment

🔵 Hybrid DNS Resolution

Q: On-premises clients need to resolve privatelink.blob.core.windows.net. What DNS architecture changes are needed?

This is one of the most common hybrid DNS challenges. By default, privatelink.blob.core.windows.net resolves to a public IP from on-premises. To make it resolve to the private endpoint IP, you need:

On the Azure side:

• Create a Private DNS Zone for privatelink.blob.core.windows.net and link it to the Hub VNet
• Ensure the private endpoint A record is registered in the zone
• Deploy Azure DNS Private Resolver with an inbound endpoint in the Hub VNet — this gives on-premises clients a routable IP to send DNS queries into Azure

On the on-premises side:

• Configure your on-premises DNS server with a conditional forwarder: privatelink.blob.core.windows.net → forward to the DNS Private Resolver inbound endpoint IP
• Ensure the inbound endpoint IP is reachable over ExpressRoute or VPN from on-premises

Result: On-premises clients query their local DNS → conditional forwarder redirects to Azure DNS Private Resolver → Private Resolver checks the linked Private DNS Zone → returns the private endpoint IP → traffic flows privately over ExpressRoute/VPN.

Q: You’re migrating from a custom DNS forwarder VM to Azure DNS Private Resolver. How do you ensure zero DNS disruption?

1. Deploy Private Resolver in parallel — Set up the inbound and outbound endpoints and configure forwarding rulesets to mirror the existing forwarder VM’s rules exactly
2. Test thoroughly — Validate resolution of all key domains (on-premises, private endpoints, public) from test VMs pointing to the new resolver
3. Staged migration — Update the custom DNS server setting on VNets one at a time, starting with non-production VNets, monitoring for any resolution failures
4. Update on-premises conditional forwarders — Once Azure-side is validated, update on-premises DNS to point to the Private Resolver inbound endpoint instead of the old forwarder VM IP
5. Monitor — Use Azure Monitor and DNS metrics on the Private Resolver to confirm query volumes are healthy
6. Decommission the VM — Only after all VNets and on-premises forwarders are updated and validated, remove the forwarder VM

The key principle is run both in parallel, migrate gradually, and never cut over until validation is complete.