Fortinet FCSS_SDW_AR-7.4 Practice Questions

Explanation:
Local-out traffic refers to traffic originated by the FortiGate itself, such such as DNS lookups, NTP synchronization, FortiGuard updates, and logging to a FortiAnalyzer or syslog server. By default, this traffic bypasses the sophisticated SD-WAN rules engine and relies on the standard system routing table lookup. To force specific local-out traffic to use SD-WAN steering, the administrator must explicitly enable this functionality for each service that needs it.

Correct Options:

B. By default, local-out traffic does not use SD-WAN.
This is the primary constraint. Unlike user-originated traffic (which checks firewall policies and then SD-WAN rules), the FortiGate's self-generated traffic is routed using the main system routing table (FIB). If the default static route points to an SD-WAN member interface, the traffic will use that interface, but it will not be subject to any SD-WAN steering logic (like SLA checks or load balancing) unless explicitly configured.

D. You must configure each local-out feature individually to use SD-WAN.
Since SD-WAN usage is not the default, you need to go into the configuration for each specific feature (e.g., config system fortiguard, config system dns, config system ntp) and change the interface-select-method from its default (usually auto or an interface) to sdwan. This tells the FortiGate to send traffic for that particular service to the SD-WAN rules engine for path selection.

Incorrect Options:

A. By default, FortiGate uses SD-WAN rules only for local-out traffic that corresponds to ping and traceroute.
This is incorrect. By default, no local-out traffic, including ping and traceroute, uses SD-WAN rules. To enable this for diagnostic tools, you must use the CLI commands execute ping-options use-sdwan yes and execute traceroute-options use-sdwan yes.

C. You can steer local-out traffic only with SD-WAN rules that use the manual strategy.
This is incorrect. Once a local-out feature is configured to use the sdwan interface selection method, its traffic will be processed by the SD-WAN rules just like user traffic. This means it can match Performance SLA rules, Maximize Bandwidth rules, or any other steering strategy defined, not just the Manual strategy.

Reference:
This topic is covered in the Fortinet Secure SD-WAN Administration course material, under the sections detailing Local-Out Traffic Routing and the interface-select-method setting within various system configuration objects (like config system fortiguard or config system dns).

Explanation:
When an SD-WAN rule uses the Best Quality strategy with a performance SLA (here Default_FortiGuard) and a custom quality profile (Custom-profile-1), FortiGate first selects only the members that currently meet all SLA targets defined in the health check (latency, jitter, packet loss). From the remaining eligible members, it then applies tie-breakers in this strict order: member order in the rule, then the local link-cost (configured under interface or SD-WAN member).

Correct Option:

C – Links that meet the SLA targets – Member configuration order – Member local cost
Step 1: Only members meeting all SLA objectives in Default_FortiGuard (and any additional thresholds in Custom-profile-1) are considered.

Step 2: Among SLA-compliant members, the one with the lowest order in the SD-WAN rule is preferred.

Step 3: If multiple members have the same order (or order is not decisive), the member with the lowest configured link-cost (outbound link-cost on the interface or member) wins.

Incorrect Option:

A – Latency – Member configuration order – Link cost threshold
Latency alone is not used as the primary criterion in Best Quality mode when an SLA health check is selected; the entire SLA must be met first.

B – Link quality index – Member configuration order – Link cost threshold
Link quality index and link-cost-threshold are used only in the “Lowest Cost (SLA)” strategy, not in Best Quality.

D – Latency – Jitter - Packet loss – Bandwidth – Member configuration order
Best Quality does not rank links by comparing measured values (latency → jitter → loss → bandwidth). It uses a binary pass/fail against SLA targets first, then falls back to member order and link cost.

Reference:
FortiOS 7.4 SD-WAN Guide → “SD-WAN service strategies” → “Best Quality” section

Explanation:
This IPsec configuration is for a dial-up tunnel, typically used in a hub-and-spoke topology where the spoke (with this configuration) initiates the connection to a hub. The key parameters are peertype any, which allows connection to any peer, and exchange-interface-ip enable, which is a critical setting for defining how IP addresses are assigned to the tunnel interfaces.

Correct Option:

B. The remote end can be a third-party IPsec device.
The setting peertype any makes the FortiGate flexible in accepting connections from any IKE peer that can match the Phase 1 parameters, including non-Fortinet devices.

C. The administrator must manually assign the tunnel interface IP address on the hub side.
Because exchange-interface-ip is set to enable on this spoke, the hub is expected to provide its own tunnel IP to the spoke. This means the hub's tunnel IP must be manually configured, as it will not be learned from the spoke.

E. This configuration allows user-defined overlay IP addresses.
The exchange-interface-ip enable command facilitates the exchange of IP addresses for the tunnel interfaces themselves, creating the overlay network. This allows administrators to define their own IP addressing scheme for the tunnel, rather than using an automatically assigned one.

Incorrect Options:

A. The tunnel interface IP address on the spoke side is provided by the hub.
This is the opposite of what the configuration indicates. exchange-interface-ip enable means this FortiGate (the spoke) will provide its own tunnel IP address to the remote peer (the hub). The spoke's IP is configured locally.

D. The remote end must support IKEv2.
While ike-version 2 is configured, this does not mean the remote end must use IKEv2. The peertype any setting allows the tunnel to negotiate and fall back to IKEv1 if the remote end does not support IKEv2, providing compatibility.

Reference:
Fortinet FortiOS CLI Reference for config vpn ipsec phase1-interface. The exchange-interface-ip command is documented to control which side of the tunnel provides its interface IP address, defining the overlay network setup in a dial-up VPN.

Explanation:
The configuration uses a passive health check named "Passive" that is linked to an SD-WAN service rule for "Facebook-YouTube". Passive health checks do not send active probes; instead, they monitor the performance (latency, jitter, packet loss) of the actual user traffic matching the rule. The health of the SD-WAN members is therefore directly tied to the flow of the specified applications.

Correct Option:

B. The performance is an average of the metrics measured for Facebook and YouTube traffic passing through the member.
This is true. The passive health check is bound to the service rule that controls both Facebook (ID 15832) and YouTube (ID 31077). The FortiGate will measure the performance of all traffic matching these application IDs and calculate composite metrics for each member.

D. FortiGate identifies the member as dead when there is no Facebook and YouTube traffic passing through the member.
This is true for passive checks. Without active probes, if there is no user traffic for the specified applications, the FortiGate has no data to measure. A lack of measurable traffic will cause the member to be considered "dead" or down after the configured timeout.

Incorrect Options:

A. Only related TCP traffic is used for performance measurement.
This is false. Passive measurements can be performed on both TCP and UDP traffic flows that match the rule. Since the rule specifies applications (Facebook, YouTube) which can use both protocols, performance for both will be measured.

C. Encrypted traffic is not used for the performance measurement.
This is false. The firewall policy has ssl-ssh-profile "certificate-inspection" applied, meaning the FortiGate is performing SSL decryption. Once decrypted, the traffic (including Facebook and YouTube) is visible to the Application Control and SD-WAN engines, allowing them to identify the application and perform passive measurements on it.

Reference:
Fortinet FortiOS documentation on SD-WAN passive health checks, which states that passive measurements rely on actual user traffic matching the associated service rule and that a member is considered dead if no matching traffic is seen.

Explanation:
The exhibit shows the configuration of an SD-WAN zone named "HUB2" with three VPN tunnel members. The key setting is minimum-sla-meet-members being set to 2. This option dictates the minimum number of members within the zone that must be meeting their Service Level Agreement (SLA) targets before the zone is considered healthy for certain operations, including the formation of ADVPN shortcuts.

Correct Option:

C. The configuration instructs FortiGate to establish shortcuts only when at least two members meet the SLA target.
This is the direct function of the minimum-sla-meet-members 2 setting. The FortiGate will only allow critical actions, such as initiating ADVPN shortcut tunnels for this zone, if at least two of its member tunnels (HUB2-VPN1, HUB2-VPN2, HUB2-VPN3) are reporting a healthy SLA status.

Incorrect Options:

A. The configuration instructs FortiGate to choose an ADVPN shortcut based on SD-WAN information.
This describes the advpn-select option, which is visible in the exhibit but is not checked/enabled. Therefore, this behavior is not active.

B. The configuration instructs FortiGate to allow ADVPN shortcuts for the tunnels of this SD-WAN zone.
While the zone contains VPN tunnels capable of forming shortcuts, the configuration does not "allow" or "disallow" them directly. The advpn options control the behavior, and advpn-health-check is also disabled. The active control is the minimum-sla-meet-members constraint.

D. The configuration instructs FortiGate to establish shortcuts only for overlay interfaces that meet the SLA target HUB1_HC.
This is incorrect for two reasons. First, the service-sla-tie-break option, which would use the "HUB1_HC" SLA, is not enabled. Second, the minimum-sla-meet-members setting applies to the number of healthy members in the zone, not to the health of an individual member.

Reference:
Fortinet FortiOS CLI Reference for SD-WAN zones. The set minimum-sla-meet-members command is documented to define the minimum number of healthy members required before the zone can be used for services like ADVPN shortcut initiation.

Explanation:
The diagnose sys sdwan member output lists the active SD-WAN member interfaces on a specific FortiGate. By cross-referencing this output with the SD-WAN template configuration, we can identify the device. The template shows that member HUB1-VPN3 (ID:6) is only applied to branch2_fgt and branch3_fgt, NOT to branch1_fgt. Since the diagnose output is missing HUB1-VPN3, it must be from branch1_fgt.

Correct Option:

D. The diagnose output was collected on the device branch1_fgt.
The SD-WAN template explicitly shows that interface HUB1-VPN3 (member ID 6) is installed on branch2_fgt and branch3_fgt, but is absent from branch1_fgt. The diagnose output does not list member ID 6, which perfectly matches the configuration of branch1_fgt.

Incorrect Options:

A. The diagnose output shows that HUB1-VPN1 and all HUBx-VPNy members are dead.
The flag 0xd (binary 1101) indicates the member is enabled, alive, and remotely configured. A dead member would show a flag of 0x0 or 0x1. Therefore, all listed members are operational.

B. The diagnose output does not correspond to a device configured with the SD-WAN template shown in the exhibit.
The output corresponds perfectly. It shows members from both HUB1 and HUB2 zones, which aligns with the template. The specific combination of members (lacking HUB1-VPN3) matches one of the configured branch devices.

C. The diagnose output was collected on the device branch2_fgt.
This is incorrect because the template shows branch2_fgt has member HUB1-VPN3 (ID 6) installed. The diagnose output does not show this member, so it cannot be from branch2_fgt.

Reference:
Fortinet documentation on SD-WAN CLI diagnostics. The diagnose sys sdwan member command shows the interfaces that are currently active SD-WAN members on the device. The "Installation Target" column in the FortiManager SD-WAN template defines which devices receive which member configuration.

Explanation:
The standard MSSP practice is to host the hub in their own infrastructure to simplify management and leverage their shared resources. However, the hub is essentially the central termination point for all branch-to-branch and branch-to-data center traffic. When the customer's traffic patterns introduce a high volume of internal traffic or traffic destined for the customer's resources, routing it through the MSSP's external hub creates unnecessary latency and consumes the MSSP's bandwidth. In these specific high-traffic scenarios, placing the hub closer to the source (the branches) and destination (the data center) becomes a performance necessity.

Correct Options:

B. The administrator expects a large volume of traffic between the branches.
If branches primarily communicate with each other (branch-to-branch traffic), they must first tunnel to a central hub before traffic can be routed to the destination branch. If this volume is very large, routing it through the MSSP's hub introduces significant latency and consumes the MSSP's network capacity. Placing the hub in the customer's data center keeps this high-volume tunnel termination traffic entirely within the customer's control plane, optimizing performance and reducing external dependencies.

D. The majority of the branch traffic is directed to a corporate data center.
The hub device is the gateway to the corporate data center applications and resources (like ERP or file servers). If most branch traffic is destined for this data center, placing the hub directly within the data center (or HQ) eliminates the need to route this high-volume, performance-sensitive traffic externally to the MSSP's infrastructure before it is routed back inside. This ensures the lowest possible latency for accessing critical internal applications.

Incorrect Options:

A. The customer requires SIA with centralized breakout.
SIA (Security Inspection and Access) with centralized breakout means that all internet-bound traffic is sent to a central location for security inspection (like NGFW, web filtering, etc.). If the customer requires the MSSP to provide this security, the best place for the hub (or the security stack) is often within the MSSP's cloud or data center. This allows the MSSP to apply unified security policies and is a reason to keep the hub external, not move it to the customer premises.

C. The customer expects a large amount of VoIP traffic.
While VoIP is latency-sensitive, it is usually destined for either a centralized SIP trunk/PBX (covered by option D) or a cloud-based VoIP provider (which encourages a local or cloud-based breakout). High volumes of VoIP alone do not necessitate placing the hub in the customer premises unless that hub serves as the central voice gateway. The primary drivers for customer premises hub placement are high internal, data center-bound, or branch-to-branch data volumes.

Reference:
This concept is part of Managed Security Service Provider (MSSP) deployment models for SD-WAN, specifically the design considerations for Hub-and-Spoke architecture where the central hub is a traffic aggregation and security enforcement point. The decision hinges on minimizing traffic backhauling and latency for the most critical or highest volume traffic flows (internal data center access).