Technical Lab: Implement a WAF policy
Questions
Question 1 — Multiple Choice
A team needs to protect two distinct resources: an Azure Application Gateway serving an internal web application and an Azure Front Door distributing a global application to external users. Both require independent WAF policies with different custom rules. Which statement correctly describes the relationship between WAF Policies and these resources?
A) A single WAF Policy can be simultaneously associated with an Application Gateway and a Front Door, as long as they are in the same resource group
B) WAF Policies for Application Gateway and for Front Door are distinct types and are not interchangeable; each resource requires a policy of the corresponding type
C) WAF Policies are global by default and automatically apply to all application delivery resources in the subscription
D) It's possible to use the same WAF Policy on both resources, as long as the Application Gateway SKU is WAF_v2 and the Front Door is Premium tier
Question 2 — Technical Scenario
An administrator created a WAF Policy for an Azure Application Gateway WAF_v2 and added a custom rule with the following configuration:
Name: BlockBadBot
Priority: 10
Match Type: RequestHeaders
Header: User-Agent
Operator: Contains
Value: BadBot
Action: Block
After associating the policy with the Application Gateway, the administrator notices that requests with User-Agent BadBot/2.0 are still reaching the backend. The WAF is in Prevention mode. What is the most likely cause?
A) Custom rules with Block action are not supported in Prevention mode; they only work in Detection mode
B) The WAF Policy was created but not associated with a specific listener or with the Application Gateway as a whole, remaining without effect
C) The Contains operator is not valid for header matching; the correct one would be Equals
D) Priority 10 is reserved for OWASP managed rules and cannot be used by custom rules
Question 3 — Multiple Choice
When implementing a WAF Policy on Azure Front Door Premium, an architect needs to protect endpoints from different clients with distinct rule sets. Each client has their own custom domain associated with Front Door. What is the supported association granularity for Azure Front Door when linking WAF Policies?
A) The WAF Policy is associated with the Front Door profile as a whole, applying equally to all domains and routes
B) The WAF Policy can be individually associated with each security policy, which in turn is linked to specific domains and routes within the profile
C) The WAF Policy is directly associated with the origin group, filtering traffic before it is sent to the backend
D) Each WAF Policy is associated with a routing rule (route rule), allowing control by URL path but not by domain
Question 4 — True or False
In a WAF Policy associated with an Azure Application Gateway, custom rules are always evaluated before the managed rules from the OWASP rule set, regardless of the priority value defined in the custom rule.
Question 5 — Technical Scenario
A company implemented a WAF Policy on Azure Front Door Premium with the DRS 2.0 managed rule set active. After deployment, the development team reports that legitimate requests from a partner are being blocked. Log investigation reveals:
RuleSetType: Microsoft_DefaultRuleSet
RuleSetVersion: 2.0
RuleId: 920300
Action: Block
Details: Request Missing an Accept Header
RequestUri: /api/v2/data
The partner confirmed that their legacy system does not send the Accept header in requests. The company needs to resolve the blocking only for this endpoint, without globally disabling the rule. What is the correct approach?
A) Create a custom rule with lower priority than all managed rules to explicitly allow the /api/v2/data path before DRS evaluation
B) Configure a rule exclusion in the WAF Policy, limiting the exclusion of RuleId 920300 to the /api/v2/data request path
C) Disable the DRS 2.0 rule set and manually recreate all necessary rules, omitting only 920300
D) Associate a second WAF Policy without DRS 2.0 to the partner's domain, keeping the original policy on other domains
Answer Key and Explanations
Answer Key — Question 1
Answer: B
WAF Policies are created with a specific resource scope: Regional (for Application Gateway and Azure CDN) or Global (for Azure Front Door). A policy created for Application Gateway cannot be associated with Front Door and vice versa, as the resource types and configuration models are incompatible. This distinction is structural, not configurable.
Alternative A is incorrect because the restriction is not about resource groups, but about policy types. Alternative C describes behavior that doesn't exist: WAF Policies are never applied automatically. Alternative D is the most dangerous distractor, as it mixes correct SKUs with a false premise: even with adequate SKUs, policy types remain incompatible with each other.
Answer Key — Question 2
Answer: B
In Azure Application Gateway, creating a WAF Policy and associating it with the resource are two distinct operations. A policy that is created but not associated with a listener or the gateway as a whole remains inactive, without evaluating any traffic, regardless of the configured mode. This is one of the most common operational errors in WAF Policy implementation.
Alternative A is technically incorrect: custom rules with Block action work fully in Prevention mode. Alternative C is false: Contains is a valid and widely used operator for header matching. Alternative D is a plausible distractor, but priority in custom rules is a user-defined value to order evaluation among custom rules themselves; there is no reserved range for managed rules.
Answer Key — Question 3
Answer: B
In Azure Front Door Premium, WAF Policy association is done through security policies. A security policy links a WAF Policy to a specific set of domains and routes within the profile, allowing different client domains to receive distinct policies. This granularity is the correct mechanism for the described scenario.
Alternative A describes a global association model that doesn't reflect the current Front Door Premium architecture. Alternative C is incorrect: association with origin groups doesn't exist as a WAF mechanism; origin groups represent backends, not traffic entry points. Alternative D is partially plausible, but association by route alone doesn't allow discrimination by domain, which is the central requirement of the scenario.
Answer Key — Question 4
Answer: True
The evaluation order in an Application Gateway WAF Policy is deterministic: custom rules are always evaluated before managed rules, regardless of the assigned priority value. The priority field in custom rules only defines the evaluation order among custom rules themselves, not their position relative to the managed set.
This characteristic is relevant because it allows custom Allow or Block rules to act as exceptions or early blocks before the OWASP engine processes the request. Ignoring this order can lead to unexpected behaviors, such as a custom Allow rule that is never reached because the administrator assumes OWASP evaluates first.
Answer Key — Question 5
Answer: B
Rule exclusion is the mechanism designed exactly for this scenario: disabling the evaluation of a specific managed rule for a subset of requests, without affecting the global behavior of the policy. It's possible to scope the exclusion by request path, header, cookie, or query string parameter, making the solution precise and surgical.
Alternative A is a common misconception: custom Allow rules evaluated before DRS can bypass managed rules for that traffic, but this approach is more fragile, requires greater maintenance, and is not the recommended mechanism for false positives in managed rules. Alternative C is disproportionate and eliminates all managed protection. Alternative D would be technically viable if Front Door Premium supported associating distinct policies by domain, which it does, making this alternative plausible. However, it's more complex and introduces unnecessary operational overhead when rule exclusion solves the problem directly and is maintained in a single policy.