Technical Lab: Associate a WAF policy
Questions
Question 1 — Multiple Choice
A team needs to associate an existing WAF policy with an Azure Application Gateway. When trying to perform the association through the Azure portal, the policy doesn't appear as an available option. The Application Gateway is in the East US region and was provisioned in the WAF_v2 tier. What is the most likely cause for the policy not being available for selection?
A) The WAF policy was created for Azure Front Door and is not compatible with Application Gateway, regardless of region
B) The Application Gateway is in the WAF_v2 tier, which requires the policy to be created with the Regional type and in the same region as the gateway
C) The WAF policy can only be associated during the creation of the Application Gateway, and cannot be associated with an existing resource
D) The WAF policy needs to be in the Prevention state before being associated with any Azure resource
Question 2 — Technical Scenario
An architect associated a WAF policy with an Azure Application Gateway with two configured listeners: one for public traffic and another for internal traffic. After the association, the architect realizes they need to apply different rules for each listener, as internal traffic has different patterns that generate false positives in the managed ruleset rules. The current configuration is:
Application Gateway Tier: WAF_v2
WAF Policy: policy-global (associated with the gateway)
Listeners: listener-public, listener-internal
Per-site policy: not configured
Which approach resolves the requirement without replacing the global policy?
A) Create a second WAF policy and associate it directly with the listener-internal, replacing the global policy only for that listener
B) Add rule exclusions in the global policy so they apply only to the internal listener based on source IP
C) Create custom HTTP rules in the Application Gateway that redirect internal traffic to a backend without WAF
D) Change the Application Gateway tier to Standard_v2 on the internal listener to disable WAF inspection on that path
Question 3 — True or False
In Azure Front Door, a WAF policy can be associated simultaneously with multiple Front Door profiles belonging to different subscriptions, as long as the subscriptions are in the same Microsoft Entra ID tenant.
Question 4 — Technical Scenario
An organization has an Azure Front Door (Standard profile) with three configured routes. The security team creates a new WAF policy and tries to associate it with one of the routes through the Azure portal, but the option to associate with individual routes is not available. What is the most likely cause?
A) WAF policies for Front Door can only be associated via Azure CLI or Azure PowerShell, not through the Azure portal
B) The Front Door profile is in the Standard tier, which doesn't support associating WAF policies; an upgrade to the Premium tier is required
C) The WAF policy was created in Detection mode, and associations with individual routes require the policy to be in Prevention mode
D) The WAF policy is in a different region from the Front Door profile, preventing the association
Question 5 — Multiple Choice
A company has an Azure Application Gateway WAF_v2 with a WAF policy associated at the gateway level. The team decides to also associate a specific WAF policy to an individual request routing rule. What is the resulting behavior for traffic processed by that routing rule?
A) Both policies are evaluated in parallel and the most restrictive action between them is applied to the request
B) The policy associated with the individual routing rule takes precedence over the gateway policy for traffic covered by that rule
C) The gateway policy always takes precedence, and the individual routing rule policy is ignored when there's a conflict
D) Associating a policy to an individual routing rule is invalid when a policy already exists at the gateway level; the portal returns an error
Answer Key and Explanations
Answer Key — Question 1
Answer: A
WAF policies are typed objects at creation time. A policy created with the Front Door type (FrontDoorWebApplicationFirewallPolicy) is incompatible with Application Gateway, and vice versa. This distinction is fundamental: the two resources use completely different policy types in the Azure control plane, and no subsequent configuration can change the type of an existing policy.
The other distractors explore plausible misconceptions: regional restriction (option B) is real for Application Gateway, but isn't the cause described in the scenario; post-creation association (option C) is perfectly supported; policy mode (option D) doesn't affect association eligibility. The consequence of not understanding this distinction is attempting to reuse policies between incompatible resources, which will always result in failure.
Answer Key — Question 2
Answer: A
Application Gateway WAF_v2 supports per-site policies, which allow associating different WAF policies to individual listeners. When a policy is associated directly with a listener, it replaces the global policy only for that listener's traffic, keeping the global policy active for others. This hierarchical model is the correct mechanism for the described scenario.
Exclusions in the global policy (option B) apply to all requests evaluated by it, without the ability to filter by listener. Redirecting to a backend without WAF (option C) completely removes protection for internal traffic, violating security best practices. Changing the listener tier (option D) is not possible; tier is a property of the entire Application Gateway, not individual listeners.
Answer Key — Question 3
Answer: False
A WAF policy in Azure Front Door can only be associated with profiles within the same subscription where the policy was created. The scope of a WAF policy is limited to the subscription, regardless of the Microsoft Entra ID tenant. Shared tenants between subscriptions don't expand the scope of WAF policy association. This limitation is relevant in multi-subscription architectures, where each subscription using Front Door needs its own locally defined WAF policy.
Answer Key — Question 4
Answer: B
Associating WAF policies with individual routes in Azure Front Door is a feature available only in the Premium tier. The Standard tier supports WAF, but only with association at the endpoint level, without per-route granularity. To obtain per-route control, upgrading the profile to the Premium tier is required.
Portal restriction (option A) is false; association can be done through both portal and CLI. Policy mode (option C) doesn't affect association functionality availability. Region (option D) is not a relevant criterion for Front Door, which is a global service without regional policy binding.
Answer Key — Question 5
Answer: B
In Application Gateway WAF_v2, policy hierarchy follows the principle that the most specific policy takes precedence. A policy associated with an individual routing rule (per-rule policy) takes precedence over the policy associated with the gateway for traffic covered by that rule. This allows fine-tuned protection without altering the global policy, keeping the security posture of other routes intact.
Parallel evaluation with application of the most restrictive action (option A) doesn't reflect actual behavior; only one policy is applied per request. Global policy always taking precedence (option C) inverts the correct hierarchy. Option D is incorrect because multi-level association is explicitly supported and documented by Microsoft as a WAF_v2 feature.