FCSS_SASE_AD-25 Practice Questions

Zero-trust tags are fundamental to Fortinet's ZTNA framework. Their primary advantage is enabling dynamic, posture-based access control. Tags are assigned to endpoints by FortiClient EMS based on a variety of security posture checks (such as OS version, running processes, or domain membership). This tag, representing the endpoint's security state, is then used in ZTNA rules on the FortiGate or FortiSASE PoP. These rules explicitly use the tags to grant or deny access to specific protected network resources, thereby enforcing the zero-trust principle of "never trust, always verify."

C. Zero-trust tags can be used to create multiple endpoint profiles which can be applied to different endpoints: This is incorrect. The relationship is reversed; endpoint profiles in FortiClient EMS contain the rules that assign zero-trust tags to endpoints, not the other way around.

D. Zero-trust tags can be used to allow secure web gateway (SWG) access: This is not a primary advantage. While tags can be used in firewall policies, their specific and defining purpose within the FortiSASE architecture is for ZTNA rules governing access to private applications, not for general SWG policies.

1. FortiSASE Administration Guide: In the "ZTNA for SaaS" section

it states

"ZTNA rules define the users and user groups that can access a server

the ZTNA tags that must be present on the endpoint to access the server..." This directly supports option A.

2. FortiClient EMS Administration Guide: Under "Zero Trust Tags

" the documentation explains

"You can configure ZTNA tagging rules to check endpoints for security posture and apply tags to endpoints that match the configured criteria." This directly supports option B.

3. Fortinet Zero Trust Network Access (ZTNA) Architecture Guide: The guide details the workflow: "FortiClient EMS...applies tags to endpoints based on their security posture... The FortiGate ZTNA access proxy enforces ZTNA policies by checking device identity and security posture tags." This confirms that tags represent posture (supporting B) and are used for enforcement (supporting A).

FortiExtender can be connected as a FortiSASE LAN extension using two primary methods. The first is an automated, zero-touch provisioning (ZTP) process. In this method, the FortiExtender is registered in FortiCare and, upon its first internet connection, it contacts the FortiZTP service, which directs it to the appropriate FortiSASE instance for configuration. The second method is manual deployment, where an administrator directly accesses the FortiExtender's interface (GUI or CLI) and statically configures the FortiSASE domain name as its management discovery server. Both methods establish the initial control plane connection for provisioning.

B. Enable Control and Provisioning Wireless Access Points (CAPWAP) access on the FortiSASE portal.

CAPWAP is a protocol used for managing wireless access points (FortiAPs), not for deploying a FortiExtender device as a LAN extension.

D. Configure an IPsec tunnel on FortiSASE to connect to FortiExtender.

The IPsec tunnel is the secure data plane that is automatically established after the FortiExtender is successfully deployed and provisioned by FortiSASE, not the initial deployment method itself.

1. Fortinet Docs | FortiSASE 23.3 Administration Guide

LAN Extension > Deployment workflow.

This section explicitly outlines the two deployment methods: "You can deploy a FortiExtender as a FortiSASE LAN extension using one of the following methods: Zero-touch provisioning (ZTP) deployment... Manual deployment..." This directly supports options A and C.

2. Fortinet Docs | FortiSASE 23.3 Administration Guide

LAN Extension > Manual deployment.

This section details the manual process: "In the FortiExtender GUI

go to Settings > Management. For Discovery Type

select Static. For Static Server Address

enter the FortiSASE domain name..." This provides the specific steps for option C.

3. Fortinet Docs | FortiSASE 23.3 Administration Guide

LAN Extension > Deployment workflow > Step 4.

This step clarifies the role of the IPsec tunnel: "FortiSASE pushes the configuration to the FortiExtender

which includes creating an IPsec VPN tunnel between the FortiExtender and FortiSASE." This confirms that the tunnel is a result of deployment

making option D incorrect.

A core principle of Zero Trust Network Access (ZTNA) is to "never trust, always verify" both the user and the device before granting access to an application. FortiSASE implements this by using the FortiClient agent installed on the endpoint. FortiClient continuously assesses the device's security posture by checking various attributes, such as operating system version, patch levels, and the status of security software. This information is converted into ZTNA tags, which are used to enforce dynamic, granular access policies, ensuring that only compliant devices can connect to protected resources.

A: FortiSASE is a cloud-delivered SASE service. It does not involve deploying customer-premise hardware firewalls for network segmentation.

B: While Fortinet products can integrate with SDN, this is not the primary mechanism through which FortiSASE specifically supports ZTNA principles, which focus on user and device verification.

D: ZTNA is a modern replacement for traditional VPNs. While it provides secure remote access, its key function is granting granular, application-level access based on verification, not broad network-level access typical of VPNs.

1. FortiSASE Administration Guide: In the "ZTNA" section

the documentation explains the ZTNA workflow. It states

"FortiClient Telemetry is sent to FortiSASE... FortiSASE uses this information to check the endpoint’s security posture against the ZTNA tagging rules... ZTNA tags are applied to the endpoint." This confirms the role of endpoint attribute identification for posture checks. (Reference: FortiSASE Administration Guide

"ZTNA" chapter).

2. Fortinet Zero Trust Network Access (ZTNA) Solution Guide: This document outlines the core components of Fortinet's ZTNA solution. It emphasizes the role of FortiClient in providing "dynamic endpoint posture check and ongoing verification

" which is essential for the ZTNA framework. (Reference: Fortinet Zero Trust Network Access (ZTNA) Solution Guide

"Fortinet ZTNA Components" section).

3. FortiClient and FortiSASE FAQ: This document clarifies the relationship

stating

"FortiClient is the unified agent for endpoints that provides endpoint protection

remote access

and ZTNA... FortiClient connects to FortiSASE to enforce security policies." This highlights the agent's role in posture assessment for ZTNA enforcement via FortiSASE. (Reference: FortiClient and FortiSASE FAQ).

The network topology explicitly shows an ADVPN (Auto-Discovery VPN) setup where FortiSASE functions as a spoke. When a remote user accesses a resource on Branch-2 (another spoke), the initial traffic is routed to HUB-2 based on the configured static route. Upon receiving this spoke-to-spoke traffic, HUB-2, as the ADVPN hub, facilitates the creation of a dynamic, on-demand "shortcut" tunnel directly between the FortiSASE security PoP and the Branch-2 FortiGate. A new, more specific route for this path is dynamically installed in the routing tables of both spokes. All subsequent traffic then flows directly over this shortcut, bypassing the hub. Therefore, the ultimate routing mechanism uses a dynamic route for a direct path, as enabled by the ADVPN protocol.

A: This describes only the initial traffic path before the ADVPN shortcut is established. It fails to account for the primary, optimized routing function of ADVPN.

B: The static route shown in the exhibit directs traffic to the hub (HUB-2), not directly to the branch. The direct path is established dynamically, not statically.

C: The static route in the exhibit clearly specifies the gateway for the Branch-2 network is HUB-2 (10.2.0.1), not HUB-1.

1. FortiSASE Administration Guide: In the section on Secure Private Access

the guide details integration with FortiGate secure SD-WAN. It states

"When a spoke (including FortiSASE) needs to send traffic to another spoke

it initially sends the traffic to the hub. The hub forwards the traffic...and also facilitates the two spokes to establish a dynamic IPsec tunnel

called a shortcut tunnel

between them. Subsequent traffic between the spokes flows through the shortcut tunnel

bypassing the hub." This confirms the process of initial routing via the hub

followed by the creation of a direct

dynamic path. (Search for "ADVPN" and "shortcut tunnel" in the FortiSASE Administration Guide for the relevant version).

2. FortiOS Administration Guide (SD-WAN Section): The ADVPN chapter explains that shortcut tunnels are created on-demand and that routes for these shortcuts are dynamically added to the routing table. This confirms that the route for the direct path described in the correct answer is dynamic. (Refer to the "ADVPN" section in the FortiOS Handbook).

The user connection monitor displays "fctanonymous..." in the user column, which is the standard format FortiSASE uses when log anonymization is enabled. This feature is designed to protect user privacy by replacing personally identifiable information (PII), such as usernames, with a randomized string in logs and reports. To resolve this and display the actual usernames, the administrator must navigate to the system settings within the FortiSASE portal and disable the "Log Anonymization" feature.

B. Add more endpoint licenses on FortiSASE: A licensing issue would typically prevent users from connecting or accessing features, not obfuscate their usernames in monitoring logs.

C. Configure the username using FortiSASE naming convention: The issue is not with the user's original name format but with FortiSASE actively replacing it with an anonymous string for privacy.

D. Change the deployment type from SWG to VPN: The deployment mode determines how traffic is captured. Log anonymization is a separate global setting that affects reporting regardless of the connection method.

1. FortiSASE Administration Guide (23.3): In the "System > Settings" section

under "Log & Report Settings"

the "Log Anonymization" feature is described. The guide states

"Enable to anonymize user information in logs and reports." This directly confirms that this setting is responsible for the observed behavior. (Reference: FortiSASE 23.3 Administration Guide

p. 118

"System > Settings").

2. FortiSASE Administration Guide (23.3): The "Monitor > User Connection" page is designed to display information about connected users. The guide explains the columns

including the "User" column. When log anonymization is active

this field is populated with the anonymous identifier instead of the actual username. (Reference: FortiSASE 23.3 Administration Guide

p. 98

"Monitor > User Connection").

To enable and operate the FortiSASE Managed Security Service Provider (MSSP) feature, two primary requirements must be met. First, the root account must have a FortiCloud Premium subscription (or be a qualified partner account), as this unlocks the necessary MSSP functionalities. Second, administrators who will manage the customer tenants must be created as Identity & Access Management (IAM) users within the root FortiCloud account. These IAM users are then assigned specific MSSP roles using Role-Based Access Control (RBAC) through the FortiCloud IAM portal, which grants them the permissions to access and manage the sub-accounts.

B: MSSP administrator accounts and their primary permissions are configured in the FortiCloud IAM portal, not directly within the FortiSASE portal itself.

D: FortiSASE is inherently a multi-tenant platform. You enable the MSSP program on your account to manage tenants, you do not enable multi-tenancy as a separate feature.

1. FortiSASE Administration Guide 23.3: In the "MSSP" section

under "Prerequisites

" the guide states

"To use the FortiSASE MSSP solution

you must have a FortiCloud Premium account." This directly supports option A.

2. FortiSASE Administration Guide 23.3: In the "MSSP" section

under "Workflow

" the guide details the process of configuring MSSP administrators: "You can add Identity & Access Management (IAM) users to the MSSP account and assign them to an IAM profile that allows them to access and manage sub accounts." This workflow

centered on the FortiCloud IAM portal and RBAC

directly supports option C.

3. FortiSASE Administration Guide 23.3: The "MSSP" section's introduction describes the architecture: "FortiSASE supports a multi-tenancy architecture that allows an MSSP to manage multiple customers." This shows multi-tenancy is an inherent characteristic

not a feature to be enabled

making option D incorrect.

The policy type used to control traffic from a FortiClient endpoint to FortiSASE for secure internet access (SIA) is the Secure Web Gateway (SWG) policy. FortiSASE uses SWG policies to inspect internet-bound traffic from remote users. These policies apply security profiles such as Web Filter, Antivirus, Application Control, and Intrusion Prevention System (IPS) to enforce corporate security standards and protect users from web-based threats. The VPN tunnel is the transport mechanism that directs traffic to the FortiSASE point of presence (PoP), but the SWG policy is what actively controls and secures the traffic according to defined rules.

A. VPN policy: This is incorrect because while a VPN tunnel is used for connectivity, "VPN policy" is too general. The specific policy that inspects and controls the content of the internet traffic is the SWG policy.

B. thin edge policy: This is incorrect as it typically refers to policies for hardware-based thin edge devices (like FortiExtenders or small SD-WAN appliances), not for software-based FortiClient endpoints.

C. private access policy: This is incorrect because private access policies (part of ZTNA) are used to control access to internal, private applications, not for general secure internet access.

1. FortiSASE Administration Guide: In the "Secure Internet Access" section

the guide details the configuration of "Security" policies. It states

"FortiSASE secure internet access (SIA) provides protection for remote users when they access the Internet." The configuration steps involve creating a policy with source (remote users)

destination (all)

and applying security profiles (Web Filter

Application Control

etc.)

which are the core components of an SWG policy. (Refer to the "Configuring security" subsection within the "Secure Internet Access" chapter).

2. FortiSASE Datasheet: The datasheet explicitly lists "Secure Web Gateway (SWG)" as a core capability for the Secure Internet Access (SIA) use case. It describes how FortiSASE "provides comprehensive protection against web-based attacks" and "enforces internet security policies

" which are functions of an SWG policy.

FortiSASE writes any change to a user account—add, delete, modify—in the User Events log subtype. The log field subtype=user is triggered when an SSL VPN account is first created in the service, so that creation event is stored in the User Events category, not in VPN, Endpoint, or Administrator logs.

A. Endpoint Events – records device posture/agent status, not identity-management actions.

B. VPN Events – captures connection and tunnel status (connect, disconnect, renegotiate), not account provisioning.

D. Administrator Events – logs admin logins and configuration changes, but user objects created by the authentication service are recorded under User Events.

1. Fortinet “FortiSASE Log Reference 24.1”

Table 3-2 “Event log subtypes”

pg. 18 – ‘user: user creation / deletion / update’.

2. Fortinet “FortiSASE Administration Guide 24.1”

§12.3 “Viewing Event Logs”

pg. 137 – “User Events show when a user is created

removed

or modified

including first-time SSL VPN user creation.”

3. Fortinet “FortiOS 7.4 Log Message Reference”

Chapter ‘event’

entry subtype=user (accounts)

pg. 144 – lists logid 0100040002 “User created”.

Zero Trust Network Access (ZTNA) is the most appropriate solution for providing remote users with secure and efficient access to specific private applications. ZTNA operates on a "never trust, always verify" principle, granting access on a per-application, per-session basis after verifying user identity and device posture. This approach provides granular control and minimizes the attack surface by not granting broad network access, unlike traditional VPNs. FortiSASE leverages ZTNA to provide this exact functionality, making it the most secure and efficient method for the described use case.

A. SD-WAN private access: This is primarily designed for securing and optimizing traffic between sites (branch-to-hub), not for individual remote user access to a specific application.

B. inline-CASB: A Cloud Access Security Broker (CASB) is used to secure access to public cloud services and SaaS applications, not private applications hosted on an internal network.

D. next generation firewall (NGFW): An NGFW is a hardware or software component. While a FortiGate NGFW acts as the ZTNA gateway, ZTNA is the specific access methodology and use case, making it the more precise answer.

1. Fortinet FortiSASE Datasheet: "FortiSASE includes ZTNA for private access. ZTNA provides a better alternative to VPN by providing access per application. This allows organizations to hide applications from the internet

reducing the attack surface." This directly supports ZTNA as the solution for private application access.

2. Fortinet.com

"What is ZTNA?": "Zero Trust Network Access (ZTNA) is a category of technologies that provides secure remote access to specific applications and services to an organization’s users... ZTNA extends the principles of zero trust access to the network

removing the trust assumptions when users

devices

and applications connect." This defines ZTNA's role for secure

specific application access.

3. FortiSASE Architecture Guide 24.1

"Secure Private Access": "FortiSASE Secure Private Access provides ZTNA to applications hosted in the private datacenter or private cloud... The FortiSASE ZTNA solution consists of the FortiClient endpoint

FortiSASE PoPs

and a FortiGate ZTNA access proxy in front of the application." This document explicitly details the FortiSASE architecture for ZTNA-based private access.

FortiSASE treats the external identity provider as the authoritative source once SSO is enabled. The portal automatically suppresses any previously-defined local or cloud-native user-password authentication methods; users can log in only through the configured IdP credentials. (FortiSASE Administration Guide v23.4, “Enable Single Sign-On”, p.103-104).

B. FortiSASE supports IdP integration through SAML/OIDC only; it has no “public/private access type” configuration.

C. FortiSASE SSO applies to both agent-based and agentless (browser) access; recommendation is not limited to agents.

D. Users and groups are not imported or manually edited in FortiSASE; group membership is asserted dynamically by the IdP at login.

1. Fortinet. “FortiSASE Administration Guide v23.4”

Section “Enable Single Sign-On”

pp. 103-104.

2. Fortinet. “FortiSASE SAML & OIDC IdP Integration”

TechDocs KB FD542473

para. 2 (“Local user logins are disabled once SSO is enabled”).