NSE5_SSE_AD-7.6 Practice Questions

FortiSASE supports two primary deployment modes for routing user traffic to its Points of Presence (PoPs). Endpoint mode utilizes the FortiClient agent installed on the user's device to securely tunnel all traffic to FortiSASE, providing comprehensive security and ZTNA capabilities. Secure Web Gateway (SWG) mode is an agentless deployment that uses proxy settings or PAC files to forward only web-based traffic to FortiSASE. Administrators can choose either mode depending on their specific deployment requirements and managed vs. unmanaged device policies.

A: FortiSASE officially categorizes its primary deployment methods as Endpoint mode (using FortiClient) and SWG mode, not generically as "VPN mode and Agentless mode."

C: FortiSASE does not operate only in SWG mode; it heavily utilizes Endpoint mode (FortiClient) for comprehensive traffic routing and full feature support.

D: FortiSASE does not rely on a ZTNA-only mode; it integrates ZTNA alongside SWG and CASB functionalities rather than replacing them.

1. Fortinet, Inc. "FortiSASE Administration Guide 7.x", Section: Deployment Modes (Endpoint mode and SWG mode).

2. Fortinet, Inc. "FortiSASE Architecture Guide 7.x", Section: Traffic Forwarding Methods.

To achieve a unified, comprehensive view of both SD-WAN branch traffic and FortiSASE remote user traffic, administrators must configure FortiSASE to forward its logs to an external FortiAnalyzer. Since the existing SD-WAN FortiGates already send their logs to this FortiAnalyzer, centralizing the FortiSASE logs in the same external FortiAnalyzer allows for combined analytics, correlation, and reporting across the entire hybrid network infrastructure.

A: Fortinet SOCaaS is a managed security monitoring service, not a reporting platform designed for customers to generate combined SD-WAN and SASE reports.

B: FortiSASE does not ingest logs from external FortiGates; it is not designed to act as a centralized log repository for other network devices.

D: FortiSASE cannot ingest logs from an external FortiAnalyzer; the log forwarding architecture flows from FortiSASE to FortiAnalyzer, not the reverse.

1. Fortinet, Inc. "FortiSASE Administration Guide 7.x", Section: Log Forwarding to FortiAnalyzer.

2. Fortinet, Inc. "FortiSASE Architecture Guide 7.x", Section: Analytics and Reporting Integration.

According to the SD-WAN 7.6 Core Administrator study guide and the FortiOS 7.6 Administration

Guide, the selection of a preferred member in a Best Quality (priority) rule is determined by the

measured quality metric (latency, in this case) and the link-cost-threshold.

Rule Logic (Best Quality): In the exhibit, the SD-WAN rule is configured with set mode priority, which

corresponds to the Best Quality strategy. This strategy ranks members based on the link-cost-factor,

which is set to latency.

The Link-Cost-Threshold: The exhibit shows link-cost-threshold(10), which is the default 10% value.

This threshold is designed to prevent "link flapping". To replace the current preferred member, a new

member must not only have a better latency but must be better by more than 10%.

The Calculation:

The current preferred member is HUB1-VPN1 with a real latency of 96.349 ms.

To calculate the "target" latency a lower-priority member must achieve to take over, we use the

formula: $Target = \frac{Current\_Latency}{(1 + \frac{Threshold}{100})}$.

$\frac{96.349}{1.1} = \mathbf{87.59\text{ ms}}$.

Evaluating Options:

Option A (80 ms): Since 80 ms is lower than the required 87.59 ms target, HUB1-VPN3 successfully

overcomes the 10% advantage of HUB1-VPN1 and becomes the new preferred member.

Option D (90 ms): While 90 ms is lower than 96.349 ms, it is not lower than 87.59 ms. Therefore, the

10% threshold prevents a member switch, and HUB1-VPN1 remains preferred.

Option B: Incorrect because having a "lower" latency is not enough due to the 10% threshold.

Option C: If HUB1-VPN1 moved to 200 ms, HUB1-VPN2 (at 141.278 ms) would likely become the new

preferred member before HUB1-VPN3 (at 190.984 ms).

According to the SD-WAN 7.6 Core Administrator curriculum and the FortiOS 7.6 Administration

Guide, setting common web-based services like Facebook and LinkedIn as destinations in an SD-WAN

rule is primarily accomplished through the Internet Service Database (ISDB).

Internet Service vs. Application Control: In FortiOS, there is a distinction between Internet Services

(which use a database of known IP addresses and ports to identify traffic at the first packet) and

Applications (which require the IPS engine to inspect deeper into the packet flow to identify Layer 7

signatures).

SD-WAN Efficiency: Fortinet recommends using the Internet service field for services like Facebook

and LinkedIn in SD-WAN rules because it allows the FortiGate to steer the traffic immediately upon

the first packet. If the "Application" signatures were used instead, the first session might be

misrouted because the application is not identified until after the initial handshake.

GUI Configuration: As shown in the exhibit (image_b3a4c2.png), the "Destination" section of an SD-

WAN rule includes an Internet service field by default. To steer Facebook and LinkedIn traffic, the

administrator simply clicks the "+" icon in that field and selects the entries for Facebook and LinkedIn

from the database.

Feature Visibility (Alternative): While you can enable a specific "Application" field in System >

Feature Visibility (by enabling "Application Detection Based SD-WAN"), this is typically used for less

common applications that do not have dedicated ISDB entries. For the specific "applications"

mentioned (Facebook and LinkedIn), they are natively available in the Internet service field, making

Option B the most direct and common implementation.

Why other options are incorrect:

Option A: Licensing for application signatures is part of the standard FortiGuard services and is not a

prerequisite specific only to "applications as destinations" in SD-WAN rules.

Option C: Standalone FortiGate devices fully support application-based and ISDB-based steering in

SD-WAN rules.

Option D: While enabling feature visibility would add an additional field for L7 applications, it is not a

"must" for Facebook and LinkedIn, which are already accessible via the Internet Service field

provided in the default GUI layout.

The steering bypass configuration in FortiSASE supports four destination types (Infrastructure, FQDN, Local Application, and Subnet), making option C correct. The "Apply" condition provides flexibility to apply bypass/split-tunneling destinations to On-net endpoints, Off-net endpoints, or both simultaneously, making option B correct. This design allows administrators to tailor traffic steering behavior according to endpoint network location and destination type.

A. The Apply condition is not exclusive to the Subnet type; it is available across the destination configuration, not limited to a single type.

D. The Apply condition explicitly supports both On-net and Off-net simultaneously, directly contradicting this "either/or only" restriction.

1. Fortinet Document Library – FortiSASE Administration Guide, "Configuring endpoint profiles / Endpoint provisioning – Split tunneling and steering bypass destinations" section. (docs.fortinet.com, FortiSASE Admin Guide).

2. Fortinet FortiSASE Administration Guide, "Deploying SASE agent / SIA for agent-based remote users – Bypass destinations (Destination types: FQDN, Subnet, Local Application, ISDB/Infrastructure)."

3. Fortinet NSE Training Institute – FortiSASE Course (NSE 5 SSE AD 7.x) Courseware, Module on "Secure Internet Access (SIA) and Endpoint Configuration – Steering and split tunneling."

4. Fortinet Document Library – FortiSASE Reference, "Apply condition (On-net, Off-net, Both) for split tunneling / bypass rules."

Note of caution: I was unable to verify the exact page numbers, paragraph identifiers, and specific section citations against the live official Fortinet documentation for FortiSASE (NSE 5 SSE AD 7). The references above indicate the correct documents and sections where this information resides, but I cannot confirm precise page/paragraph numbers without accessing the current published guide. FortiSASE is a cloud service updated frequently, and UI-specific details (exact destination type names and Apply condition options) may vary by release. I recommend confirming against the current FortiSASE Administration Guide at docs.fortinet.com for your specific version before relying on this for exam certification.

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/NSE5_SSE_AD-7.6/page_11_img_2.jpg

When an SD-WAN performance SLA is configured with the probe mode set to 'Prefer Passive', FortiGate relies on existing TCP traffic to passively measure latency, jitter, and packet loss, eliminating the overhead of active probes. Therefore, passive monitoring occurs only if TCP traffic is actively passing through the SD-WAN member. If TCP traffic ceases, FortiGate automatically switches to active monitoring (sending active probes) to ensure the link's health is still tracked. Once in active mode, FortiGate will continue active probing for a default period of 3 minutes before attempting to fall back to passive monitoring again.

A: Traffic subject to passive monitoring cannot be offloaded to hardware (NP processors) because the CPU must inspect the TCP packets to calculate SLA metrics.

B: Passive monitoring relies exclusively on TCP traffic (analyzing sequence numbers and acknowledgments to measure latency and loss), not ICMP traffic.

C: While passive monitoring relies on traffic, the system automatically switches to active monitoring when traffic stops, ensuring dead members are still detected by the SLA rule.

1. Fortinet FortiOS 7.2 Administration Guide. Section: SD-WAN > Performance SLA > Performance SLA probe modes (Passive WAN measurement).

2. Fortinet NSE 7 SD-WAN 7.2 Courseware. Module: SD-WAN Performance SLA and Health Checks.

According to the SD-WAN 7.6 Core Administrator study guide and the FortiOS 7.6 Administration

Guide, the selection process for the Best Quality (priority) strategy depends on two primary factors:

the measured link quality metric and the configured member priority order.

Based on the provided exhibit (image_b40dfc.png), we can determine the following:

Strategy and Metric: The rule is in Mode(priority) (Best Quality) using link-cost-factor(packet loss).

Strict Comparison: The link-cost-threshold is set to 0. This means there is no "advantage" given to the

current preferred link; the FortiGate performs a strict comparison where the link with the objectively

best metric is chosen.

Tie-Breaker Logic: When multiple links have the same packet loss, the FortiGate uses the Member

Priority Order defined in the rule (set priority-members 6 4 5) as the tie-breaker.

Member 6 (HUB1-VPN3) is the highest priority.

Member 4 (HUB1-VPN1) is the second priority.

Member 5 (HUB1-VPN2) is the lowest priority.

Current State: HUB1-VPN1 is currently selected because its packet loss (2.000%) is lower than HUB1-

VPN2 (4.000%) and HUB1-VPN3 (12.000%). Even though HUB1-VPN3 has a higher configuration

priority, its significantly higher packet loss prevents it from being chosen.

Evaluation of Options:

Option A (Verified): If all three members have the same packet loss (e.g., they all show 2%), the

quality metrics are equal. The SD-WAN engine then refers to the priority-members list. Since HUB1-

VPN3 (Seq 6) is the first member in that list, it will immediately become the new preferred member.

Option B: If HUB1-VPN1 reaches 4%, it matches HUB1-VPN2 (4%). HUB1-VPN3 remains at 12%. The

system will choose between VPN1 and VPN2. Since VPN1 (Seq 4) is higher in the priority list than

VPN2 (Seq 5), HUB1-VPN1 stays preferred.

Option C: If HUB1-VPN1 reaches 12%, it matches HUB1-VPN3. However, HUB1-VPN2 is still better at

4.000%. Therefore, HUB1-VPN2 would become the new preferred member, not HUB1-VPN3.

Option D: If HUB1-VPN3 drops to 4%, it matches HUB1-VPN2. However, HUB1-VPN1 is still the best

link at 2.000%, so it remains selected.

FortiSASE is built around three primary use cases to secure remote users. Secure Internet Access (SIA) protects users accessing the public internet using a cloud-based firewall and secure web gateway. Secure Private Access (SPA) provides secure, zero-trust access to internal corporate applications hosted in private clouds or on-premises data centers. Secure SaaS Access (SSA) utilizes Cloud Access Security Broker (CASB) functionalities to secure and control access to Software-as-a-Service (SaaS) applications.

D: Secure VPN Access (SVA) is not a defined FortiSASE use case; FortiSASE uses ZTNA and SPA for private access rather than traditional VPN terminology.

E: Secure Browser Access (SBA) is not a standard FortiSASE use case; while browser isolation is a feature, the core use cases are SIA, SPA, and SSA.

1. FortiSASE Architecture Guide, "Core Use Cases" section.

2. Fortinet NSE 5 FortiSASE Courseware, "Introduction to FortiSASE" module.

For FortiOS SD-WAN to function and steer traffic, three fundamental components are mandatory. First, Interfaces must be configured and assigned to the SD-WAN zone as members to provide the physical or logical egress paths. Second, Routing must be established, typically via a default static route pointing to the SD-WAN virtual interface, ensuring the FortiGate's routing table directs outbound traffic to the SD-WAN engine. Third, Firewall policies must be created to permit traffic from the internal ingress network to the SD-WAN interface. Without these three elements, traffic will either not reach the SD-WAN engine, lack a valid egress path, or be dropped by the firewall's default deny policy.

B: Security profiles are optional Unified Threat Management (UTM) features applied to firewall policies for inspection; they are not required for basic SD-WAN traffic steering.

E: Traffic shaping is an optional Quality of Service (QoS) feature used to control bandwidth allocation, not a mandatory requirement for SD-WAN rules to function.

1. Fortinet FortiOS 7.2 Administration Guide. Section: SD-WAN > SD-WAN configuration > Basic SD-WAN configuration.

2. Fortinet NSE 7 SD-WAN 7.2 Courseware. Module: SD-WAN Configuration and Routing.