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.

• ✓

  Create two firewall policies, one for each subnet

  Why this is correct

  Two firewall policies are required because policy-based NAT binds the source translation directly to the policy entry. Since each subnet must egress with a different public IP pool, a separate policy for each subnet allows the FortiGate to select the correct pool based on the source address. This creates a clean one-to-one mapping of source subnet to NAT pool, with no reliance on routing or additional match conditions.

• ✓

  In each policy, enable NAT and select the corresponding IP pool

  Why this is correct

  Simply creating the policies is not enough; the NAT action and IP pool must be explicitly assigned within each policy. When NAT is enabled and an IP pool is selected, the FortiGate translates all matching source addresses to addresses from that pool. This configuration step ties the source subnet to its specific public range, ensuring traffic from different subnets is source-NATed differently.

• ✗

  Configure a single firewall policy with both subnets in the source address group

  Why it's wrong here

  A single firewall policy can reference only one IP pool for source NAT. If both subnets are grouped into one source address object, the policy loses the ability to distinguish which subnet should receive which public address. The FortiGate would apply the same single IP pool to all traffic, breaking the requirement for subnet-specific translation. Policy-based NAT does not support conditional NAT based on individual members of a source address group.

• ✓

  Create two IP pool objects, POOL1 and POOL2

  Why this is correct

  IP pool objects define the usable public address ranges for SNAT, and each pool must exist as a separate object before it can be referenced. Creating POOL1 and POOL2 gives the administrator named containers for distinct public IP ranges. These objects are then selected inside the firewall policy's NAT settings, completing the connection between the private subnet and its allocated public translate addresses. Without separate pools, there would be nothing to point to.

• ✗

  Enable Central NAT and define two NAT policies

  Why it's wrong here

  Central NAT is an operational mode in which NAT rules are independent from firewall policies, usually managed via the Central NAT table. The question explicitly states the device is already using policy-based NAT, so switching to Central NAT would require changing the system's NAT mode and reworking the entire policy structure. Defining central NAT policies would not take effect while policy-based NAT is active, and it contradicts the given configuration. Therefore, it is not a valid solution for this scenario.

Go deeper

Related to this question