AZ-305 network security questions are usually placement questions. The exam is not asking which Azure service sounds most secure. It is asking which control belongs on the path for a specific traffic direction, inspection requirement, attack type, or exposure boundary.
Use Azure Firewall when the design needs centralized stateful network and application-level policy, logging, and inspection across virtual networks, subscriptions, hub-spoke traffic, or controlled egress. Use NSGs for distributed subnet or NIC-level allow/deny filtering. Use WAF when the requirement is HTTP or HTTPS web application protection against common exploits. Use Azure DDoS Protection for public endpoint availability against volumetric and protocol attacks. Use Private Link when a supported service should be reached through a private endpoint, then check public exposure controls separately.
Start With The Traffic Path
The fastest exam model is to ask what kind of traffic is being controlled:
| Scenario signal | Better exam move |
|---|---|
| Centralized outbound policy, logging, or hub-spoke inspection | Put Azure Firewall on the routed path. |
| Subnet-to-subnet or NIC-level allow/deny filtering | Use NSGs as distributed filters. |
| Internet-facing HTTP/S app must block common web exploits | Use WAF with Application Gateway or Azure Front Door. |
| Public endpoint faces volumetric or protocol attack risk | Use Azure DDoS Protection; do not treat it as L7 request filtering. |
| PaaS access must use private address space | Use Private Link/private endpoint, then separately verify public access controls. |
| Requirement is identity, RBAC, or app authorization | Do not substitute a network control for an identity or permission control. |
The major trap is treating one service as a universal replacement. Azure Firewall and NSGs are complementary. WAF and DDoS Protection address different layers. Private Link changes the service access path but does not automatically prove every public path is closed.
Worked Scenario
A company is designing a hub-spoke Azure environment for a public web application. The architecture team has four requirements:
- Public users must reach the web application, but common HTTP/S attacks should be filtered before requests reach the workload.
- Public endpoints must have stronger mitigation against volumetric and protocol attacks.
- Spoke workloads need centralized outbound policy and logging across subscriptions.
- The application must reach a supported PaaS dependency privately, and the team must not assume the public service path is closed unless the service controls say so.
The AZ-305 answer is layered. Put WAF in front of the HTTP/S web application path because the attack type is web exploits. Enable the DDoS protection layer for public endpoint availability risk because that is a network-layer attack problem, not a URL-rule problem. Place Azure Firewall in the hub for centralized stateful policy, logging, and controlled egress, but only traffic routed through that inspection point is inspected. Keep NSGs at subnet or NIC boundaries for local allow/deny filtering. Use Private Link with a private endpoint for the supported PaaS dependency, then separately verify the service's public network access or firewall settings.
Now change one requirement: the only issue is that one subnet should not talk to another subnet. That does not automatically require WAF, DDoS Protection, or Private Link. The direct control is an NSG rule design at the subnet or NIC boundary. If the requirement instead says outbound destinations must be centrally logged and governed across spokes, NSGs alone are not the complete answer; the design needs Azure Firewall on the traffic path.
How To Defend The Choice
For each answer option, say what it controls and what it does not control:
- Azure Firewall: centralized stateful network and application-level policy, inspection, and logging. It is not the same thing as WAF for inbound web exploit protection.
- NSG: distributed inbound and outbound filtering for virtual network traffic. It is not centralized application-level inspection.
- WAF: HTTP/S web application protection against common exploits. It is not a general egress firewall or DDoS replacement.
- Azure DDoS Protection: L3/L4 attack mitigation for public endpoint availability. It is not L7 request inspection or fine-grained access control.
- Private Link: private endpoint access to supported services. It is not proof that public network access is disabled for every service.
Quick Recap
If the interactive components do not load, remember the decision model: place the control on the path that matches the requirement. Use WAF for HTTP/S web exploit protection, Azure DDoS Protection for L3/L4 public endpoint attack mitigation, Azure Firewall for centralized stateful policy and logging, NSGs for subnet or NIC filtering, and Private Link/private endpoints for private access to supported services. Do not use identity controls as substitutes for network-path enforcement, and do not assume private access automatically closes public exposure.
Ready to test this under exam pressure? Take the targeted AZ-305 assessment and look for scenarios where the answer changes because the traffic direction, inspection layer, or exposure boundary changes.