Technical Lab: Configure rule sets for WAF on Azure Front Door
Questions
Question 1 — Multiple Choice
A security team needs to ensure that the WAF on Azure Front Door always uses the latest available threat definitions for the OWASP managed ruleset. When reviewing the current configuration, the architect notices that the policy is using a ruleset with a fixed version. Which approach meets the requirement to keep definitions always updated without recurring manual intervention?
A) Manually update the ruleset to the latest OWASP CRS version whenever a new version is published by Microsoft
B) Replace the OWASP ruleset with a Microsoft_DefaultRuleSet type ruleset with automatic update enabled
C) Enable Prevention mode on the WAF, as this mode automatically applies ruleset updates without needing reconfiguration
D) Create an automation script via Azure Policy that recreates the WAF policy monthly with the latest ruleset version
Question 2 — Technical Scenario
An engineer is configuring a WAF policy on Azure Front Door and needs to block requests containing a specific HTTP header with a suspicious value, a behavior that is not covered by the active managed ruleset. The current configuration is:
Managed Ruleset: Microsoft_DefaultRuleSet 2.1
WAF Mode: Prevention
Custom Rules: none
What is the correct approach to implement this blocking?
A) Add an exclusion to the managed ruleset so it evaluates the HTTP header in question with additional rules
B) Create a Custom Rule with a match condition on the HTTP header field and Block action
C) Change the managed ruleset to OWASP CRS 3.2, which has native coverage for suspicious HTTP headers
D) Configure an origin rule in the Front Door profile to reject requests with this header before they reach the WAF
Question 3 — Multiple Choice
When configuring a WAF policy on Azure Front Door, an architect needs to disable a specific rule from the managed ruleset that is causing false positives on a critical application route, but without affecting the behavior of other routes protected by the same Front Door profile. Which feature allows this level of granularity?
A) Create a second WAF policy without the problematic rule and associate it to the Front Door profile replacing the current policy
B) Use rule exclusions at the WAF policy level to disable the specific rule on all profile routes
C) Associate different WAF policies to different endpoints or routes within the same Front Door profile
D) Configure Detection mode only for the problematic rule, keeping the others in Prevention mode
Question 4 — Technical Scenario
An organization operates Azure Front Door with WAF in Prevention mode using the Microsoft_DefaultRuleSet 2.1 ruleset. The development team reports that a specific API starts receiving HTTP 403 errors after an application update. WAF logs show the following pattern:
RuleId: 942100
Action: Block
MatchVariable: RequestBody
MatchValue: SELECT * FROM users
The team confirms that the request is legitimate and that the value is part of a text search payload sent by users. What is the most appropriate solution with the least impact on security posture?
A) Completely disable rule 942100 in the WAF policy for all requests in the profile
B) Change the WAF to Detection mode so requests are no longer blocked
C) Configure an exclusion on rule 942100 for the RequestBody field only on the affected API path
D) Create a Custom Rule with priority 1 that allows all requests destined for the API path
Question 5 — True or False
In Azure Front Door, a WAF policy can simultaneously have an active managed ruleset and multiple configured Custom Rules, and Custom Rules are always evaluated before managed ruleset rules, regardless of the action defined in the Custom Rules.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
The Microsoft_DefaultRuleSet is available in versions with automatic update support in Azure Front Door. By selecting this ruleset with the automatic update option, Microsoft applies new versions in a managed way, eliminating the need for manual intervention. This behavior is specific to Front Door and is not available in the same way in Application Gateway.
The other distractors represent common misconceptions: Prevention mode (option C) controls blocking behavior, not ruleset updates. Scripts via Azure Policy (option D) add unnecessary operational complexity when the native feature already solves the problem. Manual update (option A) meets the requirement functionally but contradicts the requirement to eliminate recurring manual intervention.
Answer Key — Question 2
Answer: B
Custom Rules are the correct mechanism to implement blocking logic based on specific criteria that the managed ruleset doesn't cover. They allow defining conditions on any HTTP request component, including headers, with Block, Allow, Log, or Redirect actions.
Exclusions (option A) serve to exempt parts of the request from evaluation by existing rules, not to add new evaluation rules. Changing the managed ruleset (option C) doesn't solve the problem because no standard managed ruleset handles application-specific custom headers. Origin rules in the Front Door profile (option D) don't have layer 7 HTTP content inspection capability with the described granularity.
Answer Key — Question 3
Answer: C
In Azure Front Door (Standard or Premium profile), it's possible to associate different WAF policies to different routes within the same profile, allowing each route to have its own policy with independent configurations. This enables disabling a problematic rule only on the affected route without impacting the others.
Replacing the entire policy (option A) would resolve the false positive but would remove the rule globally, affecting all routes. Policy-level exclusions (option B) also apply globally to all routes associated with that policy. Detection mode per individual rule (option D) is not an available feature; Detection mode is applied to the entire policy, not individual rules.
Answer Key — Question 4
Answer: C
Configuring an exclusion for rule 942100 specifically on the RequestBody field and restricted to the affected API path is the approach with the least impact on security posture. Exclusions in Front Door WAF allow defining the exact scope (match variable, operator, and selector) so that only the legitimate context is exempted from evaluation, keeping the rule active for all other scenarios.
Completely disabling the rule (option A) removes SQL Injection protection for all profile requests. Changing to Detection (option B) disables blocking of all attacks, not just the false positive. Creating an Allow Custom Rule with priority 1 (option D) is overly broad and may allow genuinely malicious requests directed to the same path.
Answer Key — Question 5
Answer: True
In Azure Front Door, the WAF evaluation engine always processes Custom Rules before managed ruleset rules. This order is fixed and independent of the action type defined in the Custom Rule (Block, Allow, Log, or Redirect). This characteristic is fundamental for policy design: an Allow Custom Rule with appropriate priority can be used to exempt trusted traffic before it's evaluated by the managed ruleset, avoiding false positives in a controlled manner. Understanding this evaluation order is essential for designing policies that correctly combine the two mechanisms without unexpected behaviors.