AZ-500 Secure networking Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  A narrowly scoped WAF exclusion for the affected variable or rule

  Why this is correct

  A narrowly scoped WAF exclusion is the correct approach because it creates a targeted exception for a specific rule or rule set and specific request attribute (such as a header, cookie, or query string parameter) that is causing the false positive. This preserves deep inspection and blocking across all other traffic, ensuring the WAF still mitigates real attacks while allowing the legitimate request to pass. Microsoft's documentation recommends precisely this kind of exclusion to reduce false positives without weakening the overall security posture.

• ✗

  Disable WAF prevention mode for the entire gateway

  Why it's wrong here

  Disabling WAF prevention mode for the entire gateway is wrong because it flips the WAF from prevention mode (where malicious requests are blocked) to detection mode (where they are only logged), or in some configurations disables the WAF entirely. That would eliminate the false positive for every request, but it also allows all genuinely malicious traffic through untouched, defeating the purpose of having a web application firewall. A global mode change is a blunt instrument that forfeits protection everywhere, whereas a scoped exclusion only removes the specific rule that misfires.

• ✗

  Remove TLS from the listener

  Why it's wrong here

  Removing TLS from the listener is an incorrect fix because the false positive originates in the WAF rule inspection of application-layer content, not in the encryption itself. WAF rules typically evaluate the decrypted HTTP payload after TLS termination, so disabling TLS does not stop the rule from matching and blocking the same request—it only transmits the data in cleartext, exposing sensitive information and potentially violating compliance requirements. Additionally, this change does not address the root cause and introduces a serious security downgrade for the entire application.

• ✗

  Move the application behind an internal load balancer only

  Why it's wrong here

  Moving the application behind an internal load balancer only is wrong because it alters the network architecture without resolving the WAF logic failure. The same request content sent by internal clients will still be inspected by the WAF and will still trigger the false positive, so the legitimate blocking continues. Furthermore, this action eliminates public access to the application, which may be an unacceptable business or functional requirement, and it does not provide the precise, policy-level adjustment needed to fix the misbehaving rule.

Go deeper

Related to this question