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.

• ✗

  Add a custom rule to block all requests that do not match a known pattern.

  Why it's wrong here

  A custom rule that blocks all requests not matching a known pattern implements a positive security model (allowlist), but it is brittle: the WAF will reject any legitimate request whose URI, header, or body does not conform to the exact pattern, including benign variations such as altered user agents, cache busters, or Unicode encodings. In Application Gateway v2, custom rules are evaluated top-down, so a broad block rule would stop otherwise valid traffic before the managed rule sets can be assessed, and maintaining an exhaustive pattern list becomes operationally unsustainable in a real application.

• ✓

  Use managed rule sets with custom rules to allow the legitimate traffic that is being falsely blocked.

  Why this is correct

  Managed rule sets (for example, OWASP 3.2) can produce false positives when a benign request carries content that looks like SQL injection or cross-site scripting. Because custom rules are evaluated before managed rules in Application Gateway v2, a custom rule with action Allow can explicitly whitelist the legitimate traffic by matching on specific attributes such as URI path, headers, source IP, or query string values; the Allow action stops further evaluation, so the managed rule's Block action is not applied to that request. This lets you keep managed protection active while surgically correcting false positives.

• ✗

  Disable the WAF and rely on NSGs.

  Why it's wrong here

  Disabling the WAF and relying on NSGs is a regression in the security model: NSGs operate at the network layer (L3/L4) and filter packets based on source/destination IP, port, and protocol, so they cannot inspect HTTP request payloads, enforce signature matches, or block SQL injection, cross-site scripting, or bot traffic. An Application Gateway v2 WAF runs inside the gateway during request processing, giving application-layer visibility that NSGs simply do not possess; turning off WAF removes that layer and leaves the web application directly exposed to OWASP Top 10 threats.

• ✗

  Switch the WAF policy to detection mode.

  Why it's wrong here

  Switching the WAF policy from Prevention mode to Detection mode changes the action for every managed rule from Block to Log, meaning the gateway will forward malicious requests to the backend despite detecting them. This does not fix a false positive; it masks the problem by stopping all blocking, so the application remains vulnerable while the logs grow. Correctly resolving false positives should be done with a targeted Allow custom rule or exclusions, not by globally removing the protective action.

Go deeper

Related to this question