Fortinet NSE5_SSE_AD-7.6 Fortinet NSE 5 - FortiSASE and SD-WAN 7.6 Core Administrator Exam Practice Test

According to the FortiSASE 7.6 Architecture Guide and Administration Guide, the Site-based remote user internet access use case is the only deployment model that completely eliminates the need for individual endpoint configuration.

Centralized Enforcement: In a site-based deployment, a " thin edge " device (such as a FortiExtender or a FortiGate in LAN extension mode) is installed at the remote site. This device establishes a secure tunnel to the FortiSASE Point of Presence (PoP).

Zero Endpoint Configuration: Because the traffic redirection happens at the network gateway level, individual devices (laptops, IoT devices, mobile phones) behind the site-based device do not require any specialized software or settings. They simply connect to the local network as they would normally, and their traffic is automatically secured by the SASE cloud.

Comparison with Other Modes:

Agent-based (Option B): Requires the installation and maintenance of FortiClient software on every device, often managed via MDM tools.

Agentless (Option A): While it doesn ' t need an agent, it typically requires the configuration of Explicit Web Proxy settings or the distribution of a PAC (Proxy Auto-Configuration) file via GPO or SCCM to each device ' s browser.

ZTNA (Option D): Generally requires an endpoint agent (FortiClient) to perform posture checks and identity verification, involving significant endpoint-level configuration.

Why other options are incorrect:

Option A: Agentless mode is often confused with being " configuration-free, " but it still requires endpoints to be pointed toward the FortiSASE proxy.

Option B: This is the most configuration-intensive mode, requiring full software lifecycles for every endpoint.

Option D: ZTNA is an access methodology that adds configuration complexity (tags, certificates, posture checks) rather than minimizing it.

According to the FortiSASE 7.6 Feature Administration Guide and the latest updates to the NSE 5 SASE curriculum, FortiSASE has introduced native lifecycle management for FortiClient agents to reduce the operational burden on IT teams who previously relied solely on third-party MDM (Mobile Device Management) or GPO (Group Policy Objects) for every update.

The Endpoint Upgrade feature, found under System > Endpoint Upgrade in the FortiSASE portal, allows administrators to perform the following:

Centralized Version Control: Administrators can see which versions are currently deployed and which " Recommended " versions are available from FortiGuard.

Scheduled Rollouts: You can choose to upgrade all endpoints or specific endpoint groups at a designated time, ensuring that upgrades do not disrupt business operations.

Status Monitoring: The portal provides a real-time dashboard showing the progress of the upgrade (e.g., Downloading, Installing, Reboot Pending, or Success).

Manual vs. Managed: While MDM is still highly recommended for the initial onboarding (the first time FortiClient is installed and connected to the SASE cloud), all subsequent upgrades can be handled natively by the FortiSASE portal.

Why other options are incorrect:

Option B: Manual upgrades are inefficient for large-scale deployments (~400 users in this scenario) and are not the intended " feature-rich " solution provided by FortiSASE.

Option C: " Onboarding " refers to the initial setup. Re-onboarding every time a version changes would be redundant and counterproductive.

Option D: While the system can manage the upgrade, it is not " auto-upgraded on demand " by the client itself without administrative configuration in the portal. The administrator must still define the target version and schedule.

According to the FortiSASE 7.6 Administration Guide and the FCP - FortiSASE 24/25 Administrator curriculum, the Agentless deployment mode—commonly referred to as Secure Web Gateway (SWG) mode—is a vital component of the Secure Internet Access (SIA) framework.

Deployment Mechanism: In an agentless deployment, FortiSASE functions as an explicit web proxy. This is achieved by distributing a PAC (Proxy Auto-Configuration) file to the user ' s browser, which instructs the device to send its web traffic to the nearest FortiSASE Point of Presence (PoP).

Target Use Case: This mode is specifically designed for unmanaged endpoints, such as those used by contractors, partners, or temporary workers, where the organization does not have the authority or capability to install the FortiClient agent.

Security Capabilities: Even without an agent, FortiSASE applies a full security stack to the redirected traffic. This includes Web Filtering, Anti-Malware, SSL Inspection, and Inline-CASB to secure HTTP and HTTPS sessions.

Protocol Limitations: Because it relies on proxy settings, this mode is limited to web protocols (HTTP/HTTPS) and does not inherently secure non-web traffic like ICMP, DNS, or custom TCP/UDP applications unless they are specifically proxied.

Why other options are incorrect:

Option A: While it provides secure browsing, session isolation (RBI) is a specific feature that can be used in either mode; the defining characteristic of the agentless use case is the proxy-based redirection for unmanaged devices.

Option C: A PAC file can only secure web traffic (protocols that support proxying), not non-web traffic protocols.

Option D: Agentless mode is the opposite of requiring FortiClient; ZTNA tags generally require the FortiClient agent to provide the necessary telemetry for tag evaluation.

The FortiSASE 7.6 Administration Guide outlines the standard onboarding procedures for deploying the FortiClient agent to remote endpoints. There are two primary user-facing delivery methods:

Download from the FortiSASE portal (Option B): Administrators can provide users with access to the FortiSASE portal where they can directly download a pre-configured installer. This installer is uniquely tied to the organization’s SASE instance, ensuring the client automatically registers to the correct cloud EMS upon installation.

Invitation Email (Option C): This is the most common administrative method. The FortiSASE portal (via its integrated EMS) allows administrators to send an invitation email to specific users or groups. This email contains direct download links for various operating systems (Windows, macOS, Linux) and the necessary invitation code for zero-touch registration.

Why other options are incorrect:

Option A: While third-party stores (like the App Store or Google Play) are used for mobile devices, " zero-touch installation through a third-party store " is not the standard curriculum-defined method for laptops (Windows/macOS) in a SASE environment.

Option D: FortiSASE does not use a direct " API to the user ' s laptop " for automatic installation. While MDM/GPO (centralized deployment) is supported, it is not described as an API-based auto-installation in the core curriculum.

According to the FortiSASE 7.6 Architecture Guide and FCP - FortiSASE 24/25 Administrator materials, the solution is built around three primary use cases that support a hybrid workforce:

Secure Internet Access (SIA): This enables secure web browsing by applying security profiles such as Web Filter, Anti-Malware, and SSL Inspection in the SASE cloud. It protects remote users from internet-based threats regardless of their location.

Secure Private Access (SPA): This provides granular, explicit access to private applications hosted in data centers or the cloud. It is achieved through ZTNA (Zero Trust Network Access) for session-based security or through SD-WAN integration where FortiSASE acts as a spoke to an existing corporate SD-WAN hub.

SaaS Security: FortiSASE utilizes Inline-CASB and Shadow IT visibility to monitor and control the use of cloud applications. Data Loss Prevention (DLP) is integrated into these workflows to prevent sensitive corporate data from being uploaded to unauthorized SaaS platforms.

Why other options are incorrect:

Option A: While it mentions SD-WAN and Shadow IT, it misses the core definition of SIA (secure web browsing) which is the primary driver for SASE deployments.

Option B: Remote Browser Isolation (RBI) is typically applied to risky or uncategorized websites, not " all websites, " due to the high performance and resource overhead.

Option D: FortiSASE is designed to protect data in motion (via security profiles) as well as data stored in sanctioned cloud apps, not " at rest only " .

FortiSASE supports SAML, LDAP, and RADIUS as authentication mechanisms applicable to remote-user identity verification. The FortiSASE Administrator Study Guide explicitly identifies its authentication-server configuration objectives as describing remote authentication with LDAP and RADIUS and SAML single sign-on (SSO). It further states that FortiSASE supports authentication through the local database, RADIUS, LDAP, and SAML for SSO.

SAML (A) provides federated SSO by allowing FortiSASE, acting as the service provider, to rely on an external identity provider for user authentication. SAML SSO is specifically supported for FortiSASE SWG and VPN deployments.

LDAP (C) enables integration with directory services such as Microsoft Active Directory. FortiSASE can query directory information and authenticate users against the LDAP infrastructure; LDAPS can be enabled for protected communications. The guide notes an important limitation: LDAP authentication is unavailable for SIA remote users using IPsec VPN, but LDAP remains a supported FortiSASE authentication source.

RADIUS (E) provides centralized remote authentication and supports PAP, CHAP, MS-CHAP, and MS-CHAPv2 authentication methods.

OIDC and TACACS+ are not identified as FortiSASE remote-user authentication sources in this course objective.

The correct answer is B. SSO. The FortiSASE Administrator Study Guide explicitly states that enabling SSO authentication overrides any other previously created authentication methods, including the local user database, LDAP, and RADIUS.

FortiSASE implements SSO for endpoint users through SAML. In this design, FortiSASE functions as the service provider (SP), while authentication is performed by an external identity provider (IdP), such as Okta, FortiAuthenticator, or another supported IdP. The user database therefore does not need to be hosted directly on FortiSASE. Instead, FortiSASE redirects the user to the IdP and uses the resulting SAML assertion to establish the authenticated SSO session. The study guide confirms that SSO can be configured for both VPN users and Secure Web Gateway (SWG) users.

A. Local and C. RADIUS are authentication sources that SSO supersedes when SSO is enabled. D. MFA is an additional authentication-strength mechanism rather than the FortiSASE authentication mode described as overriding previously configured methods.

Study Guide Reference: User Onboarding and Additional Features > Configuring SSO > VPN User SSO / SWG User SSO, FortiSASE Administrator Study Guide, page 56.

The exhibit indicates that the overlay-factories zone currently contains no SD-WAN member. In the GUI, zones containing members can be expanded to display their member interfaces; for example, HUB1 is expanded and shows HUB1-VPN1, HUB1-VPN2, and HUB1-VPN3. The overlay-factories entry does not display any member beneath it. The SD-WAN study material explains that an SD-WAN zone uses one or more interface members and that a zone used for traffic steering must contain at least one member. SD-WAN_7.6_Enterprise_Administr… The exhibit alone does not establish that overlay-factories can safely be deleted because other configuration references can prevent deletion. Likewise, virtual-wan-link is the default SD-WAN zone and cannot simply be treated as a removable user-created zone. Therefore, the directly supported conclusion is that overlay-factories has no member .

================

FortiSASE endpoint upgrade rules provide controlled deployment of the latest supported FortiClient version. The FortiSASE study material specifies that administrators can either perform an upgrade immediately or configure a scheduled start time, with the scheduled deployment based on the endpoint ' s local time. It also identifies endpoint groups as the targeting mechanism and explains that automatic reboot behavior is configurable rather than unconditional.

Therefore, A is correct. Fortinet ' s Endpoint Upgrade documentation provides the exact scheduling behavior: when Scheduled (endpoint local time) is configured and the endpoint ' s clock has already passed the selected time, FortiClient installation is deferred until the next day at that selected time.

B is incorrect because upgrade rules cannot be assigned to a user group or user object; they apply to computer/device groups or computer/device objects. C is incorrect because only the Immediate option begins installation immediately; a scheduled deployment follows its configured local schedule. D is incorrect because the automatic reboot setting applies to Windows endpoints. Fortinet specifically states that macOS endpoints do not require a reboot to complete the FortiClient installation.

Study Guide Reference: Endpoint Management > Endpoint Upgrade; FortiSASE Enterprise Administrator Study Guide, Endpoint Management.

===============

In the SD-WAN 7.6 Core Administrator curriculum, the " Prefer Passive " probe mode is a hybrid monitoring strategy designed to minimize the overhead of synthetic traffic (probes) while maintaining link health visibility. According to the FortiOS 7.6 Administration Guide and the SD-WAN Study Guide, the behavior and impacts are as follows:

TCP Traffic Requirement (Option E): Passive monitoring relies on the FortiGate’s ability to inspect actual user traffic to calculate health metrics such as Latency, Jitter, and Packet Loss. Specifically, it uses TCP traffic (by analyzing TCP sequence numbers and timestamps to calculate Round Trip Time - RTT). If user traffic is flowing through the member interface, the FortiGate uses those real-world sessions for SLA calculations instead of sending its own probes.

Inability to Detect Dead Members (Option C): A significant limitation of passive monitoring is that it cannot distinguish between a " dead " link and an " idle " link. If there is no traffic, the passive monitor has no data to analyze. Consequently, while in passive mode, the SD-WAN engine cannot detect a dead member. To mitigate this, " Prefer Passive " includes a fail-safe: if no traffic is detected for a specific period (typically 3 minutes), the FortiGate will automatically switch to Active mode (sending ICMP/TCP pings) to verify if the link is actually alive.

Why other options are incorrect:

Option A: Passive monitoring generally disables hardware offloading (ASIC) for the monitored traffic. This is because the CPU must inspect every packet header to calculate performance metrics; if the traffic were offloaded to the Network Processor (NP), the CPU would not see the packets, rendering passive monitoring impossible.

Option B: While active probes often use ICMP, passive monitoring is specifically designed for TCP traffic because the TCP protocol ' s ACK structure allows for accurate RTT and loss calculation without synthetic packets.

Option D: The " 3-minute " timer is actually the trigger to switch from passive to active when traffic is absent, not the fallback timer to return to passive. The fallback to passive happens as soon as valid TCP traffic is detected again.

According to the FortiSASE 7.6 Administration Guide and the FCP - FortiSASE 24/25 Administrator study materials, FortiSASE supports three primary external (remote) authentication sources to verify the identity of remote users (SIA and SPA users). These sources allow organizations to leverage their existing identity infrastructure for seamless onboarding and policy enforcement:

Security Assertion Markup Language (SAML) (Option A): This is the most common and recommended method for modern SASE deployments. FortiSASE acts as a SAML Service Provider (SP) and integrates with Identity Providers (IdP) such as Microsoft Entra ID (formerly Azure AD), Okta, or FortiAuthenticator. This enables Single Sign-On (SSO) and Multi-Factor Authentication (MFA).

Lightweight Directory Access Protocol (LDAP) (Option C): FortiSASE can connect to on-premises or cloud-based LDAP servers (such as Windows Active Directory). This allows the administrator to map existing AD groups to FortiSASE user groups for granular security policy application.

Remote Authentication Dial-in User Service (RADIUS) (Option E): RADIUS is supported for organizations that use centralized authentication servers or traditional MFA solutions (like RSA SecurID). FortiSASE can query a RADIUS server to validate user credentials before granting access to the SASE tunnel.

Why other options are incorrect:

OpenID Connect (OIDC) (Option B): While OIDC is a modern authentication protocol similar to SAML, FortiSASE ' s primary integration for external Identity Providers is currently standardized on SAML 2.0.

TACACS+ (Option D): Terminal Access Controller Access-Control System Plus is primarily used for administrative access (AAA) to network devices (like logging into a FortiGate CLI or FortiManager). It is not used for end-user VPN or SASE authentication in the Fortinet ecosystem.

According to the SD-WAN 7.6 Core Administrator curriculum, to implement an SD-WAN solution that ensures high network availability for business-critical applications while managing costs, the administrator must configure at least two WAN links.

SD-WAN Fundamentals: SD-WAN operates by creating a virtual overlay across multiple physical or logical transport links (e.g., broadband, LTE, MPLS). Without at least two links, the SD-WAN engine has no alternative path to steer traffic toward if the primary link fails or degrades.

Cost Management: By using multiple links, administrators can implement the Lowest Cost (SLA) or Maximize Bandwidth strategies. This allows the site to use a low-cost broadband connection for primary traffic and only failover to a " pay-per-use " backup (like LTE) when the primary link ' s quality falls below the defined SLA target.

High Availability (Link Level): While a " High Availability (HA) cluster " (Option C) provides device redundancy (protecting against a hardware failure of the FortiGate itself), it does not address link redundancy or steering, which are the core functions of SD-WAN for application uptime.

Why other options are incorrect:

Option A: Using a mid-range device refers to hardware capacity but does not solve the requirement for link-level redundancy and cost-steering logic.

Option B: Dynamic routing (like BGP or OSPF) is often used with SD-WAN in large topologies, but for a small site, the primary mechanism for meeting availability and cost goals is the configuration of the SD-WAN member links and rules themselves.

Option C: HA clusters protect against hardware failure, but the question specifically asks about ensuring availability for applications while limiting backup link costs, which is a traffic-steering (SD-WAN) requirement rather than a hardware-redundancy requirement.

B and C are correct. The FortiSASE Administrator Study Guide explicitly states that FortiClient can be provisioned using installers embedded with an invitation code obtained from the FortiSASE portal. Administrators can then deploy the installer through enterprise software-distribution mechanisms such as Microsoft System Center Configuration Manager (SCCM) or Group Policy Object (GPO). The same installer can also be distributed through mobile device management (MDM) software.

The study guide also explicitly identifies manual installation as a supported deployment method: administrators can distribute the FortiClient installer directly to end users and have them install it on their endpoints. Consequently, C is also correct.

Invitation codes are important because they allow FortiClient to register with and become managed by the appropriate FortiSASE instance. The Enterprise Administrator material further explains that the default invitation code is embedded in preconfigured Windows and macOS installers, while custom invitation codes can place newly onboarded endpoints into specified endpoint groups and associated profiles.

A, D, and E are incorrect because they unnecessarily restrict supported deployment methods or incorrectly claim that an invitation code is not required.

Study Guide Reference: User Onboarding and Additional Features > FortiClient Deployment; Endpoint Management > Invitation Codes.

In the SD-WAN 7.6 Core Administrator curriculum, steering " local-out " traffic (traffic generated by the FortiGate itself, such as DNS queries, FortiGuard updates, or diagnostic pings) requires specific configuration because this traffic follows a different path than " forward " traffic.

Individual Configuration (Option A): By default, local-out traffic bypasses the SD-WAN engine and uses the standard system routing table (RIB/FIB). To use SD-WAN rules for specific features like DNS or RADIUS, you must individually enable the sdwan interface-select-method within that feature ' s configuration (e.g., config system dns or config user radius).

Default Steerable Traffic (Option B): In FortiOS 7.6, while most local-out traffic is excluded from SD-WAN by default, the system is designed so that when SD-WAN is active, it primarily considers SD-WAN rules for specific diagnostic local-out traffic—specifically ping and traceroute—to allow administrators to verify path quality using the same logic as user traffic.

Why other options are incorrect:

Option C: Local-out traffic can be steered using any SD-WAN strategy (Manual, Best Quality, etc.), provided the interface-selection-method is set to sdwan.

The correct answer is A. FortiSASE provides both API-based CASB and inline CASB. Fortinet describes FortiSASE Secure SaaS Access as using a dual-mode CASB architecture that combines inline inspection with out-of-band, API-based inspection. This provides visibility and control over SaaS usage while protecting both data in motion and data at rest.

Inline CASB operates directly in the traffic path between the endpoint and SaaS application. FortiSASE uses capabilities such as application control, web filtering, SSL deep inspection, and DLP to identify applications, enforce SaaS access controls, inspect traffic, and protect data in motion. The study guide specifically describes the inline component as recognizing SaaS application traffic and using protocol decoders and HTTP inspection to enforce controls.

The API-based or out-of-band CASB connects directly to supported cloud applications through APIs. Its principal role is inspecting and assessing data at rest that has already been stored in the SaaS service. The FortiSASE Enterprise material likewise confirms that FortiCASB provides cloud/API-based capabilities while FortiSASE simultaneously provides inline CASB through web filter and application control.

Therefore, B and C incorrectly limit FortiSASE to one CASB mode, while D incorrectly makes Security Fabric integration a prerequisite.

Study Guide Reference: SIA and SSA > Secure SaaS Access > Inline CASB and Out-of-Band CASB, pages 105–108.