Free NSE7 SDW 7.2 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

In a dual-hub SD-WAN architecture, a spoke can dynamically switch the path for an existing session from one hub to another based on performance SLA changes. Each hub maintains a separate IPsec security association (SA) with the spoke. If IPsec anti-replay is enabled on the hubs, the second hub will drop packets for the failed-over session because their ESP sequence numbers will be outside its anti-replay window. This breaks the session. Disabling anti-replay on the hubs is therefore a mandatory step to prevent this check, ensuring that TCP sessions can survive the path change and fail over seamlessly between the two hubs.

A. Anti-replay is an IPsec ESP security feature to prevent replay attacks; it does not manage TCP packet reordering for end-host applications.

C. While disabling the check can yield a negligible performance gain, the primary and critical reason in this design is to enable session failover, not to improve performance.

D. The IPsec anti-replay setting is a Layer 3/4 function and is entirely separate from Layer 7 content inspection performed by security profiles.

1. Fortinet. (2022). SD-WAN for FortiOS 7.2 Study Guide. Page 100, "Dual hub (hub and spoke)" section. The guide states, "On both hubs, you must disable anti-replay in the phase 2 configuration for the ADVPN tunnel. This is required because traffic can switch between hubs, and the sequence number check will fail."

2. Fortinet. (2022). FortiOS 7.2.0 Administration Guide. In the "IPsec VPN" chapter, the description of phase 2 settings clarifies that anti-replay is an IPsec function to protect against the retransmission of packets. Its disablement is a known requirement for certain asymmetric routing scenarios, such as dual-hub SD-WAN.

3. Fortinet. (2022). FortiOS 7.2.0 CLI Reference. Volume 2, page 1738. The command set replay {enable | disable} under config vpn ipsec phase2-interface is documented as enabling or disabling IPsec SA replay detection, confirming it relates to the IPsec tunnel, not directly to TCP.

Study guide 7.2 Page 191

The traffic-shaping policy is matching YouTube by URL category.

FortiGate can only look up the URL category of a flow when the matching firewall policy is using a Web Filter profile; otherwise the IPS engine never performs the URL category query and the shaping policy is skipped. Enabling Web Filtering on the firewall policy therefore allows the URL‐category match (YouTube/Streaming Media) and the configured bandwidth limits are applied. (Application Control is not required for URL-category shaping.)

A. Destination Internet Service affects ISDB objects; the shaping rule is based on URL category, not ISDB, so enabling this has no effect on YouTube matching.

B. Application Control is unnecessary for URL-category-based shaping; the IPS engine already identifies applications even without an Application Control profile.

D. SD-WAN zones are supported in shaping policies; selecting individual members is optional and does not influence URL-category detection.

1. Fortinet, FortiOS 7.2 Administration Guide – “Traffic shaping policies: URL category‐based shaping requires that the corresponding firewall policy include a Web Filter profile” (Section 37.3.1, p. 1032).

2. Fortinet Knowledge Base, Article KB-FD50275 “Traffic shaping with URL category—Web Filter profile requirement”, para. 2.

3. Fortinet NSE7 SD-WAN 7.0 Courseware, Module “Advanced Traffic Shaping”, slide 18: “URL category match evaluated only when Web Filtering is enabled on the firewall rule.”

FortiGate's SD-WAN Performance SLA feature allows for sophisticated health checks that go beyond simple connectivity tests. For application-layer protocols like HTTP and DNS, the health check can be configured to validate the content of the server's response. An HTTP health check can be set to look for a specific string in the server's reply, confirming the web service is returning the expected content. Similarly, a DNS health check can be configured to verify that the DNS server's response contains a specific, expected IP address for the queried domain. This ensures the service is not only reachable but also functioning correctly.

B. icmp: ICMP (ping) health checks only confirm layer 3 reachability and measure round-trip time. They do not have the capability to inspect any application-layer data in a response.

C. twamp: TWAMP (Two-Way Active Measurement Protocol) is designed to measure network performance metrics like round-trip delay, jitter, and packet loss. It does not analyze application-layer server responses.

1. FortiOS 7.0.0 Administration Guide - SD-WAN:

In the section on Performance SLA, the guide details the configuration of different health check modes. For the HTTP mode, it describes the http-match option, which is used to "Enter a text string that should be present in the HTTP response from the server." For the DNS mode, it describes the dns-match-ip option, which is used to "Enter an IP address that the DNS server should return." (See chapter on "Performance SLA", section "Health Check").

2. FortiOS 7.0.0 CLI Reference:

Under config system sdwan -> config health-check, the parameters for different modes are listed.

For set mode http, the option set http-match is available to "Response string to match."

For set mode dns, the option set dns-match-ip is available to "DNS match IP."

The ping (ICMP) and twamp modes do not have equivalent parameters for matching response content. (See config health-check in the CLI reference).

Fortinet SD-WAN rules are used to match and steer traffic to the preferred SD-WAN member(s). The matching criteria are configured within the rule and can be based on standard network information as well as advanced application-aware parameters. The key available criteria include:

Source and Destination IP addresses: Standard Layer 3 identifiers for traffic matching.

Internet Service Database (ISDB): Allows matching traffic destined for well-known cloud applications and internet services (e.g., Microsoft 365, Google Services) without needing to manually maintain IP address lists.

Application Signatures: Utilizes Fortinet's Application Control database to identify and match traffic based on specific application signatures (e.g., Skype, Zoom, SAP).

These three criteria provide granular control for routing traffic based on its source, destination, and application type.

A. Type of physical link connection: This is a property of an SD-WAN member (the outgoing interface), not a criterion used to match incoming traffic within an SD-WAN rule.

D. URL categories: URL categories are part of a Web Filter security profile, which is applied within a firewall policy, not used as a direct matching criterion in an SD-WAN rule.

1. FortiOS 7.0.1 Administration Guide: In the "SD-WAN" chapter, the section on "SD-WAN rules" details the configuration options. The GUI and CLI descriptions for creating a rule explicitly show fields for Source, Destination, and Application. The Destination field includes options for Address and Internet Service. The Application field allows for selecting specific application signatures. (See section: SD-WAN > SD-WAN rules).

2. FortiOS 7.0.0 SD-WAN Deployment Guide: This guide provides examples of SD-WAN rule configuration. In the "Configuring SD-WAN rules for steering traffic" section, it demonstrates creating rules using Internet Service objects, Application Control signatures, and standard source/destination Address objects as the primary matching criteria. (See section: Use Cases > Office 365).

Before an interface can be added as a member of an SD-WAN zone, all existing configuration references to that interface must be removed. Exhibit B shows that port1 is explicitly used as the Outgoing Interface in firewall policy ID 1. This reference is a blocking condition that prevents port1 from being added to the SD-WAN zone. The firewall policy must be deleted and later recreated using the new SD-WAN zone as the outgoing interface.

A. port1 is assigned a manual IP address.

This is incorrect. Interfaces configured with static (manual) IP addresses can be added as SD-WAN members without issue; this is a common configuration method.

C. port2 is referenced in a static route.

This statement is also factually correct and represents another blocking issue. However, the question asks for an issue, and the firewall policy reference for port1 is a critical and equally valid blocking condition shown in the exhibits.

D. port1 and port2 are not administratively down.

This is incorrect. For an interface to be an active member of an SD-WAN zone and pass traffic, it must be administratively up.

1. FortiOS 7.2.0 Administration Guide:

In the "SD-WAN" section, under "Basic configuration," the guide states: "Interfaces cannot be assigned to SD-WAN if they are used in the FortiGate configuration, for example, in a policy or static route." This confirms that both firewall policy references (Option B) and static route references (Option C) are blocking conditions.

2. SD-WAN 7.2 Study Guide:

In the "SD-WAN Members" chapter, page 13, it is explicitly mentioned: "Before you can add an interface as an SD-WAN member, you must remove all references to it. This includes references in firewall policies, static routes, and DHCP." This supports the reasoning that the firewall policy reference shown in Exhibit B for port1 is a valid issue.

In Fortinet SD-WAN, the architecture is composed of an underlay and an overlay network. The underlay consists of the physical transport networks (e.g., MPLS, Internet). The overlay is a virtual network built on top of the underlay, using tunnels to connect SD-WAN locations. These tunnels are the "overlay links." FortiGate devices primarily use IPsec tunnels to create a secure, encrypted overlay fabric. Additionally, GRE (Generic Routing Encapsulation) tunnels can also be configured as SD-WAN members to function as overlay links, often used in scenarios requiring multicast traffic support over the SD-WAN.

A. LAG: A Link Aggregation Group (LAG) is an underlay technology that bundles multiple physical interfaces to increase bandwidth and provide redundancy. It is not an overlay tunnel.

C. Physical: A physical interface is a hardware port on the FortiGate that connects directly to the underlay network. It provides the transport path for the overlay, but is not the overlay link itself.

1. Fortinet FortiOS 7.0.2 SD-WAN Architecture for Enterprise Guide, Page 10, "Overlay and underlay networks". The document states, "The SD-WAN overlay is a virtual network built on top of underlay networks. The overlay consists of the tunnels that are established between the SD-WAN members." A diagram on the same page explicitly labels "IPsec Tunnels (Overlay)" running over "Underlay Networks".

2. Fortinet FortiOS 7.0.0 Administration Guide, "SD-WAN" chapter, "SD-WAN members" section. This section describes the interfaces that can be added as SD-WAN members. While it includes physical interfaces (for direct internet access), the context of inter-site connectivity, which defines the overlay, is achieved through tunnel interfaces like IPsec and GRE. The configuration examples for building the overlay consistently use IPsec tunnels.

3. Fortinet FortiOS 7.0.0 Cookbook, "Basic SD-WAN deployment" section. This guide demonstrates the standard procedure for building an SD-WAN overlay, which involves creating IPsec VPN tunnels between sites and then adding these tunnel interfaces as members to the SD-WAN interface. This confirms IPsec as a primary overlay link type.

FortiManager provides centralized SD-WAN management primarily through the use of SD-WAN templates. This is the core mechanism for defining and deploying consistent SD-WAN configurations across multiple FortiGate devices. A key feature within these templates is the support for normalized interfaces. This allows administrators to create a single template that works across different FortiGate hardware models by mapping device-specific physical interface names (e.g., port1, wan1) to a common logical name. This abstraction is crucial for scalable and heterogeneous deployments.

A. The objects are saved in the ADOM common object database.

While factually true, this describes a general architectural principle of FortiManager for all managed objects (like addresses or policies), not a feature specific to the SD-WAN central management process itself.

B. It does not support meta fields.

This is incorrect. Meta fields (variables) are a core feature in FortiManager provisioning and can be used in CLI templates to configure device-specific SD-WAN settings, such as member gateway IP addresses.

---

1. FortiManager Administration Guide 7.2.4, "SD-WAN templates".

Page 638, "SD-WAN templates" section: "You can use FortiManager to centrally create and manage SD-WAN templates and then assign the templates to supported devices." (Supports answer C).

Page 641, "SD-WAN members" section: "From the Interface dropdown, select a physical or normalized interface." (Supports answer D).

2. FortiManager Administration Guide 7.2.4, "Provisioning Templates".

Page 498, "About provisioning templates" section: This section details the use of meta fields (variables) to push unique, per-device configurations, which contradicts the claim in option B. For example, a CLI template can be used to set a unique gateway for an SD-WAN member using a meta field.

3. FortiManager Administration Guide 7.2.4, "Objects".

Page 318, "Policy & Objects" section: This section explains that objects are managed within the ADOM database. This confirms that statement A is generally true for FortiManager but does not make it a better answer than C or D, which are specific to the SD-WAN management feature set.

The traffic shaper configuration sets a Maximum Bandwidth of 50,000 Kbps. Traffic exceeding this rate will be dropped. Converting this to kilobytes per second (KBps) gives 50,000 / 8 = 6250 KBps, making option C correct.

The screenshot also displays real-time statistics, showing the Current Bandwidth is 789 Kbps. Converting this to KBps gives 789 / 8 = 98.625 KBps. This value is less than 100 KBps, which makes option B a correct observation based on the provided data.

A. The Guaranteed Bandwidth (2000 Kbps or 250 KBps) is a minimum reserved bandwidth, not a threshold for dropping packets. Packets are dropped for exceeding the maximum bandwidth, not for being below the guaranteed level.

D. The Per-IP Shaper setting is disabled. Therefore, the maximum bandwidth limit of 6250 KBps applies to the aggregate traffic matching the policy, not to each individual source IP address.

1. FortiOS 7.2.0 Administration Guide, Traffic Shaping > Traffic shapers, Page 1891.

Maximum Bandwidth: "The maximum bandwidth that the shaper will allow. If traffic exceeds this value, it will be dropped." This directly supports the reasoning for option C.

Guaranteed Bandwidth: "The minimum bandwidth that the shaper will guarantee to the traffic." This supports the refutation of option A.

Per-IP traffic shaping: "When enabled, the traffic shaper is applied to each IP address individually." As this is disabled in the exhibit, it confirms the reasoning for why option D is incorrect.

2. Fortinet NSE 7—SD-WAN 7.2 Study Guide, Traffic Shaping > Traffic Shapers, Page 215.

The guide explains that the maximum bandwidth setting in a traffic shaper defines the upper limit for traffic, and any packets that cause the rate to exceed this limit are dropped. This validates the correctness of option C. The guide also clarifies that when per-IP shaping is not enabled, the shaper's limits are applied to the sum of all traffic processed by the policy. This validates the incorrectness of option D.

The route-tag setting in a FortiGate SD-WAN rule serves as a dynamic destination matching criterion. It allows the rule to match traffic destined for prefixes that have been assigned a specific numerical tag. These tags are typically applied to routes learned through dynamic routing protocols, such as BGP or OSPF, using route maps. This mechanism enables the SD-WAN to steer traffic based on dynamically learned network information without requiring manual updates to the destination addresses within the SD-WAN rules. For instance, all routes learned from a specific data center can be tagged, and a rule can use that tag to direct all traffic for those destinations over a preferred link.

A. Health check probes are configured on a per-member basis within the SD-WAN settings to monitor link quality, not selected via route tags in traffic rules.

C. This statement is too general. The route-tag is a specific filter for the destination of a traffic flow, not a broad indicator of all possible routes.

D. The route-tag is used to identify the destination of the traffic, not to select the outgoing SD-WAN members (interfaces) that will carry the traffic.

1. FortiOS 7.0.0 Administration Guide: In the "SD-WAN" chapter, section "SD-WAN rules", it states, "Route tags can be used to match a route that has been learned through BGP or OSPF... The route tag is used as the destination for the SD-WAN rule." (p. 1238).

2. FortiOS CLI Reference 7.0.0: Under config router sdwan, config rule, the command set route-tag is described with the helper text: "Use route-tag to match output of dynamic routing protocol." This confirms its use for matching dynamically learned routes.

3. Fortinet Certified Professional - Network Security 7.2 Study Guide: The "SD-WAN" chapter explains, "SD-WAN rules can use route tags to match destinations. You can configure BGP and OSPF to add route tags to the routes they advertise and learn. This way, you can dynamically populate the destinations in the SD-WAN rules routing table." (p. 315).

:

The FortiGate VPN event logs clearly show the establishment of ADVPN shortcut tunnels. The log message msg="IPsec ADVPN shortcut is up" tunnel="TMPLS0" shortcutname="TMPLS00" is explicit. According to the FortiGate log message reference, the tunnel field identifies the parent (master) tunnel, and the shortcutname field identifies the dynamically created shortcut tunnel. Therefore, TMPLS0 is the master tunnel from which one shortcut, named TMPLS00, has been successfully built.

A. The logs contain msg="IPsec tunnel statistics" for tunnelname="TMPLS00" and tunnelname="TINET00", which are the ADVPN shortcut tunnels, disproving this statement.

C. The logs identify TMPLS0 as the master tunnel in the tunnel="TMPLS0" field, while TMPLS00 is explicitly named as the shortcut.

D. The log message msg="IPsec ADVPN shortcut is up" ... tunnel="TINET0" directly confirms that the master tunnel TINET0 successfully negotiated and established an ADVPN shortcut.

1. FortiGate / FortiOS 7.2.0 Log Message Reference, Page 321, Log ID 0101039947.

This document defines the fields for the "IPsec ADVPN shortcut is up" message. It specifies:

tunnel: "Name of the parent tunnel."

shortcutname: "Name of the shortcut tunnel."

This directly supports the explanation that TMPLS0 is the master (parent) and TMPLS00 is the shortcut.

2. FortiOS 7.2.4 Administration Guide, Page 1311, "Monitoring ADVPN".

The guide explains how to monitor ADVPN tunnels. In the output of the command diagnose vpn tunnel list, shortcut tunnels are shown with a suffix (e.g., 0) appended to the master tunnel's name and are identified as dynamic. This confirms the naming convention seen in the logs.

3. SD-WAN 7.2 Study Guide, Page 218, "ADVPN Troubleshooting".

This guide describes the ADVPN shortcut negotiation process. It states, "When a shortcut is created, FortiGate creates a new IPsec phase 1 and phase 2. The new interface name is derived from the original phase 1 name with a number appended to it." This confirms that tunnels like TMPLS00 are the dynamically created shortcuts.

The SD-WAN rule is configured to use the Best Quality strategy, with SLAJitter as the measured criterion. This strategy operates in two steps: first, it identifies all member interfaces that meet the configured SLA target; second, from that filtered list, it selects the single best interface based on the quality metric (lowest jitter).

According to Exhibit B, only the TINET10 interface meets the SLA requirements (SLA Met: Yes). The other two interfaces, TINET00 and TMPLS0, do not meet the SLA (SLA Met: No). Therefore, they are not considered eligible paths. As TINET10 is the only member that satisfies the SLA, FortiGate will route all traffic matching this rule through it.

A: The Best Quality strategy selects a single optimal path based on the defined metric; it does not perform load balancing across multiple overlays.

B: TINET00 is not selected because it fails to meet the SLA target, making it an ineligible path for this rule.

C: TMPLS0 is not selected because it fails to meet the SLA target, making it an ineligible path for this rule.

1. Fortinet NSE 7 SD-WAN 7.2 Study Guide, Chapter: "SD-WAN Rules", Section: "Rule Steering Behavior". The guide explains that for the Best Quality strategy, "FortiGate first checks which members meet the SLA target, and then chooses the best one among them based on the link cost." This confirms that members failing the SLA are not considered for selection.

2. FortiOS 7.2 Administration Guide, Section: "SD-WAN > SD-WAN Rules". The documentation states for the Best Quality strategy: "FortiGate sends all traffic to the link with the best quality... If the best link goes down or does not meet the health-check SLA, FortiGate sends traffic to the next best link." This implies that meeting the SLA is a prerequisite for being considered the "best link".

The snat-route-change setting is enabled, which dictates how FortiGate handles existing sessions when a routing change occurs. The priority of the static route for port2 is increased to 20, making the route via port1 (priority 0) the preferred path for the default route.

Because snat-route-change is enabled, FortiGate will re-evaluate the existing sessions that were using port2. These sessions are first flagged as dirty. A new route lookup is then performed, which identifies port1 as the new best egress interface. Consequently, the session's gateway and SNAT information are updated to redirect the traffic through port1, ensuring session continuity over the new optimal path.

B. FortiGate continues routing the sessions with no SNAT, over port2.

This is incorrect because the enabled snat-route-change feature specifically triggers a re-evaluation and rerouting of sessions when the best route changes.

C. FortiGate performs a route lookup for the original traffic only.

This is incomplete. While a route lookup occurs, the key actions are flagging the session as dirty and updating its attributes for both directions of traffic.

1. Fortinet Knowledge Base, Article ID: FD36126, Technical Tip: Behavior of snat-route-change option in 'config system global'. This article explicitly states: "When this option is enabled, if the route for the SNAT IP is changed, the sessions are not flushed but are marked as dirty and are rerouted." This directly supports answers A and D.

2. FortiOS 7.2.1 Administration Guide, Session failover, Page 1231. The guide explains that for session failover to work when a link fails, sessions must be rerouted. The snat-route-change command is a key part of this process, forcing the re-evaluation of sessions that require SNAT.

3. FortiOS 7.2 CLI Reference, config system global, Page 2018. The description for snat-route-change is "Enable/disable flushing sessions when the source NAT route changes." While the term "flushing" can be ambiguous, in this context, it refers to the re-evaluation process where sessions are marked dirty and updated, as clarified by the Knowledge Base articles.

FortiGate keeps the session table intact when a firewall-policy entry is edited. Packets that belong to sessions already present in the session table continue to match the policy that was in effect when the session was first created, so those sessions are not reset or re-evaluated (option C). Only traffic that triggers the creation of a new session is examined against the updated policy set; therefore the new or modified rules are applied only to new sessions (option D).

A. FortiGate flushes all sessions – Session table is retained; flush occurs only with an explicit diagnose sys session clear command.

B. FortiGate terminates the old sessions – Existing sessions remain active until they age out or are closed normally; no automatic teardown follows a policy edit.

1. Fortinet, “FortiOS 7.2 Administration Guide – Firewall Policy, Changing firewall policies,” p. 339-340: “Changes do not affect sessions already in the session table; new sessions are evaluated against the new policy set.”

2. Fortinet KB Article FD30165 “How does a change to a firewall policy affect existing sessions?” (2022): para 2 “Existing sessions continue untouched; only new sessions are matched against the revised policy.”

3. Fortinet NSE7 SD-WAN 7.2 Study Guide (official), Module 3 “Session Management,” slide 18: “Policy edits are forward-looking; current sessions stay bound to their original rule.”