FCSS - FortiSASE 25 Administrator - FCSS_SASE_AD-25 Practice Questions

Explanation

This question tests knowledge of FortiSASE features that replace or enhance traditional on-premises proxy functionality. A cloud-based proxy for a hybrid network must inspect web traffic, enforce policies, and provide SaaS application control. Secure Web Gateway and inline-CASB together provide these capabilities in a cloud-native architecture.

🟢 Correct Options

A. secure web gateway (SWG)
SWG provides URL filtering, threat inspection, and policy enforcement for web traffic. By deploying SWG in the cloud, organizations can route user traffic through FortiSASE for inspection, replacing the traditional on-premises proxy while supporting hybrid network users.

D. inline-CASB
Inline-CASB enforces SaaS application policies, controlling which cloud apps users can access and monitoring their behavior. Combined with SWG, it ensures secure, compliant access to both web and cloud applications in a hybrid network environment.

🔴 Incorrect Options

B. zero trust network access (ZTNA)
ZTNA provides secure application-level access without VPNs but does not replace a proxy or perform general web traffic inspection for hybrid networks. It is focused on application access rather than cloud proxy functionality.

C. sandbox cloud
Sandboxing detects and analyzes advanced threats in files and traffic but does not function as a cloud proxy. It is complementary for threat detection but does not handle general web traffic routing or SaaS policy enforcement.

Reference
🔧 Secure Web Gateway (SWG) – FortiSASE Administration Guide
Explains how FortiSASE SWG inspects web traffic, enforces policies, and replaces traditional on-premises proxy functionality.

🔧 Inline-CASB – FortiSASE Administration Guide
Describes how inline-CASB enforces SaaS access policies and complements SWG in cloud-based proxy deployments.

Explanation:

This question tests your understanding of Single Sign-On (SSO) deployment capabilities in FortiSASE. The key concept is recognizing the flexibility of SSO integration with different types of identity providers based on their network accessibility.

✅ D. SSO identity providers can be integrated using public and private access types:
Correct. FortiSASE can connect to authentication servers (including SSO identity providers) with internal IP addresses or FQDNs by setting Access Type to Private in the server settings . This requires that internal servers are located behind a secure private access (SPA) hub with BGP configured per overlay. Alternatively, public identity providers like Entra ID or Okta are integrated using standard public access methods .

❌ A. SSO users can be imported into FortiSASE and added to user groups:
Incorrect. While FortiSASE does allow you to create user groups and associate them with SSO users, the documentation indicates that SSO users are not "imported" into FortiSASE. Instead, you can allow all users from the IdP or define groups in Configuration > Users, then invite users by sending invitation codes via email . Users are provisioned through invitations rather than being imported as local objects.

❌ B. SSO is recommended only for agent-based deployments:
Incorrect. SSO is a flexible authentication method available for various FortiSASE use cases, not exclusively agent-based deployments. The documentation shows SSO as one of several authentication options alongside LDAP, RADIUS, and local users . It is commonly used with agent-based deployments but not restricted to them.

❌ C. SSO overrides any other previously configured user authentication:
Incorrect. The documentation clarifies that SSO is one of multiple authentication methods that can be configured, including LDAP, RADIUS, and local users . These methods can coexist, and administrators select the appropriate authentication source based on their requirements. A confirmation dialog appears when configuring SSO, but this indicates it will take priority for new authentication attempts, not that it irreversibly overrides all other methods .

🔧 Reference:
⇒ Fortinet Documentation: Access & authentication | Feature Administration Guide - Explains how FortiSASE can connect to authentication servers with internal IP addresses using Private access type through SPA hubs.

⇒ Fortinet Documentation: Design concept and considerations | Mature SIA Agent-based Deployment Guide - Describes SSO via SAML IdP as one of several configurable authentication sources alongside LDAP and RADIUS.

Explanation:

This question explores the Network Lockdown feature, a security measure that restricts an endpoint's internet access if it is not protected by the FortiSASE tunnel. It tests the administrator's knowledge of the specific conditions required to lift these restrictions and restore network connectivity.

✔️Correct Option:

A. When the endpoint connects to the FortiSASE tunnel:
The primary purpose of lockdown is to ensure all traffic is inspected. Once the FortiClient successfully establishes a secure VPN tunnel to the FortiSASE gateway, the lockdown is released because the device is now under the protection and visibility of the corporate security policy.

B. When the endpoint is determined as on-net:
If an endpoint is physically located within the corporate office (on-net), it is typically protected by the local FortiGate. FortiSASE recognizes this "on-net" status and releases the local lockdown to allow the device to function normally within the trusted, already-secured local network environment.

❌Incorrect options:

C. When the endpoint is rebooted:
Network lockdown is a persistent security state managed by the FortiClient agent at the OS level. Simply restarting the computer will not bypass the security restriction; the agent will re-engage the lockdown immediately upon startup until a secure connection or trusted network is verified.

D. When the endpoint is determined as compliant using ZTNA tags:
ZTNA tags are used to grant or deny access to specific applications based on posture (e.g., AV updated). While a device must be compliant to access private resources, compliance alone does not trigger the release of a global network lockdown designed to force tunnel connectivity.

Reference:
⇒ FortiSASE Network Lockdown
This documentation confirms that the lockdown is lifted once the endpoint is either connected to the SASE tunnel or detected as being on a trusted corporate network (on-net).

Explanation:

The question assesses the recommended administrative method for upgrading FortiClient in a managed FortiSASE deployment. FortiSASE provides centralized control over endpoint upgrades through dedicated rules in the portal, allowing phased, controlled rollouts without manual user intervention or manual uploads.

✔️Correct Option:

✅ C. The FortiSASE administrator must assign endpoint groups to an endpoint upgrade rule.
In the FortiSASE portal, under Endpoint Management > Endpoint Upgrade, administrators create upgrade rules specifying the target FortiClient version. They then assign these rules to specific endpoint groups (based on profiles, AD groups, or other criteria) to schedule and push the upgrade automatically to matching managed endpoints.

❌Incorrect options:

❌ A. Remote users must upgrade the FortiClient manually.
This is not recommended in a managed FortiSASE environment; manual upgrades by users defeat centralized control, increase risk of version inconsistencies, and are inefficient for large deployments.

❌ B. FortiSASE automatically upgrades FortiClient when a new version is released.
FortiSASE does not perform fully automatic upgrades across all endpoints without administrator intervention; upgrades require explicit configuration via rules to control timing, groups, and avoid disruptions.

❌ D. The FortiSASE administrator will upload the desired FortiClient version to the FortiSASE portal and push it to endpoints.
FortiSASE does not require manual upload of FortiClient installers; upgrades use versions made available through Fortinet's cloud infrastructure and are managed via endpoint upgrade rules rather than direct push or upload actions.

Reference:
⇒ FortiSASE Administration Guide – Endpoint Upgrade
This section details configuring endpoint upgrade rules in the portal to schedule FortiClient upgrades by assigning them to endpoint groups for controlled deployment.

⇒ Technical Tip: Upgrading FortiClient Endpoints Directly from the FortiSASE Portal
Explains the process of using the FortiSASE portal's endpoint upgrade feature to efficiently upgrade FortiClient on managed endpoints via rules and group assignments.

Explanation:

This question tests understanding of FortiSASE's Digital Experience Monitor (DEM) core functionality. It evaluates knowledge of DEM's primary role in monitoring end-to-end network performance for remote users accessing SaaS applications through FortiSASE infrastructure.

✔️ Correct Option:

✔️ A. It provides end-to-end network visibility from all the FortiSASE security PoPs to a specific SaaS application.
DEM traces network performance from FortiClient endpoints through FortiSASE Points of Presence (PoPs) to SaaS destinations. It identifies bottlenecks across ISP links, PoP routing, and application connectivity using endpoint DEM agents.

❌ Incorrect options:

❌ B. It gathers all the vulnerability information from all the FortiClient endpoints.
Vulnerability scanning uses FortiClient EMS security posture checks. DEM focuses solely on network performance metrics, not endpoint vulnerability data collection.

❌ C. It is used for performing device compliance checks on endpoints.
Device compliance uses ZTNA tags and security posture rules in FortiClient profiles. DEM handles network path monitoring, separate from compliance verification.

❌ D. It monitors the FortiSASE POP health based on ping probes.
PoP health monitoring uses infrastructure probes and synthetic tests. DEM specifically monitors user session paths from endpoints to SaaS applications through PoPs.

Reference:
🔧 FortiSASE Administration Guide - Digital Experience Monitoring
Official documentation confirms DEM provides end-to-end visibility from endpoints through PoPs to SaaS applications.

Explanation:

This question tests your understanding of dual-hub priority configuration in a FortiSASE SD-WAN deployment. Assigning different priorities to hubs enables FortiSASE to make intelligent traffic steering decisions based on both performance thresholds and failover requirements.

✔️ Correct Option — A. Optimized Performance That Meets the Minimum SLA Requirements:
FortiSASE selects the highest priority hub that meets minimum SLA requirements when hub selection is configured using hub health and priority within each PoP. This ensures traffic is always routed through the most optimal and performance-compliant path available, preventing degraded user experience across the SD-WAN deployment.

✔️ Correct Option — D. Redundancy to Seamlessly Steer Traffic:
FortiSASE uses a priority-based preference order — primary hub first, followed by the redundant hub — to seamlessly steer traffic when the primary becomes unavailable. This dual-hub priority setup ensures continuous connectivity and automatic failover without manual intervention, providing reliable redundancy across the entire FortiSASE SD-WAN environment.

❌ Why the Other Options Are Wrong:

❌ B. Load Balancing Based on Session Identification
Load balancing based on session identification distributes traffic equally across links, which is not the purpose of hub priority configuration. Assigning different priorities creates a primary/secondary relationship focused on performance-based path selection, not session-level load sharing.

❌ C. Bandwidth Allocated Traffic Shaping
Bandwidth allocation and traffic shaping are QoS features configured separately through dedicated shaping policies in FortiSASE. Hub priority assignment is strictly concerned with path selection and failover decisions, not with managing or distributing bandwidth consumption across tunnels.

Reference:
⇒ FortiSASE – Updating Service Connection Priorities
Confirms that hub priorities determine which hub is selected based on SLA health, with lower numerical cost indicating higher priority.

⇒ FortiSASE Administration Guide – Configuring Primary and Redundant Hubs
Confirms that primary and redundant hub configuration enables seamless traffic steering and failover in dual-hub SD-WAN deployments.

Explanation:

This question tests your knowledge of FortiSASE's log management policies, specifically what happens to logs once they exceed their defined retention period. Understanding this is crucial for compliance and data management.

✅ Correct Option: A. The logs are deleted from FortiSASE.
When logs on FortiSASE surpass the configured log retention period, they are automatically purged or deleted from the system. This is a standard practice in log management to free up storage space and adhere to data retention policies.

❌ Incorrect options:

B. The logs are indexed and can be stored in a SQL database:
While logs might be indexed for faster searching, storing them in a SQL database is not the default action for expired logs within FortiSASE; they are typically deleted if not explicitly archived elsewhere.

C. The logs are backed up on FortiCloud:
FortiCloud is often used for logging and management, but exceeding the retention period means the logs are removed, not automatically backed up to FortiCloud as a separate action. If longer retention is needed, it must be configured as such within the FortiCloud logging settings, extending the retention rather than backing up after deletion.

D. The logs are compressed and archived:
FortiSASE does not automatically compress and archive expired logs for indefinite storage. If archiving is required, it typically needs a separate configuration or integration with an external archiving solution.

Reference:
⇒ For detailed information on log retention and management in FortiSASE, refer to the FortiSASE Administration Guide on Fortinet's documentation portal. This guide provides specifics on how log retention periods impact the lifecycle of log data.