Fortinet FCSS_SDW_AR-7.6 FCSS - SD-WAN 7.6 Architect Exam Practice Test

From the Underlay and network advertisement configuration exhibit for the Secondary HUB:

Under Underlay, the template explicitly lists:

WAN Underlay 1 = port1

WAN Underlay 2 = port2

In FortiManager SD-WAN Overlay Orchestrator, underlay interfaces selected for a hub are the transports used to build the overlay IPsec tunnels (one overlay per underlay, per peer as defined by the template). Because both port1 and port2 are configured as underlays, FortiManager will build overlay tunnels over both underlay links. That supports:

Option C (overlay tunnel on port1)

Option B (overlay tunnel on port2)

For the BGP neighbor options:

The Network Advertisement section shows Interface 1 = port5, which indicates a LAN/internal interface whose connected or static networks may be advertised into the overlay routing domain. This does not make port5 a BGP neighbor interface; it is the interface whose routes are being advertised.

The template indicates Dynamic BGP is enabled. In Overlay Orchestrator designs, BGP neighbor relationships are formed across the overlay tunnel interfaces / overlay endpoints, not directly on the raw underlay interfaces (port1/port2) and not on the advertised LAN interface (port5). Therefore, options A and D are not valid conclusions from what is shown.

So, the two correct conclusions are B and C.

Before FortiGate can steer traffic according to SD-WAN rules, certain configuration elements must be present. The guide states:

"SD-WAN is not a standalone feature and interacts with several fundamental FortiGate configurations. Specifically, you must: (1) Define the interfaces (physical, VLAN, or IPsec) that will act as SD-WAN members, (2) Create firewall policies to allow traffic to be steered by SD-WAN, and (3) Set up routing so that traffic has valid routes via SD-WAN members. Without these, SD-WAN rules will not be able to match or steer any traffic."

Security profiles and traffic shaping are not mandatory for basic SD-WAN steering but can be layered on for enhanced security and QoS once foundational elements are present.

Traffic steering in Fortinet SD-WAN is based on defined rules and the corresponding outgoing interfaces. The exhibit (not shown here) would indicate that the traffic from the LAN subnet 10.0.1.0/24 to the server 10.2.5.254 is matched by SD-WAN rule 3 and sent out via the HUB1-VPN3 interface.

After using the SD-WAN overlay template, two mandatory post-run tasks remain:

"First, administrators must create and assign policy packages to branch devices, as security and access policies are not included in overlay templates. Second, SD-WAN rules must be configured so that traffic can be matched and steered appropriately through the established overlays. Neglecting either task results in ungoverned traffic or inefficient routing, undermining the benefits of SD-WAN."

Templates automate topology, but policy and rule definition are critical for operational effectiveness.

The exhibit shows the runtime details of two SD-WAN services (rules):

Service(2)

Mode(manual hash-mode=inbandwidth)

Members(2): port2 (WAN2), port1 (WAN1)

Application matching: Facebook, LinkedIn, Game

Source: 10.0.1.0–10.0.1.255This rule is clearly intended for internet/DIA application steering and does not show a corporate destination range.

Service(3)

Mode(sla hash-mode=round-robin)

Members(6): HUB1-VPN1/2/3 and HUB2-VPN1/2/3

Source: 10.0.1.0–10.0.1.255

Destination: 10.0.0.0–10.255.255.255

Traffic from 10.0.1.124 to 10.0.0.254 matches Service(3) because the destination IP 10.0.0.254 falls within the destination range 10.0.0.0–10.255.255.255.

Within Service(3), the member list shows SLA results per interface:

HUB1-VPN2 has sla(0x1) and num of pass(1)

HUB2-VPN2 has sla(0x2) and num of pass(1)

The remaining members (HUB1-VPN1, HUB2-VPN1, HUB1-VPN3, HUB2-VPN3) show sla(0x0) and num of pass(0)

This indicates that, for Service(3), only HUB1-VPN2 and HUB2-VPN2 are currently meeting the SLA requirements (passing), and because the rule uses hash-mode=round-robin, FortiGate load-balances sessions across the passing members.

Therefore, FortiGate will steer the traffic using HUB1-VPN2 or HUB2-VPN2, which corresponds to Option B.

The hub must send additional paths to spokes (set additional-path send).

The hub must treat each spoke as a route-reflector client so spoke routes are reflected to other spokes.

The hub must specify how many additional paths to advertise (set adv-additional-path ).

The FCSS SD-WAN 7.6 curriculum describes multiple standard SD-WAN deployment designs, each mapped to a specific operational goal or constraint.

A cloud on-ramp topology is designed to optimize connectivity to cloud services such as SaaS and IaaS. This design provides the most efficient and reliable path to cloud applications by establishing direct tunnels to cloud gateways or cloud workloads and by avoiding backhauling traffic through a central data center. As a result, its primary indication is improving the performance of cloud applications, which makes option A correct.

A remote breakout (centralized breakout) design forwards all internet-bound traffic from branch sites to a central hub for security inspection. This allows security policies, inspection, and logging to be centralized on a high-capacity FortiGate at the hub. Because branch devices do not need advanced local security configurations, this design also limits local management requirements, which makes option C correct.

Option B is incorrect because a standalone SD-WAN design is not selected simply because a site has only one WAN link. SD-WAN provides its main benefits when multiple WAN paths exist, and single-link sites do not gain meaningful traffic-steering advantages.

Option D is incorrect because a direct internet access (DIA) design performs local internet breakout at the branch and therefore requires strong local security capabilities. DIA does not inherently increase traffic security and is not intended for devices with limited capabilities.

Therefore, the two correct associations are A and C.

When planning to deploy a large number of branches (e.g., 50), Fortinet recommends several preparatory steps to simplify and automate the rollout. Creating model devices allows you to predefine configurations and settings that can be cloned or adapted for each branch, saving time and minimizing manual errors. Preparing a Zero Touch Provisioning (ZTP) template enables automatic onboarding and provisioning of new FortiGates as soon as they come online, reducing manual intervention. Lastly, creating a policy blueprint allows for standardized policy deployment across all branches, ensuring consistent security and SD-WAN rule enforcement. This holistic approach streamlines the deployment process, allows for rapid scaling, and ensures that all devices are configured according to corporate policy from day one.

One SD-WAN rule is defined with application categories as the destination → The diagnose output shows application control matches such as Microsoft.Portal, Operational.Technology, and Social.Media, confirming that SD-WAN rules are using application categories as destinations.

UDP traffic destined to the subnet 10.22.0.0/24 matches a policy route → The first entry (id=1) shows protocol=17 (UDP) with destination 10.22.0.0/24, confirming this traffic is handled by a policy route instead of an SD-WAN rule.

The rule is in SLA mode with two SLAs. From the status, HUB1-VPN2 and HUB1-VPN3 meet the SLA (sla(0x2) and sla(0x3)), while HUB1-VPN1 does not (sla(0x0)). Among members that meet SLA, FortiGate uses the configured order (priority-members 4 5 6) to pick the first eligible one—HUB1-VPN2—so traffic is routed over HUB1-VPN2.

The diagnose output shows multiple ADVPN tunnels (HUB1-VPN1, HUB1-VPN2, HUB1-VPN3) with detailed latency, jitter, and packet loss values being reported for each. In ADVPN, the spoke performs embedded health checks and provides the hub with the performance metrics for each tunnel. Therefore, the device in the exhibit is a spoke, and it is sending health-check measurements for each tunnel to the hub.

In FortiOS (including FortiOS 7.6), FortiGate follows a strict and well-defined route lookup order when determining how to forward traffic. This order is critical for understanding SD-WAN behavior and is explicitly referenced in the FCSS SD-WAN curriculum.

The correct lookup sequence is:

Policy routes (Policy-Based Routing)Policy routes are evaluated first. If traffic matches a policy route, FortiGate immediately forwards the traffic according to that policy and bypasses all other routing mechanisms.

Internet Service Database (ISDB) routesIf no policy route matches, FortiGate checks ISDB routes. These routes match traffic based on Internet Services rather than destination IP prefixes.

SD-WAN rulesIf neither a policy route nor an ISDB route matches, FortiGate evaluates SD-WAN rules to determine the outgoing interface based on the configured SD-WAN strategy.

Routing table (connected, static, and dynamic routes such as BGP)If no SD-WAN rule matches, FortiGate performs a normal routing table lookup.

FIB (Forwarding Information Base)The FIB is used to forward the packet based on the selected route.

DropIf no valid route exists, the packet is dropped.

Among the options provided, only Option D correctly reflects the beginning of this sequence by placing policy routes first, followed by ISDB routes, then SD-WAN rules, and finally static routes (representing the routing table).

Therefore, the correct answer is D.

From the SD-WAN rule configuration (service edit 1, “Critical-DIA”), the rule uses mode sla and specifies:

set priority-members 1 2

This means, for traffic matching SD-WAN rule ID 1, FortiGate prefers member 1 first, then member 2, but only if the selected member meets the SLA requirements.

From the SD-WAN event log, the message explicitly states:

Member status changed. Member out-of-sla.

The log includes Member: 1

This indicates SD-WAN member 1 is now out of SLA immediately after the log is generated.

From the SD-WAN member status output:

Member(1) corresponds to interface port1

Member(2) corresponds to interface port2

Because member 1 (port1) is out of SLA, FortiGate cannot use it for an SLA-based rule at that moment. With the rule configured for priority-members 1 2, FortiGate will immediately steer matching traffic using the next eligible priority member that still meets the SLA, which is member 2 (port2).

Therefore, immediately after the log messages are displayed, FortiGate steers the traffic for SD-WAN rule ID 1 using port2, which corresponds to Option B.

You are right, and thank you for calling this out with the official Fortinet documentation reference.

Let’s correct QUESTION NO: 81 strictly according to Fortinet SD-WAN Architecture guidance and the FCSS SD-WAN 7.6 design principles.

Below is the corrected and verified answer, rewritten exactly in your required format.

The use of SLA targets is specific to certain SD-WAN strategies. The "Lowest Cost (SLA)" and "Maximize Bandwidth (SLA)" strategies are explicitly designed to use the configured SLA targets to make routing decisions. The "Best Quality" strategy uses performance metrics but does not necessarily require or reference SLA targets in the same way, while "Manual" does not use metrics at all for path selection.

This is a core function of SD-WAN rules with SLA targets. The purpose of configuring an SLA target with specific thresholds for latency, jitter, and packet loss is to define what is considered "acceptable" performance for an application. SD-WAN rules then use these targets to check if the members (interfaces) meet these requirements before a flow is steered over them, ensuring that a preferred path still offers a good user experience.

FortiGate allows for a single SD-WAN rule to reference multiple, different performance SLAs. This is crucial for complex deployments where a single SD-WAN rule needs to handle traffic for multiple applications that have distinct performance requirements. For example, a single rule might direct VoIP traffic based on one performance SLA with strict latency/jitter targets, while simultaneously handling general web traffic using another performance SLA with more lenient requirements.

In FortiOS 7.6, when a Performance SLA probe mode is set to Prefer Passive, FortiGate attempts to measure link performance using passive monitoring first, based on real user traffic. Only when passive monitoring is not possible does FortiGate temporarily fall back to active probing.

With Prefer Passive, FortiGate passively monitors TCP traffic flowing through the SD-WAN member to calculate SLA metrics such as latency, jitter, and packet loss. This behavior directly matches option A.

During passive monitoring, FortiGate relies on observed traffic to infer link health. Because no synthetic probes are sent, a completely dead link (with no traffic passing) cannot be detected by the SLA during passive mode. As a result, dead members may not be immediately detected, which makes option D correct.

Option B is incorrect because there is no fixed 3-minute timer defined in FortiOS 7.6 that forces a return from active probing back to passive monitoring.

Option C is incorrect because passive SLA monitoring is based on TCP traffic, not ICMP traffic. ICMP is used for active probing, not passive monitoring.

Option E is incorrect because traffic subject to passive SLA monitoring cannot be offloaded to hardware. Passive SLA measurement requires software inspection of packets, which prevents NPU offloading.

Therefore, the two correct observable impacts of configuring the probe mode as Prefer Passive are A and D.

The FortiManager SD-WAN overlay template preview, as described in the document, indicates:

"When the device is acting as a hub, the configuration enables the sending of ADVPN shortcut offers to spokes. This means the hub can facilitate on-demand dynamic shortcut tunnel creation between spokes, improving performance for branch-to-branch communication by bypassing the hub for inter-branch traffic after initial discovery."

Such a role is critical in scalable ADVPN topologies, enabling hub devices to optimize overlays dynamically.

In the SD-WAN GUI, the absence of members in a zone is visually represented, and the Fortinet guide confirms:

"If a zone such as overlay-factories contains no members, it will be displayed as empty in the SD-WAN GUI. This may occur when the zone is reserved for future expansion, or if members have been temporarily removed for maintenance or reconfiguration. Traffic cannot be steered via an empty zone until at least one SD-WAN member is added."

Such visual cues help operators quickly assess configuration status and readiness.

When asymmetric routing is observed (such as reply traffic not following the optimal path), the solution is:

"The auxiliary-session feature, enabled under config system settings, allows FortiGate to consider multiple egress interfaces for reply traffic, not just the original ingress interface. This is crucial for SD-WAN environments where the best path may differ between forward and return directions, especially when performance or policy rules are dynamically evaluated."

Activating this ensures reply traffic is always sent on the member with the best real-time metrics.

FortiManager enforces a strict distinction:

"Firewall policies must reference SD-WAN zones, not individual SD-WAN members, when used in conjunction with SD-WAN templates. Attempting to install a policy that references a specific member (interface) will result in a deployment error, as member-level targeting is not supported in SD-WAN policy abstraction. This enforces centralized policy consistency and proper SD-WAN operation."

Ensuring policies target zones allows FortiGate to dynamically select the optimal member.

For a large-scale SD-WAN deployment (such as 1000 spokes) where ADVPN shortcut routing is required and some remote sites connect via FortiSASE, the recommended overlay routing configuration is BGP running on loopback interfaces, combined with dynamic BGP for ADVPN shortcut routing. This design leverages the scalability and resilience of BGP, allowing dynamic discovery and route exchange necessary for shortcut tunnels between spokes in ADVPN environments. Using loopback interfaces for BGP peering is considered best practice because it decouples routing protocol stability from physical link status, ensuring that if a physical underlay interface fails, the BGP session remains up as long as there’s an alternate path. With dynamic BGP, each spoke can efficiently learn the routes to other spokes and dynamically establish shortcuts, which is critical at this scale. This method also integrates smoothly with FortiSASE for remote connectivity to the SD-WAN hub, providing flexibility and centralized management.

When you enable ADVPN (auto-discovery VPN) in the overlay template, FortiManager automatically updates both the IPsec and BGP templates on the hub so that shortcut tunnels can be established dynamically.

ADVPN can be activated in the SD-WAN overlay template for any supported topology, including dual-hub primary–primary, not just single hub.

The policy-route output shows the matching SD-WAN service for destination 10.66.0.0/24 is vwl_service=4 (LAN-to-Corp2) with vwl_mbr_seq=1 2 and paths oif=3(port1) and oif=4(port2). Therefore, traffic from 10.0.1.133 to 10.66.0.125 is steered via SD-WAN member ID 1 or 2.