Technical Lab: Configure Rule Sets for WAF on Application Gateway
Questions
Question 1 — Multiple Choice
A security team needs to ensure that the WAF on Application Gateway v2 uses the latest available OWASP ruleset, with improved coverage against injection attacks and lower false positive rate compared to previous versions. Which ruleset meets this requirement?
A) OWASP 2.2.9, for being the ruleset with the highest number of individual rules available in Application Gateway
B) OWASP 3.0, for being the stable version most widely tested in Azure production environments
C) OWASP 3.2, for offering precision and coverage improvements over previous versions of the same set
D) Microsoft Default Ruleset (DRS), for completely replacing OWASP and being optimized exclusively for Azure
Question 2 — Technical Scenario
An engineer configures the WAF on Application Gateway with the OWASP 3.2 ruleset and observes that a specific rule from the REQUEST-931-APPLICATION-ATTACK-RFI group is generating false positives for a legacy application. The team cannot modify the application code and needs to suppress only this rule while keeping all others active.
Which action resolves the problem with the least impact on security posture?
A) Change the WAF mode from Prevention to Detection for the entire policy, eliminating the blocking of the affected rule
B) Disable the complete REQUEST-931 rule group in the ruleset settings
C) Create an individual rule exclusion for the specific rule ID within the REQUEST-931 group
D) Replace the OWASP 3.2 ruleset with DRS 2.1, which doesn't include the REQUEST-931 group by default
Question 3 — Multiple Choice
When configuring custom rules in a WAF policy on Application Gateway, an engineer needs to ensure that a geolocation-based blocking rule is evaluated before the OWASP managed ruleset rules. How does evaluation priority work in this context?
A) Managed ruleset rules are always evaluated first, regardless of the priority configured in custom rules
B) Custom rules are evaluated before managed ruleset rules, and within custom rules evaluation follows ascending numerical priority order
C) The evaluation order between custom rules and managed ruleset is configured by a separate parameter called EvaluationOrder in the WAF policy
D) Custom rules and managed ruleset rules are evaluated in parallel, and in case of conflict the most restrictive action prevails
Question 4 — Technical Scenario
A company uses a WAF on Application Gateway with the following custom rule configured:
{
"name": "BlockScanners",
"priority": 10,
"ruleType": "MatchRule",
"matchConditions": [
{
"matchVariables": [{ "variableName": "RequestHeaders", "selector": "User-Agent" }],
"operator": "Contains",
"matchValues": ["Nmap", "Nikto", "sqlmap"]
}
],
"action": "Block"
}
After deploying the rule, the team notices that requests with the header User-Agent: Mozilla/5.0 (compatible; Nikto/2.1.6) are not being blocked. The rest of the WAF configuration is correct and functional.
What is the most likely cause?
A) The Contains operator is not supported for the RequestHeaders match variable in Application Gateway WAF
B) The rule is configured with priority 10, which is reserved by the system for internal managed ruleset rules
C) The WAF is in Detection mode, logging the match without executing the actual blocking
D) The matchValues field doesn't accept multiple values in a single condition; each value requires a separate condition
Question 5 — True or False
In Application Gateway WAF, an exclusion rule configured without specifying a field selector applies the exclusion to all values of the chosen variable type, such as all headers or all query string parameters, for the indicated rules.
True or False?
Answer Key and Explanations
Answer Key — Question 1
Answer: C
The OWASP 3.2 ruleset is the latest version of the OWASP set available in Application Gateway and includes significant precision improvements in detection compared to 3.0 and 3.1, with refined rules to reduce false positives. OWASP 2.2.9 is a legacy version with lower coverage. The Microsoft Default Ruleset (DRS) is a complementary set to OWASP, not a replacement, and focuses on mitigating specific Azure platform threats, such as attacks on managed services. Confusing DRS with a complete OWASP replacement is a common design mistake.
Answer Key — Question 2
Answer: C
Creating an individual rule exclusion by specific ID within the group allows suppressing exactly the rule responsible for the false positive without affecting any other ruleset protection. Disabling the entire REQUEST-931 group removes all protections against Remote File Inclusion, unnecessarily expanding the attack surface. Changing to Detection affects the entire policy, not just the problematic rule. DRS 2.1 has different scope and structure from OWASP, and switching the entire ruleset to work around one rule is a disproportionate and high-risk decision.
Answer Key — Question 3
Answer: B
In Application Gateway WAF, custom rules are always evaluated before managed ruleset rules. Within the set of custom rules, evaluation follows ascending numerical priority, meaning the lower number is evaluated first. There is no separate parameter called EvaluationOrder to control the relationship between custom rules and managed ruleset. Rules are not evaluated in parallel; the model is sequential with stopping at the first blocking or allowing match. Assuming that managed ruleset has precedence leads to design errors where custom blocking rules never get evaluated.
Answer Key — Question 4
Answer: C
The action: Block field in the custom rule only executes actual blocking when the WAF is in Prevention mode. In Detection mode, all actions configured as Block are downgraded to Detect, and traffic passes normally while the event is logged. The rule itself is syntactically correct: the Contains operator is supported for RequestHeaders, multiple values are allowed in a single matchValues, and priority 10 is not system-reserved. Correct diagnosis requires checking the policy mode before inspecting rule logic.
Answer Key — Question 5
Answer: True
When an exclusion is configured without a selector (without specifying a field value like a specific header name or parameter), it applies to all values of the chosen variable. For example, an exclusion on RequestHeaderNames without selector ignores all incoming headers for the indicated rules. This behavior is functionally equivalent to disabling inspection of that data type for affected rules, which can represent a significant security gap if used imprecisely. Selector granularity is exactly the mechanism that enables surgical exclusions instead of broad exclusions.