Fortinet FCSS_SDW_AR-7.4 Practice Questions

Explanation:
The exhibit shows the output of the FortiGate command diagnose firewall proute list, which lists both traditional Policy Routes (PBR) and SD-WAN Rules (which are implemented as policy routes with special internal identifiers). The output reveals an entry that is clearly an SD-WAN rule because it has the destination internet-service-app-ctrl and a very large, non-sequential id value. The second entry shows a standard, low-numbered id that matches a specific destination subnet, which is characteristic of a Policy Route.

Correct Options:

A. One SD-WAN rule is defined with application categories as the destination.
The first entry shown has the destination match criteria: internet-service-app-ctrl. In FortiGate SD-WAN rules, this criterion is used when the traffic is matched based on a specific Application Control Category or an Application/Internet Service Database entry. The large id=1211153920 also confirms it is an internal SD-WAN service rule.

D. UDP traffic destined to the subnet 10.22.0.0/24 matches a policy route.
The second entry has a low id=1 and matches traffic with:

protocol=17 (UDP)

dport=1:65535 (Any port)

dst=10.22.0.0/24 (The destination subnet).

Since the FortiGate route lookup order checks Policy Routes first, and this entry has the characteristics of a Policy Route (low ID, explicit next-hop defined by oif and gateway), traffic matching these criteria will be explicitly handled by this traditional Policy Route before the SD-WAN rules are consulted.

Incorrect Options:

B. UDP traffic destined to the subnet 10.22.0.0/24 matches a manual SD-WAN rule.
The entry matching this traffic is the second one, id=1. The small, sequential ID number identifies it as a traditional Policy Route (PBR), not an SD-WAN rule (which have very large, internal IDs like the first entry). Policy Routes are checked before SD-WAN rules in the routing process.

C. One SD-WAN rule allows traffic load balancing.
The SD-WAN rule (the first entry, id=1211153920) has an oif=virtual-wan-link but also specifies a single gateway=172.16.100.1. In FortiGate SD-WAN, explicitly setting a gateway in the policy route associated with the rule often forces traffic to a specific member, which generally indicates a Manual steering mode or a priority/SLA mode that has selected only one interface, not a generalized load balancing mode across multiple equal links. The output does not definitively confirm a load balancing mode is in use.

Reference:
This output is from the FortiGate CLI command diagnose firewall proute list, which is a key tool for troubleshooting FortiGate routing logic, including the differentiation between traditional Policy Routes (PBR) (low, sequential IDs) and SD-WAN Service Rules (large, internal IDs prefixed by vwl_service). The use of internet-service-app-ctrl as a destination field is a feature of Application-based SD-WAN steering.

Explanation:
After deploying an SD-WAN configuration via templates on FortiManager, you need the correct monitoring view to see the real-time status of each SD-WAN member interface (like internet, MPLS) and their associated Performance SLA probes. This view is distinct from a physical topology map and focuses on the health and metrics of the individual WAN links.

Correct Option:

B. Use the SD-WAN monitor table view to get a donut view and a table view that shows the status of each SD-WAN member, including the SLA pass or missed status.
This is the precise function of the SD-WAN Table View in FortiManager. It provides a summary "donut" chart for an at-a-glance status and a detailed table listing each member, its state (up/down), latency, jitter, packet loss, and most importantly, whether the configured SLA targets are being met (Pass/Miss).

Incorrect Options:

A. Use the SD-WAN monitor template view to get a map view...
The template view is for managing and deploying configuration templates, not for live monitoring. It does not provide a graphical status of member health or SLA.

C. Use the VPN monitor map view to get a map view...
While the VPN Monitor shows the IPsec tunnel topology and their operational state (up/down), it does not display the specific performance SLA status (latency, jitter, packet loss, pass/miss) for the underlying SD-WAN members.

D. Use the SD-WAN monitor asset view to get a donut view...
The Asset View provides a high-level health summary of the managed devices themselves (e.g., CPU, memory, FortiGuard services), not the detailed status of the individual SD-WAN member interfaces and their SLAs.

Reference:
Fortinet FortiManager 7.4 Administration Guide - "Monitoring SD-WAN" section, which explicitly describes the "SD-WAN Table" view as the tool for monitoring member status and SLA health.

Explanation:
The FortiManager SD-WAN Overlay Template automates the creation of IPSec tunnels, ADVPN shortcuts, BGP/OSPF on tunnels, and basic zone/objects on branch and hub FortiGates. However, it does not create firewall policies or SD-WAN steering rules. After the template is successfully installed, the administrator must manually create and install policy packages (including firewall policies) and configure SD-WAN rules (steering traffic to the correct members or performance SLAs) to make the overlay fully functional.

Correct Option:

B – Create policy packages and assign them to the branch devices
The overlay template never creates firewall policies. Traffic will be blocked until the administrator creates a policy package (or individual policies) in FortiManager that allows the required traffic and installs it to the branch (and hub) devices. This is always mandatory after running the SD-WAN overlay template.

D – Configure SD-WAN rules
The template does not configure any config system sdwan → config service (SD-WAN rules). Without SD-WAN rules, all traffic continues to use the underlying physical interfaces or default route instead of the overlay tunnels. Defining rules that steer traffic based on application, destination, or performance SLA is mandatory for the SD-WAN overlay to actually steer traffic over the tunnels.

Incorrect Option:

A – Configure routing through the overlay tunnels created by the SD-WAN overlay template
Routing (BGP or OSPF) on the overlay tunnels is automatically configured by the template. No manual post-run routing configuration is required.

C – Assign a hub id metadata variable to each hub device
Hub-id metadata variable is optional and only needed in very specific multi-hub designs that use the hub-id variable in templates. It is not a mandatory post-run task.

E – Assign an sdwan_id metadata variable to each device (branch and hub)
The SD-WAN overlay template requires the sdwan_id metadata variable before it is run. It is a pre-requisite, not a post-run task. The template will fail to install if sdwan_id is missing.

Reference:
FortiManager 7.4 Administration Guide → SD-WAN Templates → “SD-WAN overlay template” → “Post-installation tasks”

Explanation:
Fortinet SD-WAN integrates with the device's routing table to make intelligent path selection decisions. The key principles define the order of operation, ensuring that routing fundamentals are respected before SD-WAN rules are applied. This prevents routing loops and ensures traffic uses the correct path as defined by the broader network policy.

Correct Option:

B. Policy routes have precedence over SD-WAN rules.
Policy-based routing (PBR) is a very specific, high-priority directive. If a PBR policy matches the traffic, it will be enforced, and the SD-WAN rule engine will not be consulted for that traffic flow.

D. SD-WAN rules are skipped if the best route to the destination is not an SD-WAN member.
The SD-WAN rule engine only activates if the routing table's best path for a packet points to an interface that is a configured SD-WAN member. If the best route is a physical interface or VPN tunnel not in the SD-WAN zone, the packet is sent directly.

E. SD-WAN members are skipped if they do not have a valid route to the destination.
Before using an SD-WAN member, the FortiGate performs a route lookup from the perspective of that member's interface. If that lookup fails to find a route to the destination, that member is considered invalid and is skipped for that session.

Incorrect Options:

A. Directly connected routes have precedence over SD-WAN rules.
This is incorrect because the routing table itself is always consulted first. If the best route is a directly connected network, the packet is sent directly out that interface. The SD-WAN rule logic does not override this fundamental routing principle; it works within it.

C. SD-WAN rules are skipped if the best route to the destination is a static route.
This is a misleading and incorrect generalization. SD-WAN rules are only skipped if that static route points to a non-SD-WAN interface. If the static route points to an SD-WAN member interface (e.g., port1), then the SD-WAN rule engine will actively process the traffic for that route.

Reference:
Fortinet NSE 7 SD-WAN 7.4 Study Guide and the FortiOS Handbook on SD-WAN, which detail the path selection logic and the hierarchy where SD-WAN rules are evaluated after the routing decision but can override the egress interface based on performance and policy.

Explanation:
SD-WAN load balancing on FortiGate is a flexible system that allows traffic distribution across multiple WAN links. The primary strategy for this is Maximize Bandwidth (SLA) (or the load-balance mode in CLI). When this strategy is used, the FortiGate first filters the available links based on SLA targets, and then uses a hashing algorithm to distribute the traffic across the remaining qualified links.

Correct Options:

A. You can select the outbandwidth hash mode with all strategies that allow load balancing.
Outbandwidth is one of the available hash modes (algorithms) used by the FortiGate to decide which interface to select for a new session when in a load balancing strategy. This hash mode chooses the link with the most available outbound bandwidth based on the configured interface speed. All strategies designed for load balancing (primarily Maximize Bandwidth (SLA), and Load Balancing enabled under Lowest Cost (SLA) or Manual mode) support the use of bandwidth-aware hash modes like outbandwidth (along with inbandwidth and bibandwidth).

C. When applicable, FortiGate load balances the traffic through all members that meet the SLA target.
This is the core behavior of the Maximize Bandwidth (SLA) strategy. The FortiGate first checks the required Performance SLA targets (e.g., latency, jitter, packet loss). Any SD-WAN member that successfully meets those targets is considered eligible. The rule then uses its configured load-balancing hash mode (like Round Robin, Source-IP, or Outbandwidth) to distribute the traffic among all the eligible members, thus maximizing the total available bandwidth.

Incorrect Options:

B. Only the manual and best-quality strategies allow SD-WAN load balancing.
This is incorrect. The main strategy for load balancing is Maximize Bandwidth (SLA). While Manual strategy can be configured to enable load balancing via CLI (set mode load-balance), the Best Quality (SLA) strategy is designed for single-path selection—it picks only the one link with the absolute best measured quality metric (e.g., lowest latency), not for distributing traffic across multiple links.

D. SD-WAN load balancing is possible only using the best quality and lowest cost (SLA) strategies.
This is incorrect. The Best Quality (SLA) strategy focuses on selecting the single best link, not load balancing. While load balancing can be enabled on the Lowest Cost (SLA) strategy (by setting load-balance enable in the CLI), the dedicated strategy for load balancing is Maximize Bandwidth (SLA).

Reference:
This information is derived from the Fortinet Secure SD-WAN Administration course material, specifically detailing the SD-WAN Rule Strategies and available Load Balancing Hash Modes in FortiOS.

Explanation:
In FortiManager 7.4, the SD-WAN overlay template supports enabling Auto-Discovery VPN (ADVPN) even on existing deployments by re-running or modifying the template. ADVPN can be activated in any supported topology (single-hub, dual-hub primary-primary, primary-secondary, full-mesh). When auto-discovery is enabled, FortiManager automatically modifies the relevant VPN phase1/phase2 and BGP templates on the hub(s) to insert the required auto-discovery-sender, auto-discovery-receiver, and shortcut settings.

Correct Option:

B – When auto-discovery VPN is enabled, FortiManager updates the IPsec and BGP templates in the hub
Enabling auto-discovery in the overlay template causes FortiManager to automatically push the necessary ADVPN commands (set auto-discovery-sender enable, set auto-discovery-receiver enable, shortcuts over IPsec, NHRP settings, and BGP allow-as-in or conditional advertisements) to the hub devices without manual CLI template changes.

D – You can activate auto-discovery VPN in the SD-WAN overlay template for any type of topology, including a primary-primary dual-hub topology
FortiManager 7.4 fully supports enabling ADVPN in single-hub, dual-hub (primary-primary), dual-hub (primary-secondary), and full-mesh overlay templates. There is no limitation to only single-hub topologies.

Incorrect Option:

A – You can activate auto-discovery VPN in the SD-WAN overlay template only if it is a single hub topology
This is false. ADVPN via the overlay template is fully supported in multi-hub topologies (including primary-primary dual-hub).

C – After you enable auto-discovery VPN in the overlay template, you must select between ADVPN 2.0 and ADVPN 1.0
There is no such selection in the FortiManager GUI. FortiManager 7.2+ implements the modern shortcut-based ADVPN (sometimes called ADVPN 2.0) automatically when auto-discovery is enabled; legacy “ADVPN 1.0” (pure NHRP without shortcuts) is not an option in the overlay template.

Reference:
FortiManager 7.4 Administration Guide → SD-WAN Templates → “SD-WAN overlay template” → “Auto-discovery VPN (ADVPN)”

Explanation:
The FortiGate GUI is designed to be streamlined and does not display every possible configuration option by default to avoid overwhelming administrators. Features that are considered advanced or less commonly used are often hidden and must be explicitly enabled. The "Application" as a match criterion in SD-WAN, VPN, and firewall policies is one such feature that is disabled in the GUI by default.

Correct Option:

D. You must enable the feature first using the GUI menu System > Feature Visibility.
This is the standard procedure for revealing hidden features in the FortiGate GUI. By navigating to System > Feature Visibility, you can find and enable the "Application" option under the "Security Features" section. Once enabled, the "Application" selector will appear as a configurable destination in SD-WAN rules.

Incorrect Options:

A. You cannot use applications as the destination when FortiGate is used for a DIA setup.
This is false. Application-based SD-WAN rules are a core feature and are fully supported in DIA (Direct Internet Access) setups. The limitation is purely in the GUI's default visibility, not in the platform's capabilities.

B. FortiGate allows the configuration of applications as the destination of SD-WAN rules only on the CLI.
This is incorrect. While it is possible to configure this via the CLI, the feature is also available in the GUI once it has been made visible through the Feature Visibility menu.

C. You must enable the feature on the CLI.
This is not the primary or intended method. The Feature Visibility menu in the GUI is the correct and user-friendly way to enable this option. While CLI commands can alter the configuration, they are not required to simply make the feature appear in the web interface.

Reference:
Fortinet FortiOS Documentation - "Feature Visibility" chapter, which explains that certain features are hidden by default and must be enabled to appear in the GUI. The specific setting to enable is "Application" under Security Features.