Microsoft AZ-700: Network Security — Study Guide

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Network access control: NSG and ASG design, routing and peering

Network Security Groups (NSGs) remain the primary, low-cost mechanism for filtering traffic into and out of subnets and NICs. NSGs are stateful, can reference service tags (e.g., Internet, Storage) and support application security groups (ASGs) to group VM NICs and scale rule maintenance for large fleets. Apply NSGs at the subnet for broad segmentation and at the NIC for host-specific exceptions; remember that both are evaluated, and the most restrictive effective set applies. Common traps include forgetting the default rules (deny/allow system rules at high priorities), mis-ordering priorities (NSG rule priorities range from 100 to 4096; system defaults sit at 65,000+), and assuming NSGs provide IDS/antivirus capabilities — they do not inspect payloads. When peering virtual networks, NSGs still govern traffic between the peers, but UDRs (user-defined routes) can override system routes and unintentionally blackhole traffic if a next hop (for example, to an Azure Firewall) isn’t reachable in that context. Design trade-offs weigh cost and simplicity of NSGs/ASGs against the visibility and advanced controls of a centralized firewall: NSGs are cheap and performant for coarse filtering; use a managed firewall for centralized logging, DNAT/NAT control, and application-layer policies.

Perimeter and east-west controls: Azure Firewall, DNAT, application rules and IDPS

Azure Firewall provides a managed stateful perimeter capable of DNAT, SNAT, and application-layer rules. Architect it in a dedicated AzureFirewallSubnet and use route tables to steer hub-spoke east-west traffic through the firewall for inspection. Use DNAT collections to publish internal services: specify source ranges, destination IP, destination ports and translated IP:port. Application rule collections let you permit by FQDN for HTTP/S (e.g., *.microsoft.com) which avoids brittle IP allowlists. For deep packet inspection and encrypted traffic inspection, Azure Firewall Premium adds an IDPS engine and TLS inspection, at higher cost and operational complexity for certificate management and potential latency. Third-party NVAs remain a valid choice when you need specialized signatures or performance characteristics. Scale and resilience decisions include using Firewall autoscale (v2) or zone-redundant deployments versus fixed instances: autoscale eases throughput constraints but is more expensive. Monitor firewall metrics and logs in Log Analytics to detect DNAT/SNAT exhaustion and tweak rule ordering and public IP counts when necessary.

Azure Firewall Standard: stateful L3–L7 filtering, NAT/DNAT, application and network rules, managed service with autoscale options and integrated logging.
Azure Firewall Premium: includes Standard features plus IDPS, TLS inspection, advanced threat intelligence and URL filtering; higher cost and requires certificate/key management for TLS inspection.

Application-layer protection, Private Link and DDoS

Protect web applications at the edge with WAFs and distributed edge services. Application Gateway WAF_v2 provides regional WAF with integration into a VNet and is ideal when backends are private (App Service with ASE or VMs). Azure Front Door (edge) provides global load balancing and WAF at the CDN edge and reduces latency for global clients; choose Front Door for global failover and App Gateway for regional private-backend protection. DDoS protection (Basic included) should be upgraded to DDoS Protection Standard where public IPs host important services; it automatically profiles traffic and mitigates volumetric attacks for resources in a protected virtual network. For private access, Private Link/Private Endpoints provide a private IP in your VNet for platform services, eliminating public exposure. Common pitfalls include forgetting to disable public network access on the PaaS resource, mishandling private DNS integration (you must own and map privatelink zones or configure conditional forwarders), and expecting edge WAFs to reach private endpoints without a regional proxy; often a small, hardened reverse-proxy (Application Gateway or Firewall) in a perimeter subnet routes traffic from front-door to the private endpoint.

Operational controls: logging, policy, monitoring and common engineer traps

Operational hygiene is often the differentiator between secure and brittle network estates. Enable NSG Flow Logs (v2) and Azure Firewall diagnostics to a centrally managed Log Analytics workspace and wire them to Azure Monitor and Sentinel for analytics, threat hunting and alerts. Use Traffic Analytics for aggregated topology, top talkers and flow anomalies; remember Traffic Analytics requires Network Watcher and a Log Analytics workspace in the same region. For hybrid links, Network Performance Monitor (NPM) and Connection Monitor provide periodic latency, jitter and path health which helps prove SLAs for ExpressRoute and SD‑WAN. Enforce guardrails with Azure Policy: require Azure Firewall in hubs, disallow public IP creation on private-only resources, and audit NSG rule priority ranges or untagged rules. Common traps include route precedence (UDR overrides system routes), SNAT port exhaustion when many connections egress through a single public IP (mitigate by adding public IPs or using firewall autoscale), and subnet naming requirements (AzureFirewallSubnet must exist for Firewall). Decisions on resilience versus cost are iterative: centralize inspection for visibility, but localize for latency-sensitive paths and use autoscale/zonal redundancy where workloads are critical.

Practical Problem: Use-Case Scenario

Scenario: Contoso Ltd. runs a hub-and-spoke Azure network spanning two regions with a central hub VNet containing a zonal Azure Firewall and shared services. Branch sites connect via SD‑WAN BGP to regional hubs. Several PaaS web apps use private endpoints in spoke VNets.

Challenge: Internet customers must reach a public front door for global routing, but web app backend traffic must terminate on private endpoints and all egress from spokes must be inspected and logged without exposing PaaS resources publicly.

Recommended Approach:

Deploy Azure Front Door Standard/Premium as the global public entry point and attach a regional Application Gateway in each hub as a private origin, or use Front Door Premium with a secure private origin configuration where supported.
Place an Application Gateway v2 in the hub VNet subnet (dedicated per AGW) and configure it to forward traffic to the App Service Private Endpoint via VNet peering; enable WAF_v2 on the Application Gateway and associate a managed WAF policy.
Route all spoke outbound traffic through the hub Azure Firewall Premium (in AzureFirewallSubnet) using UDRs on spokes; enable DNAT rules for required inbound translations and application rules for FQDN egress; enable IDPS and TLS inspection on the Premium SKU for encrypted traffic visibility.
Centralize logs to a Log Analytics workspace, enable NSG Flow Logs and Traffic Analytics, enable DDoS Protection Standard on the hub public IPs, and enforce the architecture with Azure Policy (require Firewall, disallow public network access on PaaS).

Rationale: Front Door gives global availability and low latency, Application Gateway with WAF_v2 secures private backends, and Azure Firewall Premium provides centralized inspection, DNAT and IDPS for both egress and ingress. Centralized logging and policy enforcement ensure visibility and compliance while keeping PaaS endpoints private.

← Azure DNS · All domains · Load Balancing →

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