Microsoft AZ-500: Network Security Architecture — Study Guide

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Part of the Microsoft Azure Security Engineer Associate AZ-500 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure network security architecture enforces least-privilege connectivity, assumes breach, and instruments continuous monitoring. It combines micro-segmentation inside virtual networks, stateful control planes for east-west and egress traffic, edge protections for internet-facing endpoints, and private access to PaaS. Sound designs prioritize identity-aware access at the application layer while maintaining strong network boundaries, explicit routing, and verifiable telemetry.

Virtual Network Controls and Segmentation

Subnets are the first segmentation boundary. Place workloads with similar trust, lifecycle, and policy in the same subnet; separate tiers (web, app, data) so you can apply independent policies and routes. Avoid flat “shared” subnets that mix admin tools, jump hosts, and business workloads; they complicate policy and increase blast radius.

Network Security Groups (NSGs) apply stateful L3–L4 filtering per subnet or per NIC. Inbound and outbound rules are evaluated by priority (lower number first), with an implicit DenyAll at the end. NSGs are stateful: responses to permitted flows are allowed automatically, so you rarely need ephemeral port rules. Operationally, bind NSGs to subnets for broad controls, then refine on critical NICs. Always document owner, purpose, and expiration for any “temporary” allows.

Application Security Groups (ASGs) let you reference VM groups by name rather than IP, so rules survive scaling and IP churn. Tag VMs into role-based ASGs (e.g., asg-web, asg-app) and express policies like “asg-web → asg-app TCP 443.” This reduces rule sprawl and operational drift.

Effective security rules result from merging NSGs applied to both a NIC and its subnet. The most specific matching allow/deny (by priority) wins. Validate with “Effective security rules” in the portal or via Network Watcher IP flow verify to catch conflicting entries before deployment windows.

Service tags (e.g., AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) are maintained by Microsoft and collapse large, dynamic IP spaces into stable rule targets. Prefer service tags to manual IP lists to avoid outages on service IP rotation. For example, restrict egress to Storage and Sql while denying broad Internet.

Micro-segmentation and Zero Trust are realized by:

• Applying deny-by-default NSGs and only opening explicit, minimal paths.
• Using ASGs to encode workload intent.
• Restricting egress with service tags or FQDN-based filtering via Azure Firewall.
• Enforcing “no public IP on servers” and routing all egress through a controlled inspection point.

Example: create an NSG rule allowing web-to-app over TLS with ASGs and deny all else explicitly at a higher priority than the implicit deny to document intent.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Network Security Services and Edge Protection

Azure Firewall is a fully stateful, high-availability firewall with central policy. Use it for:

• East-west and egress control when NSGs are insufficient (domain names, TLS inspection).
• DNAT for limited inbound exposure when Application Gateway is unsuitable.
• Central logging and threat intelligence.

Rule collection groups contain rule collections (Network, Application, NAT) with priorities that define evaluation order. Within a group, lower priority collections are evaluated first; rules are matched by most-specific criteria. Keep DNAT rules in their own group with the highest evaluation priority to capture inbound traffic deterministically.

• Network rules filter by 5-tuple (IP/port/protocol).
• Application rules filter by FQDN, URL categories (Premium), and can use FQDN tags.
• NAT rules translate public to private addresses/ports for inbound scenarios.

Threat intelligence-based filtering blocks known bad IPs/domains. Run in Alert during initial baselining, then Deny once false positives are addressed.

Premium features add:

• TLS inspection with outbound and inbound decryption, enabling L7 visibility and IDPS.
• Intrusion Detection and Prevention (IDPS) with signatures and vulnerability prioritization.
• URL filtering and web categories for granular egress control.
• Advanced certificate and TLS policy controls.

Operationally, isolate the firewall in a dedicated subnet (AzureFirewallSubnet), route all internet-bound traffic to it with UDRs, and enable Availability Zones. Use Firewall Policy (not classic rules) for scalable administration, inheritance, and Dev/Test divergence with a shared base policy.

Web Application Firewall (WAF) mitigates L7 attacks (SQLi, XSS).

• On Application Gateway, WAF protects regional apps with end-to-end TLS and per-site policies; it terminates client TLS and optionally re-encrypts to backend.
• On Azure Front Door, WAF protects globally distributed apps at the edge with integrated CDN, bot protections, and geo controls.

Create WAF policies and associate them to gateways, listeners, or routes. Choose Detection mode initially to tune, then Prevention to block. Use managed rule sets (OWASP 3.x) and add custom rules for rate limits or IP ranges. Configure exclusions (e.g., specific JSON fields or headers) to reduce false positives without weakening overall protection.

Distributed Denial of Service (DDoS):

• Basic is always-on platform protection but offers no per-resource telemetry or mitigation tuning.
• DDoS Protection: Network Protection adds adaptive tuning per public IP, automatic mitigation, attack analytics, alerting, cost protection credit, and access to DDoS Rapid Response.

Enable Network Protection on VNets hosting public IPs (Standard SKU). Use telemetry (Metrics, Diagnostic logs) to observe attack vectors, mitigation lifecycle, and effectiveness. Architect protected resources behind load balancers or Application Gateway to absorb volumetric load, and minimize direct public exposure. Combine WAF and DDoS for layered defense.

Private Access, Hybrid Connectivity, and Routing

Private Link and private endpoints provide private IP access from your VNet to PaaS services. A private endpoint is a NIC in your subnet mapped to the PaaS resource; traffic stays on Microsoft’s backbone. Operational steps:

• Disable public network access on the PaaS resource to prevent bypass.
• Deploy private DNS zones (e.g., privatelink.blob.core.windows.net) and link them to VNets for seamless name resolution.
• Manage approvals centrally; consider subscription/tenant isolation with manual approval workflow.

Service endpoints extend your subnet identity to PaaS resources over their public IPs, allowing the PaaS firewall to restrict access to specific subnets. They do not create private IPs, so egress passes the public edge but remains within the Microsoft network. Use service endpoint policies to allow only approved storage accounts. For containerized workloads on IaaS VMs, ensure Azure CNI is used so pod/container IPs are from the subnet; otherwise the service endpoint will not recognize the source and access can fail.

DNS resolution strategy:

• For Private Link, ensure your DNS path resolves the PaaS FQDN to the private endpoint. Use Azure Private DNS zones, conditional forwarders on on-prem DNS, or Azure DNS Private Resolver for hybrid forwarding.
• Keep authoritative split-horizon mappings clear to avoid intermittent public resolution.

Hybrid connectivity:

• VPN Gateway: For site-to-site, use route-based VPN with IKEv2 and strong ciphers. Use BGP to exchange routes dynamically, simplifying growth and failover. Apply VPN NAT when overlapping address spaces exist. For forced tunneling, advertise 0.0.0.0/0 from on-prem via BGP or apply UDRs sending 0/0 to a virtual appliance; ensure an exception route for PaaS private ranges as required.
• ExpressRoute: Provides private connectivity; encryption is not inherent. Use MACsec (for ExpressRoute Direct) or run IPsec over ER for confidentiality. Use BGP communities and route filters for Microsoft peering. Support active-active with ECMP across circuits for resiliency. For forced tunneling, accept default routes from on-prem and ensure no conflicting UDRs blackhole internet paths.

User-defined routes (UDRs), NVAs, and precedence:

• Route selection uses longest prefix match, then source: UDR > BGP > system. Misapplied 0/0 UDRs can blackhole return paths; validate with Network Watcher’s next-hop.
• For NVAs, enable IP forwarding on NICs and place behind a load balancer or Gateway Load Balancer for transparent, scalable insertion. Prefer Azure Firewall for managed scenarios; when vendor-specific features are required, design HA with multiple availability zones and health-probed load balancing.

Secure Administration, Monitoring, and Telemetry

Secure administrative connectivity:

• Azure Bastion provides RDP/SSH over TLS from the portal or native client without exposing VM public IPs. Use Standard SKU for scale, IP-based connections, and shareable links. Restrict Bastion access by RBAC and Just-in-Time.
• Just-in-Time VM access (Defender for Cloud) closes management ports in NSGs and opens them on time-bound request with approval and source IP limits. Combine with Bastion for a no-public-IP posture and precise audit trail.

Network Watcher provides operational verification and forensics:

• NSG flow logs (v2) write to storage and can be sent to Traffic Analytics in Log Analytics for insights on top talkers, allowed/denied flows, and geography.
• Connection troubleshoot actively tests end-to-end connectivity and reports where a path is blocked (NSG, UDR, DNS, firewall).
• Packet capture can be triggered on-demand or by alerts; use ring buffers to reduce storage and capture only relevant ports.
• Effective routes and IP flow verify map runtime decisions across UDRs, BGP, and NSGs; automate these checks in CI/CD preflight.

Enable NSG flow logs and analytics quickly:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Practical Problem Scenario

Starbucks is modernizing an order management platform to Azure. Security goals: no public IPs on app/data tiers, strict egress, global web protection, and operational visibility.

1. Create three subnets per region: web, app, data, each with its own NSG and role-aligned ASGs.

Rationale: Subnet-based micro-segmentation with ASGs encodes least-privilege flows (web→app 443, app→data 1433) and reduces blast radius. Separate NSGs per tier avoid accidental policy coupling.

2. Deploy Azure Front Door Standard/Premium with WAF policy in Prevention mode using OWASP 3.x and custom rules for rate limiting and geo restrictions.

Rationale: Global edge protection absorbs volumetric traffic, blocks common L7 attacks before they reach the region, and reduces latency via anycast. WAF policies at the edge provide consistent enforcement across regions.

3. Place Application Gateway with WAF v2 in each region in front of the web tier; terminate TLS at App Gateway and re-encrypt to backend.

Rationale: Regional L7 routing and WAF complement Front Door, enabling per-app mTLS to backends, cookie-based affinity, and blue/green deployments while maintaining inspection capability.

4. Enable DDoS Protection: Network Protection on the VNets containing Application Gateway public IPs.

Rationale: Adaptive per-IP mitigation, telemetry, and cost protection reduce risk from volumetric attacks targeting regional entry points. VNet scoping ensures all current and future public IPs are protected without per-resource configuration.

5. Deploy Azure Firewall Premium in a secured hub; route all egress from app and data subnets to it with UDRs. Enable TLS inspection and IDPS for outbound traffic, and configure application rules to allow only required FQDNs.

Rationale: Centralized egress control with decryption and signature-based detection prevents command-and-control and data exfiltration. Application rules reduce maintenance versus IP-based rules and align to Zero Trust egress.

6. Use Private Link for Azure SQL and Storage; disable public network access and configure private DNS zones linked to all VNets. For containerized workloads, use Azure CNI.

Rationale: Private endpoints keep data paths on the backbone and eliminate public exposure. Private DNS ensures seamless name resolution. Azure CNI guarantees pod IPs originate from the subnet so Private Link and service endpoints function correctly.

7. Establish ExpressRoute with dual circuits in active-active and advertise on-prem routes with BGP; enable IPsec over ER for sensitive traffic. Do not advertise 0/0 initially; pilot forced tunneling in a staging subnet first.

Rationale: ER provides predictable, private connectivity; layered encryption protects high-sensitivity flows. Controlled rollout of forced tunneling prevents accidental internet blackholing and validates exception routes.

8. Provide administrative access via Azure Bastion and enforce Just-in-Time on all VMs; remove all public IPs from servers.

Rationale: Eliminates exposed management surfaces while preserving auditable, time-bound access aligned with least privilege.

9. Turn on NSG flow logs and Traffic Analytics, configure Firewall and WAF diagnostics to Log Analytics, and set alerts for DDoS mitigations and WAF blocking surges.

Rationale: Unified telemetry enables proactive detection, capacity planning, and rapid incident response. Alerting on anomaly patterns catches attacks and misconfigurations early.

10. Implement Azure Policy to deny public IPs on NICs, require NSGs on all subnets, and audit VNets without DDoS enabled; integrate policy checks into CI/CD.

Rationale: Prevents drift, enforces guardrails at scale, and makes secure defaults repeatable for future workloads.

← Identity and Access Management · All domains · Compute →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →