AZ-305 Network Security: Azure Firewall, NSG, or WAF?

For AZ-305 network-security questions, do not treat Azure Firewall, network security groups (NSGs), and Azure Web Application Firewall (WAF) as three names for the same control. Use NSGs for subnet or network-interface allow/deny rules. Use Azure Firewall when the design needs centralized stateful network policy, egress filtering, threat intelligence, DNAT, or hub-spoke inspection. Use WAF when the risk is HTTP(S) web-app attacks such as SQL injection or cross-site scripting. Microsoft lists network security optimization inside the AZ-305 infrastructure domain, which is weighted 30-35% in the current study guide (AZ-305 study guide, AZ-305 exam page).

Compact Decision Shortcut

• Choose an NSG when the requirement is local traffic filtering at a subnet or NIC boundary: source, destination, protocol, port, direction, priority, and allow/deny behavior (NSG overview).
• Choose Azure Firewall when the requirement is centralized inspection or policy across VNets, subscriptions, hub-spoke networks, internet egress, non-HTTP(S) flows, DNAT, FQDN-based application rules, or threat-intelligence filtering (Azure Firewall overview).
• Choose WAF when the workload is a web app and the requirement is protection from common web exploits and vulnerabilities at the HTTP layer (Azure WAF overview).
• Use more than one when the scenario has more than one boundary. Microsoft explicitly describes Azure Firewall and Application Gateway/WAF as complementary services for network and application-layer protection (Azure Architecture Center).

The Boundary Diagram

The exam trap is replacing a layered design with one product. An NSG can block an unexpected port on a subnet, but it does not give the same centralized egress control as Azure Firewall. Azure Firewall can filter network and application traffic, but Microsoft still recommends WAF for web workloads because WAF is built for HTTP-layer attack patterns. WAF protects the web application path, but it does not replace subnet-level guardrails or outbound network policy.

Decision Cards

NSG: Subnet and NIC Guardrail

Use an NSG when the scenario asks for traffic filtering between Azure resources in a virtual network, or when a subnet/NIC needs explicit inbound or outbound allow/deny rules. Microsoft describes NSGs as security rules that filter inbound and outbound network traffic for Azure resources in virtual networks, evaluated by priority and five-tuple information (NSG overview).

Exam clue: "Only the application subnet should accept TCP 443 from the gateway subnet." That is an NSG-style boundary. It is local, rule-based, and tied to subnet or NIC placement.

Do not overstate it. NSGs are not the best answer for centralized FQDN egress filtering, internet-scale threat intelligence, or HTTP request inspection. They are also stateful: if you allow an outbound connection, you do not need a matching inbound rule for the response traffic.

Azure Firewall: Central Network Policy

Use Azure Firewall when the architecture needs a managed, stateful firewall service for centralized policy. Microsoft describes Azure Firewall as cloud-native, fully stateful, highly available, and scalable, with Standard offering L3-L7 filtering and threat-intelligence feeds and Premium adding IDPS capabilities (Azure Firewall overview).

Exam clue: "All spoke VNets must send outbound internet traffic through a central security service, and only approved FQDNs should be reachable." That is an Azure Firewall-style boundary. The design usually includes a hub or secured virtual hub, route tables, firewall policies, logging, and an egress allow list.

Do not confuse Azure Firewall with a web application firewall. Azure Firewall can participate in inbound and outbound designs, but Microsoft distinguishes WAF as the web-layer control for common application exploits.

WAF: Web Application Attack Protection

Use WAF when the scenario is about HTTP(S) applications and the risk is web-layer attacks. Microsoft says Azure WAF provides centralized protection for web applications from common exploits and vulnerabilities, including examples such as SQL injection and cross-site scripting, and can be deployed with Application Gateway, Application Gateway for Containers, Front Door, and Azure CDN (Azure WAF overview).

Exam clue: "The public web app must be protected from OWASP-style attacks while preserving Layer 7 routing." That points to WAF on Application Gateway or Front Door, depending on whether the routing requirement is regional or global. If the question is mainly about choosing Front Door, Application Gateway, Traffic Manager, or Load Balancer, use the existing AZ-305 load balancing decision guide instead of turning this article into a routing matrix.

Do not use WAF as the answer for SSH, RDP, custom TCP, general subnet segmentation, or outbound allow-listing. WAF is about web application traffic.

Worked Scenario: Public App, Private Admin, Controlled Egress

A company hosts a payment portal on VMs in a spoke VNet. Internet users reach the app over HTTPS. Administrators connect from on-premises through a private network path. Security requires three things:

• block common web attacks before requests reach the app;
• allow the web subnet to receive traffic only from the gateway tier;
• force outbound traffic from workload subnets through a central inspection point.

First pass: put WAF in the web ingress path. If the app is regional and the back ends are private, WAF on Application Gateway is a natural fit. If the app needs a global edge entry point, compare Front Door with WAF. That is a web attack boundary, not just a port boundary.

Second pass: use NSGs on the application subnets to keep local rules tight. The app subnet should accept the expected ports only from the gateway tier or approved source ranges. The database subnet should not accept random spoke traffic just because the VNet is peered.

Third pass: send outbound workload traffic through Azure Firewall by route table when the scenario asks for centralized egress control, FQDN filtering, logging, or threat-intelligence enforcement. Microsoft says a common parallel design uses WAF on Application Gateway for inbound web traffic while Azure Firewall covers outbound flows and non-HTTP(S) workloads (Azure Architecture Center).

Exam-ready answer: WAF for public web attack protection, NSGs for subnet-level guardrails, and Azure Firewall for centralized egress and non-web network inspection. If the same scenario starts talking about VPN Gateway, ExpressRoute, Virtual WAN, Private Link, or hybrid DNS, review the AZ-305 hybrid network connectivity guide because that is a transport and private-access boundary.

What Wrong Answers Reveal

• Choosing only an NSG for centralized egress control usually means you missed the hub-spoke policy requirement.
• Choosing Azure Firewall as the only answer for SQL injection usually means you missed the HTTP application-layer clue.
• Choosing WAF for RDP, SSH, or custom TCP usually means you mapped "firewall" to the wrong traffic type.
• Choosing WAF because Application Gateway appears in an answer choice may mean the actual question was about Layer 7 load balancing. That belongs in the routing guide.
• Choosing Private Link for every security problem means you drifted into private service access. Private Link can reduce exposure to a PaaS resource, but it is not a replacement for NSGs, Firewall, or WAF.

Study Drill For AZ-305

Practice changing one requirement at a time:

• If the requirement changes from "block internet inbound to a subnet" to "allow only approved outbound domains," does Azure Firewall become stronger than an NSG?
• If the requirement changes from "HTTP app attacks" to "custom TCP protocol," does WAF drop out?
• If the requirement changes from "single subnet rule" to "many spokes and subscriptions," does centralized firewall policy matter?
• If the requirement changes from "regional private web back end" to "global edge routing," do you need to revisit Front Door versus Application Gateway?

When you are ready to see whether these boundaries are costing you points, take the AZ-305 assessment. CramHQ is independent exam-preparation software, not a Microsoft product and not a pass guarantee. For this topic, the useful learning loop is to identify whether a miss came from local filtering, centralized network policy, web-layer protection, routing, or private connectivity, then use targeted remediation, lessons, and nearby practice instead of rereading the whole networking domain.

Quick Recap

Use NSGs for subnet and NIC traffic rules. Use Azure Firewall for centralized stateful network policy, egress control, non-HTTP(S) filtering, DNAT, and threat-intelligence-backed inspection. Use WAF for HTTP(S) web application attack protection. On AZ-305, the best answer is often layered: choose the control that matches the boundary in the scenario, then add adjacent controls only when the requirements actually name another layer.