Chapter 4

Implement and Manage Virtual Networking

Microsoft Azure Administrator (AZ-104) Study GuideBased on the Microsoft AZ-104 exam objectives

Virtual networking is the foundation everything else in Azure runs on. Virtual machines, app services, databases, and hybrid connections all depend on correctly designed address spaces, subnets, and security rules. This chapter covers the 15–20% of the AZ-104 exam devoted to virtual networks, peering, IP addressing, network security groups, DNS, load balancing, troubleshooting with Network Watcher, hybrid connectivity, and Azure Bastion.

Virtual Networks and Subnets

A virtual network (VNet) is your private, isolated network in Azure — the cloud equivalent of the LAN you would build in an on-premises datacenter, minus the physical switches. Every VNet has one or more address ranges in CIDR notation, and those ranges are divided into subnets that host your resources. Two rules govern the whole design: address ranges must come from private or public space you control, and subnets are carved only from the VNet's own ranges.

When you create a VNet you assign at least one address space, such as 10.0.0.0/16. You can add more address ranges later (for example, 10.1.0.0/16) as long as the new range does not overlap any existing range on that VNet. You can also remove an address range — but only if no subnet is allocated from it. A common exam trap: you cannot change the prefix length of an existing range in place. If 10.0.0.0/16 is too small, you add a new range; you do not "stretch" the old one.

Subnets divide the address space into segments. A subnet like 10.0.1.0/24 gives you 256 addresses in theory, but Azure reserves five addresses in every subnet, regardless of size:

• The network address (for example, 10.0.1.0)
• 10.0.1.1 — used by Azure as the default gateway
• 10.0.1.2 and 10.0.1.3 — mapped by Azure to its DNS service
• The last address in the range (for example, 10.0.1.255) — the broadcast address

So the usable count is always 2^n − 5, where n is the number of host bits. A /24 yields 256 − 5 = 251 usable addresses. A /26 yields 64 − 5 = 59. The smallest subnet Azure allows is /29, which gives 8 − 5 = 3 usable addresses — enough for a gateway subnet in a pinch, but not recommended.

Subnets have one more property the exam loves: delegation. Subnet delegation grants a specific Azure PaaS service exclusive rights to a subnet — for example, delegating a subnet to Microsoft.Web/serverFarms for App Service VNet integration, or to Microsoft.ContainerInstance/containerGroups for container groups. Once delegated, only that service's resources can live in the subnet, and some policies (like NSGs, depending on the service) may be restricted. You cannot delete a subnet that still has delegated resources in it.

Special subnets carry naming rules. A gateway subnet must be named exactly GatewaySubnet — Azure looks for that name when deploying a VPN or ExpressRoute gateway. Similarly, the Azure Bastion subnet must be named exactly AzureBastionSubnet and be at least a /26. If you name it Bastion-Subnet, deployment fails even if the size is right.

Subnets span availability zones automatically. A subnet is a regional construct — you do not create one subnet per zone. Zone-aware resources (like zonal VMs) are placed into the same subnet, and the zone is a property of the resource, not the subnet. There is no "zone redundancy" toggle on a subnet.

Worked Scenario: Subnet Sizing

Your team needs a single subnet to host 500 virtual machines, and the design must account for Azure's reserved addresses. What is the smallest subnet prefix you can use?

Step 1: Add the reserved addresses to the requirement. 500 hosts + 5 reserved = 505 addresses needed.

Step 2: Find the smallest power of two that fits 505. 2^8 = 256 (too small). 2^9 = 512 (fits).

Step 3: Convert to prefix length. A subnet with 9 host bits is a /23 (32 − 9 = 23).

Answer: 10.x.x.x/23 — the smallest prefix that provides at least 505 addresses. A /24 (256 addresses) is far too small, and a /22 (1,024 addresses) works but wastes space. On the exam, always add the 5 reserved addresses first, then round up to the next power of two.

For gateway subnets, Microsoft recommends /27 or larger. The absolute minimum is /29, but it leaves no room for gateway SKU changes — always pick /27 or larger on exam questions asking for the recommended size.

VNet Peering

VNet peering connects two virtual networks so resources in each can communicate as if they were on the same network, using private IP addresses and the Azure backbone — no VPN gateway, no public internet. Peering works between VNets in the same region or different regions (global peering), in the same subscription or different subscriptions, and even across Microsoft Entra tenants.

The single hard requirement: the address spaces must not overlap. If VNet-A is 10.0.0.0/16 and VNet-B is 10.0.0.0/24, peering creation fails outright — not a connectivity problem to troubleshoot later, but a hard block at creation time. Different prefix lengths are fine; overlap is not.

Peering is non-transitive by default. If VNet-A peers with VNet-B, and VNet-B peers with VNet-C, A and C cannot talk to each other unless you also peer A with C directly. The exam frequently tests this with hub-and-spoke designs: the hub peers with each spoke, but spokes cannot reach each other without additional peering or routing through the hub.

Two optional peering settings change routing behavior:

• Allow gateway transit: lets a peered VNet use the other VNet's VPN or ExpressRoute gateway. In a hub-and-spoke design, you enable gateway transit on the hub-to-spoke peering so spokes reach on-premises through the hub's gateway — without deploying a gateway in every spoke.
• Use remote gateways: the mirror setting, enabled on the spoke side, telling the spoke to use the hub's gateway.

Both must be configured correctly for the pair to work: one side allows transit, the other side uses the remote gateway. A classic exam question shows on-premises connectivity working from the hub but failing from a spoke — the answer is almost always the missing "use remote gateways" setting on the spoke peering.

Troubleshooting peering follows a short checklist. First, confirm the peering status shows Connected on both sides — peering is configured per direction, and a peering created on only one side shows Initiated, not Connected. Second, check for overlapping address spaces (creation would have failed, so this is rare). Third, look at NSGs on the subnets and any firewalls on the VMs themselves — peering provides the path, but NSG rules can still block traffic. Fourth, verify effective routes: a user-defined route forcing traffic to a firewall appliance (NVA) can break peering paths if the appliance is misconfigured.

IP Addressing

Every Azure resource that talks on a network has an IP address, and AZ-104 expects you to know the SKUs and behaviors cold.

Public IP Addresses

Public IPs come in two SKUs with sharply different capabilities:

The practical rule: Standard is the modern default and is required whenever you use a Standard Load Balancer, NAT gateway, or zone-redundant design. Basic public IPs are a legacy option — cheaper, but without zone redundancy and with dynamic assignment by default, meaning the address can change when the resource is stopped and deallocated.

A public IP can be associated with a VM's network interface, a load balancer frontend, a NAT gateway, a VPN gateway, or an application gateway, among others. You can also bring your own public IP prefixes (BYOIP) if your organization needs to keep its address reputation.

Private IP Addresses

Private IPs are assigned from the subnet's address range. By default they are dynamic — Azure assigns the next available address and it can change if the VM is stopped and deallocated. You can set a private IP to static, which reserves that specific address for the resource's lifetime. Static private IPs are standard practice for domain controllers, DNS servers, and firewall appliances where other systems depend on a fixed address.

NAT Gateway

Azure NAT gateway provides outbound-only internet connectivity for subnets. Before NAT gateway existed, VMs without public IPs relied on the load balancer's default outbound SNAT, which had unpredictable ports and timeouts. NAT gateway replaces that with a dedicated, fully managed outbound path using static public IPs (or a public IP prefix) that you control — so destination firewalls can allowlist a known address.

Key facts: a NAT gateway is associated with one or more subnets, supports up to 16 public IP addresses for massive SNAT port scale, and has a configurable idle timeout up to 120 minutes. It does not allow inbound connections — it is purely for outbound traffic. A subnet can have both a NAT gateway (outbound) and a load balancer (inbound); they complement each other.

Network Security Groups

A network security group (NSG) is a stateful packet filter that controls traffic to Azure resources. You associate an NSG with a subnet, a network interface (NIC), or both. When both are associated, both sets of rules apply — traffic must pass the subnet NSG and the NIC NSG.

Rule Processing

NSG rules are evaluated by priority number, from lowest to highest, and processing stops at the first match. Priorities run from 100 to 4096. This ordering is everything: a broad "deny all" at priority 4000 never fires if an "allow" at priority 200 matches first. The exam's favorite NSG question gives you three rules and asks which one applies to a packet — always walk the priorities from lowest to highest and stop at the first match.

Each rule specifies a source, destination, port, and protocol. Protocol choices are TCP, UDP, ICMP, ESP, AH, or Any — and yes, ICMP is a real, selectable option, so a rule allowing ping uses protocol ICMP, not "Any."

Every NSG ships with default rules you cannot delete (priorities 65000–65500):

Inbound defaults:

• 65000 — AllowVNetInBound: allows all traffic within the VNet
• 65001 — AllowAzureLoadBalancerInBound: allows Azure's load balancer health probes
• 65500 — DenyAllInBound: blocks everything else

Outbound defaults:

• 65000 — AllowVnetOutBound
• 65001 — AllowInternetOutBound
• 65500 — DenyAllOutBound

Because the defaults allow VNet-to-VNet and outbound internet traffic, a brand-new NSG is permissive inside the VNet. The exam often asks what happens "by default" — remember that intra-VNet traffic is allowed unless you add a deny rule with a priority lower than 65000.

Service Tags and Application Security Groups

Service tags are named groups of IP address prefixes managed by Microsoft — VirtualNetwork, Internet, AzureLoadBalancer, Storage, Sql, and regional variants like Storage.WestEurope. Instead of hardcoding Microsoft's ever-changing IP ranges into NSG rules, you reference the tag and Azure keeps it current. A rule allowing Storage as the destination automatically tracks the right prefixes.

Application security groups (ASGs) let you group NICs by workload role — for example, all web-server NICs in ASG-Web and all database NICs in ASG-DB — and then write a single NSG rule: allow ASG-Web to ASG-DB on port 1433. When you add a new database VM, you just drop its NIC into ASG-DB; no NSG edits needed. Constraints: all NICs in an ASG must belong to the same VNet, and an ASG is referenced only in NSG rules, never attached to a subnet directly.

Effective Security Rules

When troubleshooting, the portal's "effective security rules" view shows the merged result of the subnet NSG and the NIC NSG for a given VM. This is the fastest way to answer "why is traffic blocked?" — it lists every rule from both NSGs in priority order with the final allow/deny outcome. If the effective rules look correct but traffic still fails, check the guest OS firewall on the VM itself and any user-defined routes redirecting traffic.

Worked Scenario: The Blocked Web Server

A VM in subnet Web-Subnet (10.0.1.0/24) runs a website on port 443. Users report the site is unreachable from the internet. The subnet NSG has: priority 200, allow HTTPS from Internet; priority 300, deny all inbound from Internet. The NIC NSG has: priority 150, deny 443 from Internet. What is wrong?

Step 1: Remember both NSGs apply. Traffic must pass the subnet NSG AND the NIC NSG.

Step 2: Check the subnet NSG. Priority 200 allows 443 from the Internet — matches, allowed. The deny at 300 never fires for this traffic.

Step 3: Check the NIC NSG. Priority 150 denies 443 from the Internet — matches first, traffic denied.

Answer: the NIC-level NSG blocks the traffic despite the subnet NSG allowing it. Fix: remove or reprioritize the NIC rule. The exam lesson — always check effective security rules (both NSGs), not just one.

Name Resolution

Name resolution in Azure comes in two flavors: Azure-provided DNS and your own custom DNS.

By default, every VNet uses Azure-provided DNS (168.63.129.16), which resolves public internet names and provides automatic name resolution for VMs within the same VNet — VMs can reach each other by hostname without any configuration. You can override this at the VNet level by specifying custom DNS servers (for example, your domain controllers at 10.0.2.4 and 10.0.2.5). When custom DNS is configured, Azure DNS is no longer used for that VNet, so your DNS servers must handle both internal and external resolution — a frequent cause of "VM can't reach the internet" incidents after a DNS change.

Azure DNS Zones

Azure DNS hosts DNS zones as a PaaS service — no DNS servers to manage.

• Public DNS zones resolve names on the public internet (for example, contoso.com). You delegate from your registrar to Azure's name servers.
• Private DNS zones resolve names only inside linked VNets (for example, contoso.internal). They are the standard way to give private endpoints and internal resources stable DNS names without running your own DNS infrastructure.

A private DNS zone does nothing until you link it to a VNet with a virtual network link. Links come in two modes: with auto-registration enabled, VMs in the VNet automatically get A records in the zone; without it, you manage records manually. Private DNS zones also link automatically to private endpoints — when you create a private endpoint for a storage account, Azure creates the matching record in the linked private zone so the storage hostname resolves to the private IP.

A split-brain (split-horizon) setup — the same zone name existing as both public and private — is supported: queries from inside linked VNets hit the private zone, and internet queries hit the public zone.

Load Balancing

Azure offers four load-balancing services, and choosing the right one is a core AZ-104 skill. The decision tree is: global or regional? Layer 4 or Layer 7?

Azure Load Balancer (Layer 4, Regional)

Azure Load Balancer distributes TCP and UDP traffic within a region. It comes in two flavors:

• Public load balancer: frontend is a public IP; distributes internet traffic to backend VMs.
• Internal load balancer: frontend is a private IP inside a VNet; distributes traffic between internal tiers (for example, app servers to database listeners).

SKU differences mirror public IPs. The Basic SKU has no zone redundancy, supports only limited backend pool types, lacks HTTPS health probes, and has no outbound rules. The Standard SKU is zone-redundant, supports any VM or VMSS in the VNet as backend, offers HTTPS probes, and provides outbound rules for controlled SNAT.

Core components:

• Frontend IP configuration: the public or private IP clients connect to.
• Backend pool: the VMs or VMSS instances receiving traffic.
• Health probe: periodically checks backend health (TCP, HTTP, or HTTPS on Standard). Unhealthy instances stop receiving new connections. Probe interval and unhealthy threshold are configurable.
• Load-balancing rule: maps frontend port to backend port (for example, 443 to 443).
• Session persistence (distribution mode): None (default 5-tuple distribution), Client IP (2-tuple, same client goes to same backend), or Client IP and protocol (3-tuple).
• Outbound rules (Standard only): define how backend instances reach the internet, controlling SNAT ports explicitly instead of relying on defaults.
• HA ports (Standard internal LB): a single rule covering all ports, used for network virtual appliances in active-passive or active-active designs.

Choosing Between App Gateway, Front Door, and Traffic Manager

• Application Gateway (Layer 7, regional): HTTP/HTTPS load balancing inside one region with path-based and host-based routing, SSL termination, and an optional Web Application Firewall (WAF). Use it when you need URL-path routing (for example, /images to one pool, /video to another) or WAF protection in a single region.
• Azure Front Door (Layer 7, global): global HTTP/HTTPS entry point with instant failover, SSL offload, WAF, and caching. Use it for multi-region web apps needing the fastest global routing and immediate failover.
• Traffic Manager (DNS-based, global): routes clients at the DNS level using methods like priority (failover), weighted (traffic splitting), geographic, or performance. Because it works through DNS, failover depends on DNS TTL — slower than Front Door. Use it for non-HTTP workloads or simple global failover where DNS-level routing is acceptable.

Worked Scenario: Picking the Load Balancer

Your company runs a web application in two regions (East US and West Europe). Requirements: global users should reach the nearest healthy region, HTTPS traffic, WAF protection, and failover must be near-instant. Which service?

Step 1: Global or regional? Two regions — global.

Step 2: Layer 7 (HTTP/HTTPS with WAF) or DNS-level? Requirements say HTTPS + WAF + near-instant failover.

Step 3: Front Door is Layer 7 global with WAF and instant failover. Traffic Manager is DNS-based — failover waits on DNS TTL, violating "near-instant." Application Gateway is regional only.

Answer: Azure Front Door. The exam pattern — "global + HTTP + WAF + fast failover" always points to Front Door; "global + non-HTTP or DNS-level" points to Traffic Manager; "regional + URL routing" points to Application Gateway.

Connectivity Troubleshooting

When connectivity breaks, Network Watcher is your diagnostic toolkit. It is enabled per region — the features only work in regions where Network Watcher is turned on, which is an easy exam point to miss.

• IP flow verify: answers "would this packet be allowed?" You give it a VM, a packet's 5-tuple (source, destination, ports, protocol), and direction. It tells you whether the NSG rules allow or deny it and which rule decided. Use it before capturing packets — it is the fastest NSG check.
• Next hop: shows where traffic from a VM to a destination would be routed next — the effective route in action. It reveals whether traffic goes to the internet, stays in the VNet, hits a VPN gateway, or gets forced through a firewall appliance by a user-defined route.
• Packet capture: captures actual packets on a VM for deep inspection, stored to a storage account. Sessions are time- or size-limited.
• Connection troubleshoot: runs a live connectivity check between a source VM and a destination (VM, IP, or URL), testing each hop and reporting where the break occurs.
• Connection Monitor: continuous monitoring of connectivity between endpoints, including hybrid (on-premises via agents) scenarios, with latency and loss metrics plus configurable thresholds and alerts.
• NSG flow logs: record metadata about traffic flowing through NSGs (allowed/denied, 5-tuple, timestamps) to a storage account. They log flow metadata, not packet contents. Pairing flow logs with Traffic Analytics (a Log Analytics solution) gives you searchable, visual traffic analysis.

Effective routes deserve special attention because they combine three route sources: system routes (Azure's defaults, including VNet-local and internet routes), user-defined routes from route tables, and BGP routes learned from VPN/ExpressRoute gateways. The "effective routes" view on a NIC shows the merged table. Longest-prefix match wins; among equal prefixes, user-defined routes beat BGP, which beats system routes. When peering or hybrid traffic misbehaves, effective routes usually reveal the culprit — often a UDR forcing traffic to a dead firewall appliance.

Hybrid Connectivity

VPN Gateway

A VPN gateway connects your VNet to on-premises networks over the public internet using IPsec/IKE-encrypted tunnels (site-to-site), or connects individual clients (point-to-site). The gateway lives in the GatewaySubnet — which, again, must carry exactly that name.

Gateway SKUs determine throughput and features: Basic (legacy, low throughput), VpnGw1 through VpnGw5 (increasing bandwidth up to 10 Gbps on VpnGw5), each also available in zone-redundant AZ variants (VpnGw1AZ–VpnGw5AZ). Generation 2 SKUs offer better performance. Remember the subnet guidance: /27 or larger recommended, /29 absolute minimum.

High-availability designs use active-active gateways (two instances, two public IPs, BGP for failover). Site-to-site connections can also run in active-active mode with two tunnels to on-premises VPN devices.

ExpressRoute Basics

ExpressRoute is a private, dedicated connection from on-premises to Azure through a connectivity provider — traffic never crosses the public internet. It offers more consistent latency and higher bandwidth than VPN, at a higher cost. An ExpressRoute circuit supports two peering types: private peering (to VNets, like an extension of your LAN) and Microsoft peering (to Microsoft 365, Dynamics, and public Azure services). The VNet side needs a gateway of the ExpressRoute SKU family. For the exam, know it at this level: private dedicated connectivity, higher consistency and cost than VPN, circuits with private/Microsoft peering. Deep configuration is beyond AZ-104 scope.

Service Endpoints vs Private Endpoints

Both connect VNets to Azure PaaS services (Storage, SQL Database, Key Vault), but they work very differently:

Service endpoints extend your VNet's identity to the PaaS service. You enable the service endpoint on your subnet, and traffic from that subnet to (for example) Azure Storage stays on the Azure backbone instead of going over the internet. The storage account's firewall then allows only your VNet. There is no private IP involved — the PaaS service keeps its public endpoint, but access is restricted to your VNet. Service endpoints are free, simple, and configured per subnet. Limitation: they do not work from on-premises — only from within the VNet.

Private endpoints give the PaaS service a private IP address inside your VNet via a network interface. The storage account becomes reachable at 10.0.3.4, DNS resolves through a private DNS zone, and you can lock the PaaS firewall down completely. Private endpoints work from on-premises too (over VPN/ExpressRoute), because the address is a normal private IP routable through your hybrid network. They cost money per endpoint per hour plus data processing.

The DNS implication is the exam's favorite angle: with a private endpoint, the PaaS hostname (for example, mystorage.blob.core.windows.net) must resolve to the private IP inside your VNet — which is why private endpoints integrate with private DNS zones. If DNS still resolves the public IP, traffic bypasses the private endpoint entirely, a classic misconfiguration.

Azure Bastion

Azure Bastion provides secure RDP and SSH access to VMs directly from the Azure portal over TLS — no public IPs on the VMs, no jump boxes, no VPN client needed. You connect through the portal, Bastion brokers the session, and the VMs stay fully private.

Deployment requirements: a subnet named exactly AzureBastionSubnet with a prefix of /26 or larger, in the same VNet as the VMs (or a peered VNet). Bastion SKUs:

• Basic: core RDP/SSH through the portal.
• Standard: adds native client support (connect with your local RDP/SSH client through Bastion), among other features.
• Premium: adds Kerberos authentication support and shareable links (generate a URL that lets someone access a VM without portal access), plus session recording.

Designing for the Exam: Putting It Together

Most AZ-104 networking questions are not about isolated facts — they chain several concepts into one scenario. A typical question gives you a hub-and-spoke topology with a VPN gateway, asks which subnet a new workload needs, which NSG rules apply, and how on-premises users reach a PaaS database. The way to attack these is layer by layer: addressing first, then connectivity, then security, then name resolution.

Start with addressing. Sketch the address spaces and confirm nothing overlaps — overlapping ranges kill peering designs before anything else matters. Size each subnet with the 2^n − 5 rule, and remember the special subnets: GatewaySubnet for the VPN gateway (/27 recommended) and AzureBastionSubnet (/26 or larger) if administrators need portal-based RDP/SSH without public IPs.

Next, connectivity. Map every path: spoke to hub via peering (non-transitive, so spoke-to-spoke needs its own peering or a hub-routed path), hub to on-premises via the gateway (check "allow gateway transit" on the hub peering and "use remote gateways" on the spoke peering), and PaaS access via service endpoints (VNet-only, free) or private endpoints (private IP, works over hybrid, costs money). If the scenario involves users across regions reaching a web app, run the load-balancer decision tree: regional Layer 4 means Load Balancer, regional Layer 7 with URL routing means Application Gateway, global Layer 7 with WAF means Front Door, global DNS-level means Traffic Manager.

Then security. Walk the NSGs in priority order, lowest first, stopping at the first match — and check both the subnet and NIC associations via effective security rules. Remember the defaults: intra-VNet traffic is allowed (priority 65000) unless you explicitly deny it, and Azure Load Balancer health probes are always allowed inbound (priority 65001), which is why your load-balanced VMs answer probes even with a "deny all" custom rule at priority 4000.

Finally, name resolution. If the scenario uses private endpoints, DNS must resolve PaaS hostnames to private IPs — a missing private DNS zone link is the number-one reason private endpoint designs "don't work" on the exam. If custom DNS servers are configured on the VNet, they own all resolution, internal and external.

When a scenario asks you to troubleshoot, reach for Network Watcher in this order: IP flow verify for "is the NSG blocking it?", next hop for "where is the route sending it?", effective routes for "which route table entry won?", and packet capture or NSG flow logs when you need evidence of what actually traversed the wire. That sequence mirrors how the exam structures its troubleshooting questions — and how you will debug real Azure networks on the job.

End-of-Chapter Test

1. You need a subnet that will host 120 virtual machines. Accounting for Azure's reserved addresses, what is the smallest subnet prefix you can use?

A) 10.0.0.0/25 B) 10.0.0.0/24 C) 10.0.0.0/26 D) 10.0.0.0/23

1. Your VNet uses address space 10.0.0.0/16. You need to add a subnet using 10.5.0.0/24, which is outside the current range. The VNet is in production. What should you do?

A) Delete and recreate the VNet with a larger address space B) Change the existing range to 10.0.0.0/15 in place C) Add 10.5.0.0/16 as an additional address range, then create the subnet D) Create a second VNet and peer it

1. You attempt to peer VNet-A (172.16.0.0/16) with VNet-B (172.16.0.0/20). Both are in the same subscription. What happens?

A) Peering succeeds; different prefix lengths are allowed B) Peering fails because the address spaces overlap C) Peering succeeds but requires a gateway D) Peering succeeds after you add a user-defined route

1. A hub VNet has a VPN gateway to on-premises. Spoke VNets are peered to the hub. Spoke VMs cannot reach on-premises, but hub VMs can. What is the most likely cause?

A) The address spaces overlap B) "Use remote gateways" is not enabled on the spoke-side peering C) The VPN gateway SKU is too small D) Peering is non-transitive and can never support this design

1. Which public IP SKU is required when using a Standard Load Balancer?

A) Basic SKU, dynamic B) Basic SKU, static C) Standard SKU D) Either SKU works

1. Your security team needs outbound traffic from a subnet to appear from a fixed, allowlistable public IP. No inbound connectivity is needed. What should you deploy?

A) A public load balancer B) A NAT gateway C) An application gateway D) A VPN gateway

1. An NSG has these inbound rules: priority 100 — deny all from Internet; priority 200 — allow 443 from Internet. A packet arrives for port 443 from the Internet. What happens?

A) Allowed, because allow rules beat deny rules B) Denied, because priority 100 is evaluated first C) Allowed, because 443 is HTTPS D) Denied, because default rules override custom rules

1. You need an NSG rule that allows ping between two subnets for diagnostics. Which protocol should you select?

A) TCP B) Any, because ICMP is not available in NSG rules C) ICMP D) UDP

1. You want one NSG rule to allow all current and future web servers to reach the database tier on port 1433, without editing the NSG when servers are added. What should you use?

A) Service tags B) Application security groups C) A /26 subnet for each tier D) IP flow verify

1. Your VNet uses custom DNS servers (your domain controllers). After the change, VMs cannot resolve public internet names. What is the most likely cause?

A) Azure DNS is still being used first B) Your custom DNS servers do not forward or resolve external names C) The NSG is blocking port 53 D) Private DNS zones are required for internet resolution

1. You run a web app in three regions and need global HTTPS load balancing with WAF and near-instant failover. Which service should you choose?

A) Traffic Manager with priority routing B) Azure Front Door C) Application Gateway D) Internal load balancer

1. You create a private endpoint for a storage account but traffic still goes to the public IP. What is the most likely cause?

A) Service endpoints are also enabled on the subnet B) DNS still resolves the storage hostname to the public IP instead of the private IP C) The private endpoint needs a Standard SKU public IP D) NAT gateway is intercepting the traffic

Answer Key

1. A — 120 + 5 reserved = 125 addresses needed; a /25 provides 128, the smallest fit. A /26 (59 usable) is too small.
2. C — You can add non-overlapping address ranges to a production VNet at any time; you cannot change an existing range's prefix length in place.
3. B — VNet peering requires non-overlapping address spaces; 172.16.0.0/20 overlaps 172.16.0.0/16, so creation fails.
4. B — Gateway transit requires "allow gateway transit" on the hub side and "use remote gateways" on the spoke side; the spoke-side setting is the classic missing piece.
5. C — Standard Load Balancer requires Standard SKU public IPs; Basic SKU is incompatible.
6. B — NAT gateway provides outbound-only internet access with static public IPs ideal for allowlisting; it accepts no inbound connections.
7. B — NSG rules are evaluated by priority, lowest first, stopping at the first match; priority 100 (deny) fires before priority 200.
8. C — ICMP is a valid standalone protocol choice in NSG rules; select it directly for ping rather than opening "Any."
9. B — Application security groups let NSG rules reference a group of NICs by role; adding a server means joining its NIC to the ASG, with no NSG edits.
10. B — Custom DNS replaces Azure-provided DNS entirely for the VNet, so your servers must handle external resolution themselves.
11. B — Azure Front Door is the global Layer 7 entry point with WAF and instant failover; Traffic Manager's DNS-based failover depends on TTL and is slower.
12. B — Private endpoints depend on DNS resolving the PaaS hostname to the private IP (usually via a private DNS zone); if DNS still returns the public IP, traffic bypasses the endpoint.