Implement and manage virtual networking

Creating a public DNS zone in Azure does not automatically make it resolvable from the internet. For internet clients to resolve names in the zone, you must update the NS (Name Server) records at your domain registrar to point to the four Azure name servers assigned to the zone. Once the registrar delegates authority to Azure's name servers, external DNS resolvers will follow that delegation. Modifying the SOA record at the registrar, or creating additional NS records inside the Azure zone itself, does not accomplish this delegation.

• A private DNS zone must be linked to a VNet before any VM in that VNet can resolve records in the zone.
• A VNet link can optionally enable auto-registration, which causes Azure to automatically create DNS A records for VMs in that VNet when they start.
• Auto-registration only registers the VM's private IP address — never its public IP. A VM without a private IP (no NIC connected to the VNet) will not be auto-registered.
• A VNet can be linked to up to 1,000 private DNS zones; a single private DNS zone can be linked to up to 1,000 VNets.

• Records are created when a VM starts (and its NIC is assigned a private IP). Records are removed when the VM is deleted.
• Only the VM's private IP address is registered — never the public IP, even if the VM has one.
• For auto-registration to work, the VNet must be linked to the private zone and the link must have auto-registration enabled.
• A VM connected to a VNet that is not linked to the private zone will not have its record auto-registered, even if the zone exists in the same subscription.
• A VM in a VNet that is linked to the zone but with auto-registration disabled can still resolve records from the zone — it just does not get its own record created automatically.

1. NIC-level custom DNS — if a specific DNS server IP is configured directly on the network interface, that VM uses only that DNS server, regardless of the VNet's settings.
2. VNet-level custom DNS — if no NIC-level DNS is set, the VM uses whichever custom DNS servers are configured on the VNet.
3. Azure-provided DNS (168.63.129.16) — used only when neither the NIC nor the VNet has a custom DNS server configured. Azure-provided DNS is what queries private DNS zones.

If a DNS server VM (e.g. VM1 on VNET1) needs to serve DNS to VMs in VNET2 and VNET3, those VNets must be able to reach VM1 over the network. The correct solution is to configure peering between the VNets so that VNET2 and VNET3 can communicate with VM1. Simply adding service endpoints does not establish connectivity between VNets. After peering is in place, setting the DNS server IP on VNET2 and VNET3 to VM1's private IP completes the configuration.

Before peering two VNets, their address spaces must be entirely non-overlapping. The overlap check is performed against the VNet's declared address space, not just the subnets currently in use. If VNet1 has address space 10.11.0.0/16 and VNet2 has 10.11.0.0/17, VNet2's address space is a subset of VNet1's — they overlap and cannot be peered. To resolve this, the address space of one VNet must be modified first. Simply deleting subnets or adding gateway subnets does not resolve an address space conflict.

A Disconnected peering means the peering object exists on this VNet, but the matching reciprocal peering on the remote VNet has not been created or has since been deleted. Azure requires both sides to acknowledge the peering before traffic can flow. A Disconnected peering is purely a configuration gap — the fix is to go to the peer VNet and add the corresponding peering back to this VNet.

• If the desired range (e.g. 192.168.1.0/24) falls completely outside the VNet's declared address space, the address space must be added to the VNet first. Only then can a subnet be created within that range.
• If the desired range falls within the VNet's address space but no subnet covers it, a new subnet must be created within that range.
• Adding a network interface alone does not provision an IP range — NICs are assigned to existing subnets.

Usable hosts = 2^{(32 − prefix length)} − 5

• Destination (address prefix) — the CIDR range of the traffic you want to intercept. To route all traffic from a VPN gateway to VNet resources through an NVA, set the prefix to the VNet's address space (e.g. 10.0.0.0/16).
• Next hop type — set to Virtual appliance. This is the only next hop type that requires an explicit next hop IP address.
• Next hop IP address — the private IP of the NVA. Other next hop types (Internet, VirtualNetwork, VirtualNetworkGateway, None) do not require an explicit IP — they route to system-managed endpoints.

A route table can only be associated with subnets. You cannot associate a route table directly with a VNet or with a NIC. When a route table is associated with a subnet, its custom routes apply to all resources connected to that subnet. To route inbound VPN gateway traffic through an NVA, the route table must be associated with the GatewaySubnet — this causes traffic arriving at the VPN gateway to be redirected to the NVA before entering other subnets.

• On VNet A (the VNet that owns the VPN gateway): enable Allow gateway transit on the peering configuration pointing to VNet B.
• On VNet B (the VNet without its own gateway): enable Use remote gateways on the peering configuration pointing to VNet A.
• Once both settings are configured, on-premises traffic can reach VNet B by traversing VNet A's VPN gateway without requiring a separate gateway in VNet B.

1. Create a GatewaySubnet in the VNet — the VPN gateway requires a dedicated subnet named exactly GatewaySubnet. It cannot share a subnet with any other resource.
2. Deploy a Virtual Network Gateway — choose type VPN, and select a SKU appropriate for the expected load. The gateway is deployed into the GatewaySubnet.
3. Configure the address pool — specify the client IP address pool from which P2S clients will be assigned IPs when they connect. This pool must not overlap with the VNet's address space.
4. Configure the authentication method (certificate-based, Azure AD, or RADIUS) and distribute the VPN client configuration to users.

• Each VNet must have a subnet named exactly GatewaySubnet. Azure will not allow a Virtual Network Gateway to be deployed without it.
• A Virtual Network Gateway (type: VPN) must be deployed into the GatewaySubnet.
• A Local Network Gateway must be created to represent the on-premises VPN device, specifying its public IP address and the on-premises address prefixes.
• A Connection object links the VPN gateway to the local network gateway using a shared key.

• Network Interface (NIC) — a public IP is associated with a NIC, not with the VM directly. The VM gets its public IP via the NIC.
• Load Balancer (frontend IP configuration) — public-facing load balancers use a public IP as their frontend.
• VPN Gateway — requires a public IP to establish VPN tunnels with the internet or on-premises devices.
• Application Gateway — can have a public IP for internet-facing ingress.
• Azure Firewall — requires a public IP for internet-bound traffic.
• Azure Bastion — requires a Standard SKU public IP.
• NAT Gateway — uses a public IP for outbound SNAT.

• AzureCloud — all Azure datacenter IP ranges globally. Blocking this prevents access to all Azure services.
• AzurePortal — IP ranges used by the Azure portal (portal.azure.com). Use this tag to specifically block or allow portal access without affecting other internet or Azure traffic.
• AzureKeyVault — IPs for Azure Key Vault. Used when you want to allow VMs to reach Key Vault specifically.
• Internet — all IP addresses outside the VNet and outside Azure's known ranges (the public internet).
• VirtualNetwork — the VNet's own address space plus all peered VNet address spaces and on-premises ranges connected via VPN or ExpressRoute.
• AzureLoadBalancer — the health probe source IP used by Azure Load Balancers (168.63.129.16).

• AllowVnetInBound (priority 65000) — allows all inbound traffic from the VirtualNetwork service tag to the VirtualNetwork service tag. This covers same-VNet communication and peered VNet communication.
• AllowAzureLoadBalancerInBound (priority 65001) — allows health probe traffic from the Azure Load Balancer.
• DenyAllInBound (priority 65500) — denies all other inbound traffic, including inbound from the internet. This is why a VM without a custom allow rule for port 3389 cannot be reached via RDP from the internet.

• AllowVnetOutBound (priority 65000) — allows all outbound traffic to the VirtualNetwork service tag.
• AllowInternetOutBound (priority 65001) — allows all outbound traffic to the internet. This is why VMs can reach the internet by default without any custom outbound rules.
• DenyAllOutBound (priority 65500) — denies everything else not matched above.

• An NSG can be associated with subnets and NICs in any VNet in the same region, regardless of whether those VNets or NICs are in the same resource group or subscription as the NSG.
• An NSG in East US cannot be applied to a subnet in a West US VNet, even if both are in the same resource group.
• An NSG can be applied to multiple subnets and multiple NICs simultaneously, all within the same region.

• A custom policy definition with a deployIfNotExists or append effect can be used to ensure all NSGs contain a specific security rule.
• The policy is assigned at the subscription or resource group scope, so it applies to all NSGs created anywhere within that scope.
• Built-in policy definitions for NSGs may not cover highly specific rule requirements — a custom definition is typically needed for precise port-blocking scenarios.

When web server VMs need to distribute requests equally across business logic VMs — where the communication is entirely private within a VNet — an Internal Load Balancer is the correct choice. It operates at Layer 4, does not require a public IP, and is accessible only from within the VNet or connected networks. An Application Gateway WAF is for protecting internet-facing HTTP/S ingress from external threats — not for private internal traffic distribution.

For a VM to be added to a Standard LB backend pool, the VM must have either no public IP address, or a Standard SKU public IP address. A VM with a Basic SKU public IP address cannot be added to a Standard LB backend pool. This rule applies regardless of whether the LB is public or internal.

1. Standard Load Balancer — HA Ports and Floating IP are Standard-only features; Standard is required.
2. Frontend IP configuration, backend pool, and health probe — the backend pool contains both NVAs; the health probe monitors NVA health and enables automatic failover if one NVA becomes unhealthy.
3. HA Ports load balancing rule with Floating IP enabled — HA Ports routes all protocols and ports in a single rule. Floating IP causes the destination IP in packets to remain unchanged (the packet arrives at the NVA still addressed to the LB's frontend IP), allowing the NVA to perform its forwarding decision based on the original destination.

The WAF tier enforces OWASP Core Rule Set rules, detecting and blocking attacks including SQL injection, cross-site scripting, command injection, and HTTP protocol violations. When the requirement is to protect web servers from SQL injection attacks, the correct answer is Application Gateway with the WAF tier. An Internal Load Balancer performs Layer 4 TCP/UDP load balancing and cannot inspect application-layer content. An NSG can filter by IP, port, and protocol — but cannot parse HTTP payloads to detect injection attacks.

• A dedicated subnet named exactly AzureBastionSubnet is required in the VNet. The minimum size is /26 — Azure will not allow a smaller subnet.
• A Standard SKU, Static, IPv4 public IP address must be associated with the Bastion resource. Basic SKU and IPv6 IPs are not supported.
• An NSG inbound rule must allow port 443 from the internet — this is the port users use to reach Bastion from their browsers.

• Same VNet as Bastion — always reachable (both Basic and Standard SKU).
• Directly peered VNets — reachable with Standard SKU only. The VNet must have a direct peering link to the Bastion's VNet.
• Transitively peered VNets — not reachable by either SKU. If Bastion is in VNet1, VNet1 is peered with VNet2, and VNet2 is peered with VNet3 — Bastion cannot reach VMs in VNet3 because VNet peering is non-transitive.

Azure Firewall can be deployed into any VNet in the same Azure region, regardless of which resource group the firewall or the VNet belongs to. A firewall being created in West US can be placed in any VNet that is also in West US — whether that VNet is in RG1, RG2, or any other resource group. It cannot be placed in a VNet in Central US even if that VNet and the firewall share the same resource group.

• NSG Flow Logs must be enabled on each NSG — flow logs record which traffic was allowed or denied by the NSG. Traffic Analytics has no data to analyse without flow logs.
• A Log Analytics workspace must be configured as the destination for the processed flow log data. Traffic Analytics queries and stores its aggregated data in Log Analytics.
• A storage account is used as an intermediate landing zone where raw flow log data is initially written before being processed into Log Analytics.

To use Traffic Analytics in Azure Network Watcher to monitor VM traffic, two resources must exist: a storage account (to receive the raw NSG flow log files) and a Log Analytics workspace (to receive the processed traffic data for querying and alerting). Microsoft Sentinel, Data Collection Rules, and Azure Monitor workbooks are not prerequisites for Traffic Analytics itself.

• Displaying a visual topology of network resources and their connectivity relationships.
• Showing aggregate health and metrics across multiple networking resources simultaneously.
• Surfacing configuration issues and alerts detected by Azure across monitored resources.
• Viewing metrics for ExpressRoute circuits, VPN gateways, load balancers, and VNets in one place — particularly useful for hybrid environments where multiple ExpressRoute circuits connect to multiple on-premises datacenters.

A service endpoint on a subnet creates a direct, high-priority route to the specified Azure service (e.g. Microsoft.Storage) over the Azure backbone. This route takes precedence over the forced tunnelling default route. Traffic from a VM to the storage account then flows: VM → Azure backbone → storage account — never leaving Azure's network and never passing through the VPN gateway or on-premises. The storage account's firewall can also be configured to only accept traffic from subnets with a service endpoint, preventing all other access.

• Regional constraint — a service endpoint policy must be created in the same region as the subnet it will be applied to. A policy in South Central US can only be applied to subnets in VNets located in South Central US.
• Service endpoint required first — a subnet must already have the Microsoft.Storage service endpoint enabled before a storage service endpoint policy can be applied to it.
• Without a policy — subnets with a Microsoft.Storage service endpoint can reach all storage accounts in Azure, regardless of region.
• With a policy scoped to "all accounts in the subscription" — all three storage accounts in that subscription are accessible. This is permissive, not restrictive to one specific account.

To create a NIC and attach it to a VNet, the NIC must be created in the same Azure region as the VNet. If VNet1 is in East US, a NIC connecting to VNet1 must also be created in East US — regardless of where other resources like VMs, storage accounts, or resource groups are located. This constraint exists because NICs are bound to subnets, and subnets are parts of VNets which are regional.

• The VM resource itself — the virtual machine definition, configuration, and metadata.
• The OS disk (managed disk) — the VM cannot boot without its OS disk in the same subscription.
• The Network Interface (NIC) — the NIC is directly attached to the VM and must travel with it. It can be reconnected to a VNet in the target subscription after the move.

VNet Integration is configured on the web app itself (under Settings → Networking → VNet Integration). Once connected, the web app can make outbound calls to resources within the VNet and any peered VNets or connected on-premises networks. Importantly, VNet Integration is outbound only — it allows the web app to initiate connections to VNet resources, but it does not expose the web app as a resource accessible from inside the VNet the way a private endpoint would.

If the requirement is that all virtual machines communicate with Azure Monitor only through the VNet — using private IPs and the Azure backbone rather than the public internet — the correct resource to create is an Azure Monitor Private Link Scope. AMPLS creates private endpoints for Azure Monitor, Log Analytics, and Application Insights, allowing monitoring agents on VMs to send data without any public internet exposure.

• Records the actual packets transmitted through a VM's NIC during a specified time window (e.g. 3 hours).
• Output is a .pcap file that can be opened in Wireshark or similar tools for deep inspection.
• Used when you need to see what data is flowing — payload contents, protocol details, or conversation traces between specific hosts.
• This is the correct tool for "inspect all network traffic from VM1 to VM2 for a period of three hours."

• Continuously tests whether a source endpoint (VM or on-premises host) can reach a destination endpoint (IP, FQDN, or port).
• Reports latency, packet loss, and reachability over time — useful for detecting intermittent connectivity failures.
• A single Connection Monitor can cover multiple source-destination pairs across multiple VNets, regions, and on-premises networks simultaneously.
• This is the correct tool for "monitor connectivity between VMs and the on-premises network" — not for inspecting packet contents.

When a user needs to both deploy virtual machines and manage virtual networks, the least-privilege role is Contributor. The Virtual Machine Contributor role only covers VM management and cannot manage VNets. The Network Contributor role covers VNets but not VM deployment. Only Contributor (or a custom role combining both) covers both workloads. Owner is broader still because it also includes role assignment capability.

Adding a backend pool to a load balancer is a network resource operation. The least-privilege role for this task is Network Contributor on the load balancer resource — scoped directly to LB1, not to the entire resource group. Network Contributor at the resource group scope would grant the user access to all network resources in the group, which is broader than necessary if only LB1 needs management.