FCSS - FortiSASE 25 Administrator - FCSS_SASE_AD-25 Practice Questions

Explanation

This question checks knowledge of the initial provisioning process of a FortiSASE instance. During the first access to the FortiSASE portal, administrators must choose data center regions for services responsible for traffic inspection, security analysis, and log storage. These selections define where security processing and data handling occur.

🟢 Correct Options

B. Points of presence
FortiSASE security services run through globally distributed Points of Presence (PoPs). During provisioning, administrators select PoP regions from available global data centers so user traffic can be routed through nearby inspection points, ensuring better latency, optimized routing, and consistent security enforcement.

D. Logging
FortiSASE logging stores network activity, traffic logs, and security events generated within the environment. Administrators select the region where log data will be stored during the initial setup. This determines the physical location of log retention and supports monitoring, auditing, and security investigations.

E. Sandbox
FortiSASE integrates sandbox analysis for detecting unknown or zero-day malware. Suspicious files can be submitted to the sandbox environment where they are executed and analyzed. Administrators configure the sandbox region where the analysis occurs, defining where advanced threat inspection takes place.

🔴 Incorrect Options

A. Identity & access management (IAM)
IAM manages authentication and access control policies. It operates as a centralized identity service within the platform and does not require administrators to select a specific data center location during the first FortiSASE portal setup.

C. Endpoint management
Endpoint management focuses on device posture, endpoint configuration, and integration with FortiClient. These settings are configured after deployment and do not require selecting a data center region during initial tenant provisioning.

Reference
🔧 PoPs – FortiSASE Administration Guide
Explains FortiSASE security Points of Presence and how regional PoPs are provisioned for traffic inspection.

🔧 Logging – FortiSASE Administration Guide
Describes how FortiSASE logs network activity and security events for monitoring and investigation.

🔧 Sandbox – FortiSASE Administration Guide
Details sandbox configuration and how suspicious files are analyzed for advanced threat detection.

Explanation:

This question evaluates your understanding of how Digital Experience Monitoring (DEM) functions within FortiSASE to diagnose connectivity problems from an endpoint perspective. The key is knowing which diagnostic method the DEM agent actively performs to pinpoint network issues when accessing SaaS applications.

✅ FortiSASE runs a trace job on the endpoint using the DEM agent to the Software-as-a-Service (SaaS) application:
Correct. The DEM agent installed on the endpoint can perform synthetic monitoring, including trace jobs (like traceroute), to the SaaS application. This identifies the network path, measures latency at each hop, and helps pinpoint exactly where connectivity failures or performance degradation occurs between the user and the cloud application .

❌ FortiSASE runs a ping from the endpoint to calculate the TTL to the SaaS application:
Incorrect. While ping might be a basic connectivity test, DEM in FortiSASE focuses on more comprehensive synthetic monitoring like trace jobs to map the full path. Calculating TTL (Time to Live) is a byproduct of network packets, not the primary diagnostic method for pinpointing issues along the route .

❌ FortiSASE runs SNMP traps to the endpoint using the DEM agent to verify the SaaS application health status:
Incorrect. SNMP (Simple Network Management Protocol) traps are typically used for monitoring network devices (like routers and switches), not for initiating diagnostic tests from an endpoint to a SaaS application. The DEM agent doesn't receive SNMP traps for this purpose .

❌ FortiSASE runs a netstat from the endpoint to the SaaS application to see if ports are open:
Incorrect. Netstat is a command-line tool run locally on an endpoint to display active connections and listening ports on that device. It is not a test initiated by FortiSASE from the endpoint to a remote SaaS application to check if ports are open along the network path .

🔧 Reference:
⇒ Fortinet Community: Digital Experience Monitoring (DEM) - FortiSASE - Describes how the DEM agent performs synthetic monitoring, including trace jobs, to diagnose connectivity issues.

Explanation:

This question tests the configuration of Split Tunneling (Steering Bypass) within FortiSASE. The goal is to identify how to offload specific, trusted internet traffic from the secure tunnel to the endpoint's local physical interface to optimize bandwidth and performance.

✔️Correct Option:

C. Add the Google Maps URL as a steering bypass destination in the endpoint profile:
By adding the Google Maps destination to the steering bypass list in the endpoint profile, the FortiClient is instructed to route this specific traffic through the local gateway. This effectively excludes it from the FortiSASE VPN tunnel as required.

❌Incorrect options:

A. Configure a steering bypass tunnel firewall policy:
Firewall policies manage traffic that is already inside the FortiSASE infrastructure. They cannot "redirect" traffic back to a local interface once it has already been encapsulated in the VPN tunnel.

B. Add the Google Maps URL in the ZTNA TCP access proxy:
ZTNA is designed for secure, granular access to private internal applications behind a FortiGate. It is not the correct mechanism for managing split-tunneling for general public SaaS or web applications.

D. Exempt Google Maps in URL filtering in the web filter profile:
This action would stop the FortiSASE firewall from blocking the site, but the traffic would still travel through the VPN tunnel to the FortiSASE gateway instead of being redirected locally.

Reference:
⇒ FortiSASE Split Tunneling
This documentation confirms how to define steering bypass destinations to allow specific traffic to exit via the endpoint's local physical interface.

Explanation:

The question evaluates the simplest FortiSASE deployment for a small branch with only 10 users on personal (BYOD) laptops and mobile devices. Minimal configuration prioritizes agent-based endpoint security without hardware installation or complex network setup.

✔️Correct Option:

✅ C. Deploy FortiClient endpoint agent to secure internet access.
FortiClient installs directly on each personal device, enabling SSL VPN/ZTNA tunnel to FortiSASE cloud for full security inspection (SIA, AV, etc.). For small scale (10 users), individual or MDM deployment is straightforward with no on-site hardware or advanced licensing needed, making it the lowest-effort option.

❌Incorrect options:

❌ A. Deploy FortiGate as a LAN extension to secure internet access.
This uses FortiGate or FortiExtender for LAN extension/microbranch, requiring hardware deployment, configuration, and backhaul setup—more complex and not minimal for only 10 personal devices.

❌ B. Deploy FortiAP to secure internet access.
FortiAP provides thin-edge Wi-Fi offload to FortiSASE PoPs for agentless access, but requires provisioning FortiAP hardware, SSID setup, and onboarding—overkill and adds configuration steps for a small BYOD scenario.

❌ D. Deploy SD-WAN on-ramp to secure internet access.
SD-WAN on-ramp uses IPsec tunnels from FortiGate/third-party devices to FortiSASE, needing Advanced/Comprehensive licensing, device configuration, and tunnel setup—suited for larger branches, not minimal for 10 personal devices.

Reference:
⇒ FortiSASE Administration Guide – Endpoint Management and Deployment Modes: Describes FortiClient agent-based mode as ideal for remote users and small-scale BYOD with direct cloud connectivity and minimal infrastructure.

⇒ FortiSASE Ordering Guide / Architecture: Confirms user-based licensing with FortiClient for remote/endpoint access; contrasts with hardware options like FortiBranchSASE, FortiAP thin edge, or SD-WAN on-ramp for branches.

Explanation:

This question tests knowledge of FortiSASE security features during FortiClient endpoint registration. It focuses on identifying the configuration that adds identity-based authentication as an extra protection layer against unauthorized device onboarding.

✔️ Correct Option:

✔️ C. user verification
User verification via SAML SSO requires end users to enter credentials during FortiClient registration with FortiSASE. This authenticates users against an identity provider, ensuring only authorized individuals can onboard endpoints and preventing unauthorized access even with valid invitation codes.

❌ Incorrect options:

❌ A. security posture tags
Security posture tags assess endpoint compliance post-registration using rules for vulnerabilities, OS versions, or certificates. They enforce zero-trust access but do not secure the initial registration process.

❌ B. application inventory
Application inventory provides visibility into installed software on endpoints after registration. It supports monitoring but adds no authentication or verification during the FortiClient registration phase.

❌ D. device identification
Device identification profiles endpoints by attributes like OS or hardware post-registration. It enables tagging and policy application but lacks user credential checks for securing registration.

Reference:
🔧 FortiClient EMS Administration Guide
Official docs confirm user verification enforces authentication during FortiClient registration and onboarding.

🔧 FortiClient ZTNA Deployment Guide
Details SAML and user verification configuration for secure endpoint registration.

Explanation:

This question tests your ability to interpret BGP routing tables in a FortiSASE spoke-to-FortiGate hub topology. The exhibits show what the hub is advertising versus what FortiSASE has actually learned — identifying the routing gap causing the access failure.

✔️ Correct Option — D. Server Subnet BGP Route Not Received on FortiSASE:
In the FortiSASE learned BGP routes table, the 100.65.x.x subnet entries show 0.0.0.0 as both Next Hop and Learned From, indicating those routes are not properly installed. The server's subnet behind the hub is not reflected as a valid, routable entry on the FortiSASE side — meaning FortiClient traffic has no valid path to reach it.

❌ Why the Other Options Are Wrong:

❌ A. Private Access Policy Denied Due to Failed Compliance
Compliance-based denials are enforced through security posture policies and would be visible in traffic or security logs, not in BGP routing tables. The exhibits only show routing information, with no indication of a policy block or posture evaluation failure. This option cannot be concluded from the data presented in the exhibits.

❌ B. The Hub Is Not Advertising the Required Routes
The hub's advertised routes output clearly shows it IS actively advertising routes, including 10.160.160.0/24 and multiple 100.65.x.x subnets with valid next-hop addresses. The advertisement from the hub side is functioning correctly. The issue lies in FortiSASE not properly receiving and installing those routes, not in the hub failing to send them.

❌ C. Hub Firewall Policy Does Not Include the FortiClient Address Range
A missing firewall policy on the hub is a valid general troubleshooting scenario, but the exhibits provided contain only BGP routing table data. There is no firewall policy output or traffic log shown to support this conclusion. Diagnosing a firewall policy issue would require separate policy or traffic log exhibits, which are not present here.

Reference:
⇒ Fortinet FortiSASE Admin Guide – Private Access / BGP Configuration
Confirms that FortiSASE as a BGP spoke must properly receive and install hub-advertised routes for FortiClient remote access to function correctly.

⇒ Fortinet SD-WAN & BGP Spoke-Hub Troubleshooting
Validates that 0.0.0.0 next-hop entries in BGP tables indicate routes that are not usable for forwarding.

Explanation:

This question assesses your understanding of FortiSASE's capabilities to control access to cloud applications, specifically preventing unauthorized logins to non-company resources through Microsoft Office 365. It focuses on the inline-CASB feature for enforcing cloud security policies.

✅ Correct Option: C. web filter with inline-CASB
Using a web filter with inline-CASB (Cloud Access Security Broker) allows FortiSASE to inspect and control user traffic at the application layer. Inline-CASB can specifically identify and block login attempts to unapproved cloud applications by analyzing the web sessions and enforcing policies in real-time, thus preventing access to non-company resources.

❌ Incorrect options:

A. application control with inline-CASB:
While application control can identify and manage application usage, a web filter is more appropriate for granular control over web-based login attempts and destinations within a broader suite like Office 365, especially when combined with inline-CASB for cloud application visibility.

B. data loss prevention (DLP) with Microsoft Purview Information Protection (MPIP):
DLP and MPIP primarily focus on preventing sensitive data from leaving the organization's control, not on blocking login attempts to unauthorized external cloud resources.

D. DNS filter with domain filter:
A DNS filter operates at the domain level, blocking access to entire domains. While it can prevent access to known malicious or unapproved domains, it lacks the application-level context provided by inline-CASB to specifically block login attempts to non-company instances of approved services like Office 365.

Reference:
⇒ Learn more about FortiSASE and its CASB capabilities for cloud application security on the Fortinet Official Documentation. This documentation confirms that inline-CASB, often integrated with web filtering, provides the necessary controls for cloud application access.