NSE4 Firewall Policies and NAT 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.

• ✗

  Policy 3

  Why it's wrong here

  Policy 3 is not reached because FortiGate evaluates firewall policies sequentially from the top of the policy list and stops at the first matching policy. Since policy 1 already matches the traffic (source within 10.0.0.0/8 and destination any), policy 3, regardless of its own criteria, is never examined. The implicit ordering for a given interface pair is fixed by policy ID, and later policies only matter if no earlier one matched. Thus policy 3 cannot be the effective policy for this session.

• ✓

  Policy 1

  Why this is correct

  Policy 1 is correct because FortiGate uses a first-match model: it scans the policy list top-down and applies the first policy whose source, destination, and services match the packet. The source address in the traffic is within the 10.0.0.0/8 address range and the destination is any, so policy 1 matches all conditions for this session. Even though policy 2 may be more specific, it is placed after policy 1 and is therefore shadowed; the firewall never evaluates it for this traffic. Therefore policy 1's action (permit or deny) is what the audit should record.

• ✗

  Implicit deny

  Why it's wrong here

  The implicit deny rule is a default action that applies only when no explicit firewall policy matches the traffic. In this scenario, policy 1 explicitly matches the source and destination, so the firewall applies policy 1 immediately and never falls through to the implicit deny. FortiGate's implicit deny is not a policy entry in the list; it is the final catch-all when the traversal of all explicit policies fails to find a match. Because an explicit match exists, the implicit deny cannot be the result.

• ✗

  Policy 2

  Why it's wrong here

  Policy 2 does not become the effective policy because FortiGate does not use a best-match algorithm; it uses the first matching policy in the order configured. Even if policy 2 has more specific source or destination objects that exactly match the session, policy 1 appears earlier and matches the same traffic with a broader source range. This earlier match stops the lookup, so policy 2's more specific definitions are never considered. In security audits, such shadowed policies can be identified as redundant or misordered, but they do not influence this traffic.

Go deeper

Related to this question