Technical Lab: Design a WAF Deployment
Questions
Question 1 — Multiple Choice
A security team needs to protect a web application hosted on Azure against OWASP Top 10 attacks, but requires that the WAF initially operates without blocking legitimate traffic, allowing adjustments before production deployment. Which combination of resource and mode meets this requirement?
A) Azure Front Door with WAF in Prevention mode
B) Application Gateway with WAF in Detection mode
C) Application Gateway with WAF in Prevention mode
D) Azure CDN with WAF in Detection mode
Question 2 — Technical Scenario
An engineer deployed a WAF on Azure Application Gateway v2 with the OWASP 3.2 ruleset in Prevention mode. After deployment, legitimate users report that requests containing certain search parameters are being blocked with HTTP code 403. The engineer needs to resolve the issue without disabling the entire ruleset or changing to Detection mode.
What is the correct approach?
A) Create a global exclusion rule in the WAF for the parameter field that is being incorrectly blocked
B) Replace the OWASP 3.2 ruleset with the Bot Manager ruleset, which is less restrictive for query string parameters
C) Add a custom rule with higher priority that blocks all traffic except traffic originating from the affected users' IPs
D) Upgrade the Application Gateway SKU from WAF_v2 to Standard_v2 to remove parameter inspection
Question 3 — True or False
A WAF configured on Azure Front Door with a policy in Prevention mode can apply differentiated rules by distinct URL routes within the same Front Door profile, associating different WAF policies to each route individually.
True or False?
Question 4 — Technical Scenario
A company operates a public API exposed through Azure Application Gateway with WAF enabled. The security team observes the following diagnostic log:
{
"ruleName": "REQUEST-942-APPLICATION-ATTACK-SQLI",
"action": "Detected",
"matchedData": "1=1",
"policyMode": "Prevention"
}
Despite the action being logged as Detected and the policy mode being Prevention, malicious traffic is not being blocked. What is the most likely cause?
A) The REQUEST-942 rule is individually disabled in the ruleset, overriding the policy's Prevention mode
B) The field action: Detected indicates that the WAF is still in automatic learning phase and has not yet converged
C) The log is using the legacy diagnostic format, which does not reflect the current policy state
D) The Application Gateway is configured with a listener in Multi-site mode that ignores WAF policies per route
Question 5 — Multiple Choice
When designing a WAF for an architecture with multiple web applications with distinct security requirements, which characteristic of Azure Front Door differentiates its WAF policy approach from Application Gateway?
A) Front Door allows associating a single global WAF policy to all domains, while Application Gateway allows policies per listener
B) Front Door operates at layer 4, inspecting TCP packets, while Application Gateway operates at layer 7
C) Front Door does not support Microsoft-managed rulesets, requiring all rules to be customized by the customer
D) Front Door does not allow Detection mode, only Prevention, unlike Application Gateway
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Detection mode on Application Gateway with WAF logs threats without blocking traffic, allowing the team to analyze false positives before enabling actual blocking. Prevention mode immediately blocks and logs, which is not suitable for an initial adjustment phase in production. Azure CDN with WAF is a different service and is not equivalent to Application Gateway for hosting applications with complete L7 inspection. Front Door with Prevention contradicts the requirement of not blocking traffic during adjustments.
The most common mistake here is confusing "observe without interfering" with Prevention behavior, imagining that it only generates alerts.
Answer Key — Question 2
Answer: A
Exclusion rules (exclusion lists) in Application Gateway WAF allow specific request fields (such as headers, cookies, or query string parameters) to be ignored by inspection of certain rules or the entire ruleset, without disabling global protection. This is the correct surgical approach for false positives.
The Bot Manager ruleset has a different purpose, focused on bot mitigation, not on reducing OWASP sensitivity. Creating a blocking rule by IP is the opposite of the problem. Downgrading the SKU to Standard_v2 completely removes the WAF, which is an architectural decision, not a policy adjustment.
Answer Key — Question 3
True
In Azure Front Door, WAF policies are associated with routes within an endpoint, not just the profile as a whole. This means it's possible to link distinct policies to distinct routes within the same profile, allowing granular segmentation of rules by URL path or domain. This is an important design difference compared to Application Gateway, where the WAF policy is associated with the listener or the gateway itself.
The common confusion is assuming that the WAF policy is always applied uniformly across the entire Front Door profile, which would lead to under-dimensioning or over-protecting certain routes.
Answer Key — Question 4
Answer: A
When an individual rule in a managed ruleset is disabled, it logs the action as Detected regardless of the policy's global mode. This occurs because disabling the rule removes its ability to block, even if the policy is in Prevention mode. The log records the match, but the effective action is Detected because the rule was explicitly suppressed.
Application Gateway WAF does not have an "automatic learning" mechanism or progressive convergence like some third-party WAFs. The legacy log format does not interfere with real-time behavior. Multi-site mode affects request routing, not WAF policy application.
Answer Key — Question 5
Answer: A
Azure Front Door allows a WAF policy to be associated with a domain or set of domains managed globally, but its granularity per route allows differentiation within the profile. Application Gateway associates WAF policies at the listener level or the gateway itself, which means different listeners can have distinct policies for distinct applications on the same gateway.
Option B is wrong because Front Door operates at layer 7, just like Application Gateway. Option C is wrong because Front Door supports managed rulesets, including the OWASP set and Bot Manager. Option D is wrong because both services support Detection and Prevention modes.