A canal authority’s production public IPs sit in front of Application Gateway and Azure Firewall, and a past flood exhausted scale-out without anyone being paged. When should the security engineer recommend Azure DDoS Protection Standard?
Select an answer to reveal the explanation.
Short Explanation
Public IPs in front of the locks are what the flood hits—Standard gives you adaptive L3/L4 shields plus Monitor metrics so someone gets paged. No public IP? Don’t buy Standard for that VNet. WAF is the web layer; DDoS Standard is the pipe layer.
Full Explanation
Azure DDoS Protection Standard is the right recommendation when internet-facing public IPs front Application Gateway and Azure Firewall and the canal authority needs adaptive Layer 3/Layer 4 mitigation plus actionable telemetry. Network Protection on the virtual network or IP Protection on the selected public addresses brings tuned attack thresholds, Azure Monitor metrics and alerts, and mitigation logs so a volumetric flood against lock-facing endpoints pages someone instead of silently exhausting scale-out. That is the control that sits at the network pipe, not at the HTTP application layer.
Enabling Standard only on VNets that have no public IPs fails the premise: without public endpoints there is nothing for Network or IP Protection to shield, and private-subnet-only telemetry is not what Standard is for. Relying on a WAF policy alone for volumetric L3/L4 floods fails by concept because a web application firewall inspects HTTP(S) after TLS termination; it does not replace adaptive DDoS mitigation for large packet floods that saturate bandwidth before Application Gateway logic runs. Treating a Sentinel analytics rule on packet loss as a substitute fails because detection without platform mitigation still leaves the public IPs exposed during the attack—Sentinel can alert, but it does not scrub or absorb the flood the way DDoS Protection Standard does.
Exam caveat: Basic (free) DDoS protection is always on for Azure; Standard is the paid tier that adds adaptive tuning, richer metrics, and mitigation reporting for production public endpoints. Operational check: after enabling Network or IP Protection, verify the public IPs are associated with the plan, confirm DDoS metrics appear in Azure Monitor, and test an alert rule so night shift is paged when mitigation starts—not after the canal API is already unreachable.