Fortinet FCSS_SDW_AR-7.4 Practice Questions

Explanation:
In large SD-WAN deployments, preparing configuration elements in advance greatly reduces provisioning time and prevents inconsistencies across branches. Fortinet’s SD-WAN automation framework allows pre-building reusable configuration sets—such as model devices, ZTP templates, and policy blueprints—which can be applied to new branch devices as soon as they come online. This ensures consistent policy enforcement, reduces manual intervention, and simplifies onboarding during rapid or large-scale branch rollouts.

Correct Options:

B. Create model devices.
Pre-creating model devices allows you to define hardware models and expected configuration profiles before the physical units arrive. When the real device connects to FortiManager, it automatically maps to the model device and inherits its baseline settings. This significantly speeds up onboarding and ensures uniform deployment across all new branches.

C. Create a ZTP template.
Zero-Touch Provisioning (ZTP) templates allow new devices to automatically pull their configuration from FortiManager during first boot. Preparing this template in advance reduces manual configuration and ensures that every newly deployed branch follows the same standardized SD-WAN configuration. This is essential when scaling to dozens of new sites.

E. Create policy blueprint.
A policy blueprint allows administrators to define enterprise-wide security and SD-WAN policies ahead of deployment. These can then be applied to multiple devices or groups as they come online. Preparing blueprints ensures consistency across all branches and reduces the need for device-level policy creation during deployment.

Incorrect Options:

A. Update the DHCP server configuration.
While DHCP may be used for addressing in some branch networks, updating DHCP configurations is typically a local network task and not part of SD-WAN pre-deployment automation. It does not significantly simplify SD-WAN onboarding, nor is it required for ZTP or FortiManager-based provisioning of new branches.

D. Define metadata variables value for each device.
Meta fields and variables are useful for automation, but defining values before the devices exist is not practical. Metadata is typically assigned once a device is added or discovered. Pre-defining metadata does not simplify deployment for devices that have not yet been onboarded.

Reference:
Fortinet Secure SD-WAN Zero Touch Deployment Guide

Explanation:
To allow spokes to learn prefixes from other spokes (and receive multiple paths), the hub must both reflect routes and advertise extra paths. Configure the neighbor-group so the hub will accept, store, and re-advertise multiple paths and treat spokes as clients for reflection. Without additional-path send/advertise settings and route-reflector client/server behavior, the hub won’t forward spoke-learned routes or their extra paths to other spokes.

Correct Option:

A. Set additional-path to send
Enabling additional-path send on the hub’s neighbor-group causes the hub to advertise more than one path for a prefix to its neighbors. This is required so spokes receive the extra (non-best) paths learned from other spokes. In FortiOS, you must allow sending additional-paths from the hub for the spokes to see alternate paths and make multipath or path-selection decisions.

D. Enable route-reflector-client
Marking the spoke neighbors as route-reflector clients on the hub lets the hub reflect routes learned from one client to other clients without requiring full-mesh IBGP. In a hub-and-spoke overlay, the hub acts as the reflector and spokes as clients; enabling the client role on the neighbor-group ensures the hub will re-advertise spoke prefixes to other spokes.

E. Set adv-additional-path to the number of additional paths to advertise
You must explicitly configure how many additional paths the hub will advertise (e.g., adv-additional-path 2). This controls the count of non-best paths carried to neighbors; without setting this, additional-path capability may be disabled or limited. Setting an adequate number ensures spokes receive all intended extra paths from other spokes.

Incorrect Option:

B. Set additional-path to forward
The additional-path forward option is not the correct control for advertising additional paths in FortiOS BGP neighbor-groups. FortiOS typically uses additional-path modes such as send/receive (or separate adv-additional-path for count). “Forward” is not the operative action to enable sending/advertised additional paths to neighbors, so it will not cause spokes to learn other spokes’ additional paths.

C. Enable route-reflector-server
Enabling a route-reflector server on a neighbor-group is not the appropriate per-neighbor setting required for spokes to learn each other’s routes. In hub-and-spoke topologies the hub must act as the reflector (server) and the spokes must be configured as clients on the hub’s neighbor-groups. Turning on “server” in the neighbor-group is either not the expected configuration or misapplies roles and will not make the hub reflect client-learned prefixes to other spokes.

Reference:
Fortinet — FortiOS Handbook: BGP (sections on Additional-Paths and Route Reflection)

Explanation: 📚
The implicit SD-WAN rule acts as a default action when incoming traffic fails to match any explicitly defined, custom SD-WAN rules (Performance SLA or Manual). When traffic hits this rule, it bypasses the sophisticated SD-WAN steering logic and typically falls back to standard FortiGate routing mechanisms. This behavior ensures that traffic still passes through the FortiGate, but without the benefits of intelligent path selection.

Correct Options: ✅

A. The session information output displays no SD-WAN service id.
Since the traffic is not processed by any explicit SD-WAN rule or a specific service (like an SLA or manual rule), the session created does not have a designated SD-WAN Service ID. This ID is only assigned when traffic successfully matches an explicit SD-WAN rule entry, indicating that the traffic is actively being managed and steered by the SD-WAN feature.

D. Traffic does not match any of the entries in the policy route table.
The SD-WAN rules are consulted before the standard routing table (which includes the policy route table and the main FIB/static routes). If traffic matches an explicit SD-WAN rule, that rule steers the traffic. If it falls through to the implicit rule, it means the traffic did not match any explicit SD-WAN rule. The routing decision for this traffic is then deferred to the standard routing process, checking the policy route table and then the main forwarding information base (FIB) for the best route.

Incorrect Options: ❌

B. Traffic is load balanced using the algorithm set for the v4-ecmp-mode setting.
The implicit rule is handled by the standard FortiGate routing engine, which typically uses the main routing table (FIB). If multiple equal-cost static routes exist for the destination, ECMP (Equal-Cost Multi-Path) might be used, but this is a standard routing feature, not a guaranteed behavior of the implicit SD-WAN rule itself. The implicit rule's core function is simply to pass the traffic on for regular routing, not to specifically enforce the v4-ecmp-mode SD-WAN setting.

C. The traffic is distributed, regardless of weight, through all available static routes.
Traffic matching the implicit rule will be routed using the best match route in the standard routing table (Policy Routes > FIB). If ECMP is used (due to multiple equal-cost routes), traffic distribution follows the ECMP mechanism (often based on session hash), which is distinct from SD-WAN's load balancing which can consider weights. The implicit rule does not automatically distribute traffic over all static routes; it uses the single best route or an ECMP group if one exists.

E. FortiGate flags the session with may_dirty and vwl_default.
The vwl_default (Virtual WAN Link Default) flag is typically associated with traffic that has been successfully passed to the default action of an SD-WAN member interface because no specific rule matched it. While the session eventually gets routed, the most accurate description of the SD-WAN-specific consequence of matching the implicit rule is the lack of a service ID (Option A) and the failure to match explicit rules (Option D), which is the cause of hitting the implicit rule.

Reference: 📖
This information is typically covered in the Fortinet Secure SD-WAN Administration course material, specifically relating to the SD-WAN Rule Matching Process and the function of the Implicit SD-WAN Rule (Rule ID 0 or the last rule in the table). You can find details in the FortiGate documentation under the SD-WAN sections for rule processing and session information.

Explanation:
For a spoke-to-hub SD-WAN scenario to correctly steer traffic according to the defined performance SLA on the spoke, the hub must measure the link quality using exactly the same health-check criteria (protocol, servers, thresholds, etc.) as the spoke. If the hub uses different criteria or does not embed the measured health into the routing protocol, the spoke’s priority rules (link-cost-factor, priority-members, etc.) will not work as expected because the hub’s route costs will not reflect the measured SLA performance.

Correct Option:

C – The performance SLA uses the same criteria
The hub must run a performance SLA health-check with identical parameters (same DNS servers 4.2.2.1/4.2.2.2, protocol ping, latency-threshold 100 ms, same SLA members 3 and 4, etc.) as the spoke. If the hub uses different servers, thresholds, or protocol, the measured link quality differs, and the spoke’s SD-WAN rules that rely on performance SLA (priority-members, lowest-cost, best-quality) cannot steer traffic correctly to the preferred tunnel.

D – The performance SLA is configured with set embed-measured-health accept
On ADVPN hubs, the measured health (SLA status) is only embedded into BGP or OSPF updates when the performance SLA explicitly contains set embed-measured-health accept. Without this setting on the hub’s matching performance SLA, the hub does not advertise the real-time SLA met/violated status to spokes, so spokes cannot apply priority or cost-based steering even if the spoke itself measures the link correctly.

Incorrect Option:

A – The performance SLA has the parameter priority-out-sla configured
The command priority-out-sla does not exist in FortiOS SD-WAN performance SLA configuration. The related commands are priority-members and priority-in-sla (on routes), not on the health-check itself. This option is invalid.

B – This performance SLA uses the same members
While the SLA map ID and member IDs should usually match for clarity, it is not strictly required. What matters is that the hub measures the exact same links (members 3 and 4 in the exhibit) using identical probe targets and thresholds. Having different member IDs but same underlying interfaces and criteria would still work. Therefore, this is not a mandatory condition.

Reference:
FortiOS 7.4 SD-WAN Architecture Guide → “Performance SLA – Link health monitoring” → “ADVPN with SD-WAN link monitoring requirements”

Explanation:
In Fortinet's SD-WAN architecture, SIA stands for Secure Internet Access. It is a design pattern where internet-bound traffic from a branch office is sent directly to the internet locally, rather than being backhauled through a central datacenter. This optimizes application performance by reducing latency and conserving WAN bandwidth on the more expensive hub links.

Correct Option:

B. Local Breakout:
This is the correct answer. SIA fundamentally describes the capability for a branch office to break out directly to the internet from its local network. This method, also known as Direct Internet Access (DIA), improves the user experience for cloud and SaaS applications by providing a shorter, more direct path.

Incorrect Options:

A. Remote Breakout:
This is the opposite of what SIA does. "Remote Breakout" would imply sending traffic to a central site (hub) first, which is the traditional backhaul method that SIA is designed to avoid.

C. Software Internet Access:
This is a distractor term and not a recognized acronym or standard concept within the SD-WAN or Fortinet lexicon. It does not accurately describe the SIA functionality.

D. Secure Internet Authorization:
While "Secure" is part of the SIA acronym, "Authorization" is incorrect. SIA focuses on the secure routing and access of internet traffic locally, not on user or device authorization processes.

Reference:
Fortinet NSE 7 SD-WAN 7.4 training materials and the Fortinet Documentation Library frequently describe SIA as the method for enabling local internet breakout at the branch level while maintaining security inspection.

Explanation:
The SD-WAN rule is in SLA mode with an explicit priority-members list and a shortcut-priority value. That means the SD-WAN engine evaluates members by SLA and then uses the configured priority/shortcut settings to pick which overlay to install for matched traffic. The diagnostics show all three overlays alive, but the shortcut/prioritization chooses the second priority member as the active path for this service.

Correct Option:

B. The traffic will be routed over HUB1-VPN2.
The set priority-members 4 5 6 order combined with shortcut-priority 2 makes the SD-WAN engine select the second priority member as the shortcut path when SLA conditions permit. The diagnostic output shows the member corresponding to HUB1-VPN2 is alive and selected, and the routing table contains an active BGP next-hop via the HUB1-VPN2 address (.125). Therefore traffic matching the rule will use HUB1-VPN2.

Incorrect Options:

A. The traffic will be routed over HUB1-VPN3.
Although HUB1-VPN3 is alive in the member list, it is the third configured priority (cfg order(2)) and not the active shortcut according to shortcut-priority. The diagnostics show it is selected for monitoring, but it is not the chosen shortcut path for this rule, so traffic will not preferentially use HUB1-VPN3.

C. The traffic will be routed over HUB1-VPN1.
HUB1-VPN1 appears in the routing table and is reachable, but the combination of priority-members and shortcut-priority indicates the second member is preferred for shortcut routing. Even though HUB1-VPN1 is available (and may be used as a backup), it is not the active shortcut chosen for this SD-WAN service instance.

D. The traffic will be load balanced across all three overlays.
The SD-WAN configuration is using SLA + explicit priority members, not a round-robin or per-packet load-balancing policy. The diagnostics show a single selected shortcut member (the second priority). Therefore traffic is routed to the chosen overlay (HUB1-VPN2), not equally across all three overlays.

Reference:
Fortinet — FortiOS Handbook, Secure SD-WAN (SD-WAN service modes, priority-members, and shortcut behavior)

Explanation:
The exhibit displays the SD-WAN Zone configuration table. In this table, the column labeled Interfaces shows the members assigned to each zone. Zones with a (+) icon indicate that they can be expanded to show their members. Zones with a (-) icon are currently expanded, revealing the interfaces that belong to them. Zones with no icon are either system-defined or currently have no visible members.

Correct Option:

C. The overlay-factories zone contains no member.
The overlay-factories zone is displayed with a (+) icon, which indicates it is a zone that can be expanded. However, there are no listed interfaces nested directly underneath it, unlike the HUB1 zone. While the (+) icon means it can contain members, the current view and the lack of nested interfaces indicate that no interfaces are currently assigned to this specific zone.

Incorrect Options:

A. The underlay zone contains three members.
The underlay zone is also shown with a (+) icon, but no members are visible below it in the hierarchy. The three visible members (HUB1-VPN1, HUB1-VPN2, and HUB1-VPN3) are nested under the HUB1 zone, not the underlay zone. Therefore, we cannot conclude that the underlay zone has three members based on this exhibit.

B. You can delete the virtual-wan-link zones.
The virtual-wan-link is a system-defined zone that represents the entire SD-WAN group. It is a mandatory, core component of the SD-WAN feature and cannot be deleted. The presence of the red lock icon next to its name visually confirms that this zone is not editable or deletable by the user.

D. You can move HUB1-VPN3 from the HUB1 zone to the overlay-shops zone.
HUB1-VPN3 is an overlay tunnel interface (likely IPsec or similar) and is currently a member of the HUB1 zone. In FortiGate SD-WAN, an interface can only belong to one custom SD-WAN zone at a time. To move it, you would first need to remove it from the HUB1 zone before attempting to add it to the overlay-shops zone. You cannot simply move it while it's actively part of another custom zone.

Reference:
This configuration detail is found in the Fortinet Secure SD-WAN Administration course material, specifically concerning the SD-WAN Zone Configuration and Interface Membership rules within the FortiGate GUI. The non-deletable nature of the virtual-wan-link is a foundational SD-WAN concept.