NSE4 Security Profiles 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.

• ✓

  Check if the users are using HTTPS and if the SSL inspection profile has an exemption for Facebook

  Why this is correct

  When users connect to Facebook over HTTPS, FortiGate must decrypt the TLS session (or at least inspect the Server Name Indication) to determine the destination domain and apply URL category filtering. If the SSL inspection profile configured on the policy includes a certificate exemption for Facebook (often added to avoid certificate pinning errors or breakage), the firewall skips decryption entirely and cannot see the SNI or the full URL. As a result, the web filter is effectively blind to the HTTPS session, and the Social Networking category is never matched, allowing the traffic even though the profile is set to Block.

• ✗

  Ensure that the antivirus profile is enabled on the policy

  Why it's wrong here

  An antivirus profile is responsible for scanning files and message bodies for malware signatures; it does not inspect or categorize URLs. Even if the antivirus profile is disabled on the policy, the web filter will still evaluate the requested URL against the configured Social Networking category and block Facebook when the action is Block. Enabling antivirus has no bearing on the symptom, so it is not one of the three most likely causes for this issue.

• ✓

  Check if the users are accessing Facebook via an SSL VPN tunnel that bypasses the policy

  Why this is correct

  If users access Facebook through an SSL VPN tunnel (for example, via FortiClient or a web portal), the encapsulated traffic arrives on the SSL VPN virtual interface and is decapsulated there. Unless the firewall policy for that tunnel interface explicitly applies the same web filtering profile, or the internal LAN policy’s inspection is overridden by the tunnel path, the decrypted (or still-encrypted) HTTPS traffic can be forwarded directly to the internet without being evaluated against the Social Networking category. This is a plausible cause because administrators often apply web filters only to LAN-to-WAN policies and forget that SSL VPN traffic may take a separate policy path.

• ✓

  Verify that the web filtering profile is applied to the correct policy and that the policy order is correct

  Why this is correct

  FortiGate firewall policies are evaluated in order, and the first policy that matches the traffic dictates both the action and which security profiles (including web filtering) are applied. If the web filtering profile is attached to a policy that appears later in the policy list, an earlier policy with an 'accept' action and no web filter will match first and allow the user traffic unfiltered. Additionally, if the profile is applied to the wrong interface pair (for instance, a LAN-to-DMZ policy instead of the LAN-to-WAN policy), the user's internet-bound traffic will never be evaluated, so Facebook remains accessible.

• ✗

  Confirm that the 'Social Networking' category is not set to 'Monitor' instead of 'Block'

  Why it's wrong here

  The administrator has explicitly set the Social Networking category to Block in the profile, so rechecking the dropdown would only confirm an action that is already correct. Even if a group override or a custom category redefined the action, the field value shown would reflect that, and merely verifying it does not address the root cause when the symptom is that Facebook is still accessible. This is a reasonable sanity check, but it is not one of the three most likely causes because the configuration already matches the intended blocking action.

Go deeper

Related to this question