AZ-500 Secure networking Practice Question

A company uses Azure Front Door (AFD) with WAF policy in front of a web application. The security team notices that some requests from a specific IP range are being blocked incorrectly. The WAF policy uses custom rules. The team wants to allow a specific IP range while still having the WAF inspect other traffic. What is the most efficient way to configure this?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create a custom rule with priority 1, action 'Allow', and match condition for the source IP range.

The correct option is B: create a custom rule with priority 1, action 'Allow', and a match condition for the source IP range. In Azure Front Door WAF, custom rules are evaluated in priority order (lower numbers first), and an Allow rule matched early short-circuits the remaining WAF evaluation, so the trusted IP range bypasses blocking while all other traffic continues to be inspected by the managed and custom rules. Option A is wrong because a Block rule for that IP range would continue blocking the traffic the team wants to permit. Option C is wrong because a rate-limit rule controls request volume, not allow-listing, and would not reliably exempt the range from other WAF blocks. Option D is wrong because managed rule sets cannot be selectively disabled per IP range via a geo-match condition; exclusions apply to specific rule/request attributes, not source IP ranges in that manner.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Add a custom rule with priority 100, action 'Block', and match condition for the IP range.
Why it's wrong here
A custom rule with priority 100 and action 'Block' would reject requests, not exempt them. Because priority values determine evaluation order (lower number = higher priority), this rule would be evaluated after an existing priority-1 rule, and even if it matched before the managed rules, it would effectively deny all traffic from that IP range rather than allow it to bypass the WAF.
✓
Create a custom rule with priority 1, action 'Allow', and match condition for the source IP range.
Why this is correct
This works because WAF custom rules are processed in ascending priority order, where priority 1 is the highest precedence. An Allow action stops further evaluation of the policy, so any request that matches the source IP range will be permitted to reach the backend without being checked against managed rule sets. This is the standard whitelisting technique for trusted IPs that trigger false positives.
✗
Add a rate limit rule that allows traffic from the IP range.
Why it's wrong here
A rate limit rule with action 'Allow' does not create an unconditional bypass; it still tracks request counts per time window and will block clients that exceed the configured threshold. Rate limiting is designed to cap request volume, not to cherry-pick trusted traffic away from managed rules, and it is evaluated with the same custom-rule priority semantics rather than as an exclusion.
✗
Disable the managed rule sets for the specific IP range using a geo-match condition.
Why it's wrong here
Managed rule sets are evaluated against every request that is not already allowed by a custom rule; they have no per-IP enable/disable switch. A geo-match condition is a custom-rule match variable that checks the geographic location of the request, so it cannot be used to scope managed rules, and managed rule sets themselves do not accept geo-match conditions. To exclude a source IP, you must define a custom Allow rule with a higher priority than the managed evaluation.

Go deeper

AZ-500 Secure networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question