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.

• ✗

  Apply the shaper to both policies and use a different shaper for Policy B

  Why it's wrong here

  Applying the shaper to both firewall policies and then using a different shaper for Policy B is a description of the desired outcome, not a specific configuration action. On a FortiGate, each policy has its own Traffic Shaping settings, so you would have to separately select the same shaper on Policy A and the different shaper on Policy B. This approach also unnecessarily shapes Policy A, which may not be required by the question, and it does not explain how to create and bind a new shaper to one policy.

• ✗

  Use a QoS queue on the outgoing interface

  Why it's wrong here

  A QoS queue on the outgoing interface operates at Layer 2 and treats all traffic egressing that interface uniformly based on queue settings, not on firewall policy attributes. FortiGate interface QoS queues use interface queues, 802.1p priorities, or DSCP values, but they cannot match the source or destination of a specific firewall policy. Therefore, using a QoS queue would shape all HTTP traffic on the interface, including Policy A, and cannot isolate Policy B for the desired shaping.

• ✓

  Create a traffic shaping policy that matches Policy B's source and apply the shaper

  Why this is correct

  A traffic shaping policy (under Firewall Objects > Traffic Shapers or Policy & Objects > Traffic Shaping Policies) allows you to create a separate rule that matches traffic based on source and destination addresses, services, and even the firewall policy. By configuring a shaping policy that matches Policy B's source address and applying the desired shaper to it, you can shape exactly the traffic permitted by Policy B without modifying Policy A. This is a valid alternative to per-policy shaper assignment and is useful when you need to shape traffic across multiple policies or when the shaper should apply to both forward and reverse directions.

• ✗

  Enable traffic shaping on the VDOM

  Why it's wrong here

  Enabling traffic shaping on the VDOM is a global prerequisite — you must also enable traffic shaping in the system global settings and per VDOM — but it only turns on the feature engine. Simply enabling it does not create a shaper, nor does it associate any shaper with Policy B; you still need to define a traffic shaper and either assign it directly to Policy B or add a traffic shaping policy. Thus, this option is necessary but not sufficient, and it is not the specific action that applies a shaper to Policy B.

• ✓

  Configure a traffic shaper and apply it directly to Policy B in the firewall policy settings

  Why this is correct

  The most direct and commonly used method is to create a traffic shaper (for example, a shared shaper with guaranteed and maximum bandwidth settings) and then edit Policy B's firewall policy settings. In the policy configuration, under the 'Traffic Shaping' section, you can select that shaper for egress and/or ingress traffic. Because the shaper is assigned within Policy B, it applies only to the HTTP traffic matching that policy, leaving Policy A unaffected. This is a straightforward per-policy shaper binding.

Go deeper

Related to this question