Fortinet NSE7_SSE_AD-25 Fortinet NSE 7 - FortiSASE 25 Enterprise Administrator Exam Practice Test

In a FortiSASE environment, the ability of a remote user to establish a VPN tunnel is governed not only by their credentials and firewall policies but also by geographic access controls .

Geofencing Mechanism: FortiSASE includes a Geofencing feature (found under Configuration > Restrictions or Configuration > Geofencing in newer versions) that allows administrators to restrict or allow access to SASE services based on the geographic location of the endpoint ' s public IP address.

Connection Failure vs. SSO Success: The scenario describes a situation where users can successfully authenticate via SSO to reach third-party SaaS apps like Office 365 (O365) or Salesforce (SFDC) but cannot connect to the SASE VPN. This occurs because the SSO authentication is handled directly by the Identity Provider (IdP) (e.g., Microsoft Entra ID), which may not have the same geographic restrictions. However, when the FortiClient attempts to establish the tunnel to the FortiSASE Point of Presence (PoP), the SASE gateway checks the Geofencing list . If the country the user is visiting is on the Deny list (or not on the Allow list), the connection is dropped at the " local-in " policy level on the SASE backend, preventing the tunnel from forming.

Verification and Resolution: To resolve this, the administrator must verify the Geofencing settings and ensure that the countries where the traveling users are located are permitted to connect. If the feature is enabled with a " Deny " list, the specific country must be removed from that list; if it uses an " Allow " list, the country must be added.

Analysis of Other Options:

Option A: Firewall policies govern traffic after the tunnel is established; they cannot resolve a failure to connect the tunnel itself.

Option B: Restarting the device is a general troubleshooting step but will not bypass a server-side geographic block.

Option D: While keeping clients updated is a best practice, the issue described (specific to overseas travel while other functions work) points to a configuration restriction rather than a software bug.

The core of this issue lies in the difference between Certificate Inspection and Deep SSL Inspection within the FortiSASE security framework.

The Limitation of Certificate Inspection: When " Force Certificate Inspection " is enabled in a FortiSASE firewall policy, the system only inspects the SSL handshake—specifically the SNI (Server Name Indication) and certificate headers. It does not decrypt the actual data payload of the HTTPS session.

Antivirus Scanning Requirements: To detect and block malicious files like the EICAR test file when they are downloaded over an encrypted HTTPS connection (such as https://eicar.org), the FortiSASE antivirus engine must be able to " see " inside the encrypted tunnel. This requires Deep Inspection (Full SSL Inspection), where FortiSASE acts as a " man-in-the-middle " to decrypt, scan, and then re-encrypt the traffic.

Exhibit Analysis: The Secure Internet Access policy exhibit clearly shows the toggle for Force Certificate Inspection is enabled (set to " ON " ). As specified in the Fortinet technical documentation, enabling this option forces the policy to use Certificate Inspection only, overriding any Deep Inspection settings that might be defined in the Profile Group.

Conclusion: Because the traffic is only undergoing certificate-level inspection, the antivirus engine cannot analyze the encrypted eicar.com-zip file payload, allowing the download to proceed even though an antivirus profile is active in the group.

When deploying FortiSASE agent-based clients, several features are available that are not typically available with an agentless solution. These features enhance the security and management capabilities for endpoints.

Vulnerability Scan:

Agent-based clients can perform vulnerability scans on endpoints to identify and remediate security weaknesses.

This proactive approach helps to ensure that endpoints are secure and compliant with security policies.

SSL Inspection:

Agent-based clients can perform SSL inspection to decrypt and inspect encrypted traffic for threats.

This feature is critical for detecting malicious activities hidden within SSL/TLS encrypted traffic.

Web Filter:

Web filtering is a key feature available with agent-based clients, allowing administrators to control and monitor web access.

This feature helps enforce acceptable use policies and protect users from web-based threats.

The correct answer is B. By hashing log data . This question belongs to Analytics because it deals with FortiSASE log visibility, reporting, and log analysis. The FortiSASE study guide explains that FortiSASE has built-in local logging for monitoring network activity in the portal. It creates traffic logs with user sessions, destinations, protocols, and actions; security logs for detected threats; event logs for system activity; and endpoint management logs for FortiClient events. The guide also explains that FortiSASE can forward logs to FortiAnalyzer, syslog, or CEF servers for longer retention and centralized analytics.

For hiding personally identifiable user information, Fortinet’s FortiSASE documentation calls the feature log anonymization . It states that log anonymization hides user information, such as usernames, in dashboard widgets, logs, and other FortiSASE areas. When anonymization is enabled, FortiSASE uses a username anonymization hash salt ; FortiSASE then generates a hash based on the username and salt value and uses that hash to anonymize log information.

So the mechanism is hashing, not compression, deletion, or tokenization.

FortiSASE brings the following advantages to businesses with multiple branch offices:

Centralized Management for Simplified Administration:

FortiSASE provides a centralized management platform that allows administrators to manage security policies, configurations, and monitoring from a single interface.

This simplifies the administration and reduces the complexity of managing multiple branch offices.

Eliminates the Need for On-Premises Firewalls:

FortiSASE enables secure access to the internet and cloud applications without requiring dedicated on-premises firewalls at each branch office.

This reduces hardware costs and simplifies network architecture, as security functions are handled by the cloud-based FortiSASE solution.

The distinction between SASE (Secure Access Service Edge) and SSE (Security Service Edge) is a fundamental architectural concept in modern networking and security.

SASE Definition: SASE is a comprehensive framework that converges networking capabilities (specifically SD-WAN) with cloud-native security services (SSE) into a single, unified service model.

SSE Definition: SSE represents the security-focused subset of SASE. 4 It encompasses the core security pillars required for secure access, including Secure Web Gateway (SWG) , Cloud Access Security Broker (CASB) , and Zero Trust Network Access (ZTNA) .

The Key Differentiator: While both solutions share the same security stack (SWG, CASB, ZTNA), SD-WAN (Software-Defined Wide Area Network) is the specific networking component that exists in a full SASE solution to provide intelligent path selection and optimized connectivity. SSE intentionally excludes these wide-area networking functions, focusing purely on the security service delivery layer.

According to the FortiSASE 25 Enterprise Administrator Study Guide , organizations that already have a robust networking infrastructure and only require a cloud-delivered security overlay would opt for SSE, whereas those seeking a complete transformation of both network and security would deploy a full SASE solution that includes SD-WAN.

In FortiSASE Secure Private Access (SPA) deployments, establishing a stable connection between the FortiSASE PoPs and the corporate FortiGate hub relies on two primary layers: the IPsec Tunnel and the BGP Peering .

Exhibit Analysis: The exhibit (image_577e17.jpg) shows the status of several Security PoPs (Singapore, Tokyo, Frankfurt, and San Jose) connected to an " FGT-Hub " .

Tunnel Status vs. BGP Status: For all listed PoPs, the Health Check IP Status and Tunnel status are both shown with a green " Up " icon. This confirms that the underlying IPsec connectivity and the physical path between the SASE cloud and the hub are functioning correctly.

Identifying the Failure: The BGP Peering State is reported as Active . In BGP terminology, the " Active " state specifically indicates that the router is attempting to initiate a TCP connection with its peer but has not yet received a response. A fully functional and successful BGP connection must reach the Established state.

Root Cause Determination: Since the tunnel is up (eliminating Gateway or Authentication Method issues as the primary suspects) but the BGP state remains stuck in " Active, " the most likely cause is a mismatch or misconfiguration in the BGP Peer IP or BGP neighbor settings. This prevents the exchange of routing information necessary for users to access private applications.

To resolve the connectivity problem, the administrator must ensure that the BGP neighbor IPs configured on the FortiGate hub match those assigned by the FortiSASE orchestration and that firewall policies on the hub allow BGP traffic (TCP port 179) across the tunnel.

The VPN tunnel between the FortiSASE spoke and the FortiGate hub is not establishing due to the configuration of mode config, which is not supported by FortiSASE spoke devices. Mode config is used to assign IP addresses to VPN clients dynamically, but this feature is not applicable to FortiSASE spokes.

Mode Config in IPsec:

The configuration snippet shows that mode config is enabled in the IPsec phase 1 settings.

Mode config is typically used for VPN clients to dynamically receive an IP address from the VPN server, but it is not suitable for site-to-site VPN configurations involving FortiSASE spokes.

Configuration Adjustment:

To establish the VPN tunnel, you need to disable mode config in the IPsec phase 1 settings.

This adjustment will allow the FortiSASE spoke to properly establish the VPN tunnel with the FortiGate hub.

Steps to Disable Mode Config:

Access the VPN configuration on the FortiSASE spoke.

Edit the IPsec phase 1 settings to disable mode config.

Ensure other settings such as pre-shared key, remote gateway, and BGP configurations are correct and consistent with the FortiGate hub.

FortiSASE Secure Private Access (SPA) provides flexible connectivity to internal corporate resources using a hub-and-spoke architecture where FortiSASE PoPs act as spokes to an organization ' s FortiGate hub.

Flow from Agent-based users to Private Resources (C): This is the core functionality of SPA. Remote users running FortiClient (agent-based) connect to the nearest FortiSASE PoP. The PoP, integrated into the corporate SD-WAN fabric, uses IPsec and BGP to route traffic to the private applications located behind the FortiGate hub or associated spokes.

Flow from Thin Branches/Branch On-ramp to Private Resources (E): FortiSASE extends its security and connectivity to physical locations through " Thin Edge " (e.g., FortiExtender, FortiAP) or " Branch On-ramp " (e.g., branch FortiGates). These sites form tunnels to the FortiSASE PoP, which then provides them with access to the same private resources in the SD-WAN network as the remote agent-based users.

Flow from Private Resources to Agent-based users (A): The SPA architecture is designed for bidirectional communication. Documentation confirms that traffic can be initiated from the FortiGate hub (or local networks behind it) to the remote VPN agents. This " Server-to-Client " flow is essential for administrative tasks, log forwarding, or real-time communication applications like VoIP.

Incorrect Options:

Option B: Traffic from private resources to the internet is handled via Secure Internet Access (SIA) or local gateway policies, not the SPA use case, which is dedicated to internal private application access.

Option D: While FortiSASE can facilitate branch-to-branch communication via ADVPN shortcuts, the term " SPA " specifically refers to the access layer for users and is not used to describe resource-to-resource or hub-to-hub traffic.

In a FortiSASE deployment, Digital Experience Monitoring (DEM) is the primary diagnostic tool used to troubleshoot connectivity and performance issues specifically for a single user or endpoint.

End-to-End Visibility: DEM provides real-time, end-to-end visibility into the network path between the end-user ' s device and the application they are trying to reach. This is critical when only one user reports an issue, as it allows administrators to pinpoint whether the problem resides on the local device, the local ISP, the SASE backbone, or the destination application.

Performance Metrics: The DEM agent (often integrated with the FortiMonitor agent on the endpoint) collects granular performance metrics such as latency, jitter, packet loss, and RTT (Round Trip Time) . It also provides device-specific health data, including CPU and memory usage, to determine if the connectivity issue is actually caused by the remote computer ' s performance.

Hop-by-Hop Analysis: Unlike standard monitoring, DEM offers End-to-End Continuous Hop Analytics . This path monitoring visualizes every " hop " in the traffic route and highlights exactly where degraded service is occurring. For a single user experiencing issues while everyone else is fine, this tool immediately triangulates if a specific " problem hop " in their unique connection path is the cause.

Operational Comparison: * MDM (A) is used for managing device configurations and software distribution, not for real-time network performance troubleshooting.

Forensics (C) is a security-focused service used for investigating malware incidents or data breaches, not for measuring network latency.

SOCaaS (D) is a managed security service for threat monitoring and event triage; while it handles " security " connectivity issues (like a blocked IP), it is not a tool for performance metric evaluation.

Onboarding a Secure Web Gateway (SWG) endpoint involves several components to ensure secure and effective integration with FortiSASE. Two key components are the FortiSASE CA certificate and the proxy auto-configuration (PAC) file.

FortiSASE CA Certificate:

The FortiSASE CA certificate is essential for establishing trust between the endpoint and the FortiSASE infrastructure.

It ensures that the endpoint can securely communicate with FortiSASE services and inspect SSL/TLS traffic.

Proxy Auto-Configuration (PAC) File:

The PAC file is used to configure the endpoint to direct web traffic through the FortiSASE proxy.

It provides instructions on how to route traffic, ensuring that all web requests are properly inspected and filtered by FortiSASE.

Zero Trust Network Access (ZTNA) private access provides the most efficient and secure method for remote users to access a TCP-based application hosted on a private web server. ZTNA ensures that only authenticated and authorized users can access specific applications based on predefined policies, enhancing security and access control.

Zero Trust Network Access (ZTNA):

ZTNA operates on the principle of " never trust, always verify, " continuously verifying user identity and device security posture before granting access.

It provides secure and granular access to specific applications, ensuring that remote users can securely access the TCP-based application hosted on the private web server.

Secure and Efficient Access:

ZTNA private access allows remote users to connect directly to the application without needing a full VPN tunnel, reducing latency and improving performance.

It ensures that only authorized users can access the application, providing robust security controls.

In a FortiSASE environment, log management is governed by a cloud-native storage policy that prioritizes performance and resource availability.

Retention Policy Framework: All FortiSASE instances come with log retention enabled by default. The standard log retention period is 30 days , though administrators can customize this policy to any duration between 2 and 30 days . This policy applies across all log types, including traffic, security, and event logs.

Automatic Deletion (A): When logs exceed the configured retention threshold, FortiSASE automatically deletes the older logs from the platform. 2 This automatic purging is necessary to free up storage space on the cloud infrastructure and maintain compliance with the organization ' s data lifecycle settings.

Persistence and Recovery: Once logs are deleted due to the expiration of the retention period, they are generally unrecoverable from the FortiSASE platform.

Long-Term Storage Solutions: Because FortiSASE is not designed as a long-term archival solution, customers who need to store logs for months or years for regulatory compliance should configure log forwarding to an external server , such as a FortiAnalyzer or a remote Syslog server.

Analysis of Incorrect Options: * Option B and D: While traditional FortiAnalyzer deployments use SQL indexing and separate " Archive " (raw/compressed) vs. " Analytics " (SQL) tiers, FortiSASE uses a simplified cloud storage model where data is purged rather than archived or tier-shifted upon expiry.

Option C: While FortiSASE is part of the FortiCloud ecosystem, it does not automatically " back up " expired logs to another FortiCloud service; the deletion is final unless external forwarding is active.

The core of the issue shown in the exhibits is the lack of visibility into encrypted traffic.

HTTPS Encryption: The eicar.org website uses the HTTPS protocol for its downloads. This means the data payload, including the test malware file, is encrypted as it traverses the network.

SSL Inspection Modes: As seen in the Security profile group exhibit (image_5705fc.jpg), the SSL inspection mode is explicitly set to Certificate inspection mode .

Visibility Gap: Certificate inspection only analyzes the initial SSL handshake, such as the server certificate and SNI (Server Name Indication). It does not decrypt the traffic payload. Consequently, the antivirus engine in FortiSASE cannot " see " or scan the eicar.com-zip file hidden within the encrypted session.

Resolution Requirement: To detect and block malicious files over HTTPS, SSL Deep Inspection must be enabled. Deep inspection allows FortiSASE to act as a proxy, decrypting the traffic for full content scanning by the antivirus and IPS engines before re-encrypting it for the endpoint.

Log Analysis: While the web filtering logs (image_5704e5.jpg) show the traffic is " Allowed " because the URL is not blocked by a web filter category, this is only the first step of inspection. The antivirus engine is present but ineffective because it is blind to the encrypted content due to the lack of deep inspection.

In the Fortinet SASE architecture, Zero Trust Network Access (ZTNA) tags (which have been renamed to Security Posture Tags starting with FortiClient/EMS 7.4.0) play a critical role in continuous posture assessment. These tags are dynamic metadata assign 8 ed to an endpoint based on specific conditions or " tagging rules " defined in the FortiSASE Endpoint Management Service (EMS).

Posture Determination: The FortiClient agent, installed on the endpoint, monitors the device for various security attributes—such as whether an antivirus is running, the presence of specific registry keys, OS version, or the absence of critical vulnerabilities.

SIA (Secure Internet Access) Use Case: In SIA scenarios, FortiSASE uses these tags within security policies to control internet access. For example, a policy may allow full internet access only to endpoints tagged as " Compliant " while redirecting " Non-Compliant " devices to a restricted remediation portal.

SPA (Secure Private Access) Use Case: In SPA (specifically ZTNA Proxy mode), the tags are synchronized from FortiSASE to the corporate FortiGate (acting as the ZTNA Access Proxy). 12 When a user attempts to access a private application, the FortiGate checks the endpoint ' s client certificate and its synchronized ZTNA tags. 13 If the endpoint does not meet the required posture (e.g., it is missing a required " Domain-Joined " tag), access is denied at the session level.

According to the FortiSASE 25 Enterprise Administrator Study Guide , ZTNA tags are fundamental to the " Zero Trust " principle because they move beyond static identity (username/password) to verify the real-time security state of the device before granting access to either the internet or internal private resources.

To ensure that organizational SaaS applications (such as Microsoft 365, Salesforce, or AWS Console) are only accessible to users who are currently connected and protected by FortiSASE, administrators utilize Source IP Anchoring and IP-based access control .

Consistent Egress IPs: Every FortiSASE instance is assigned a set of dedicated public IP addresses (egress IPs) for each Security Point of Presence (PoP). Regardless of where a remote user is physically located, when they connect to a specific FortiSASE PoP, all their traffic destined for the internet or SaaS applications will appear to originate from that PoP ' s dedicated egress IP.

Whitelisting and Conditional Access: Administrators can retrieve the list of these dedicated egress IPs from the FortiSASE portal (typically found under the Support or Region IP list). These IPs are then configured as " Trusted Locations " or " Named Locations " within the SaaS provider ' s security settings (e.g., Microsoft Entra ID Conditional Access).

Enforcement Mechanism: Once the SaaS portal is configured to only permit logins from the FortiSASE egress IP ranges, any user attempting to access the application without being connected to the FortiSASE VPN will be denied access because their source IP will be their local ISP address rather than the trusted SASE IP. This effectively mandates the use of the SASE security stack for all corporate SaaS interactions.

Analysis of Incorrect Options:

Option A: CNAPP (Cloud-Native Application Protection Platform) is used for securing cloud-native applications and infrastructure, not for managing egress IP whitelisting for external SaaS providers.

Option B: While ZTNA is a secure access method, it is primarily used for Private Applications hosted by the organization, not for third-party public SaaS portals which rely on standard IP or identity-based conditional access.

Option C: SPA hubs are designed for Secure Private Access (connecting to a corporate data center), not for managing access to public SaaS applications.

When remote users connected to FortiSASE require access to internal resources on Branch-2, the following process occurs:

SD-WAN Capability:

FortiSASE leverages SD-WAN to optimize traffic routing based on performance metrics and priorities.

In the priority settings, HUB-1 is configured with the highest priority (P1), whereas HUB-2 has a lower priority (P2).

Traffic Routing Decision:

FortiSASE evaluates the available hubs (HUB-1 and HUB-2) and selects HUB-1 due to its highest priority setting.

Once the traffic reaches HUB-1, it is then routed to the appropriate branch based on internal routing policies.

Branch-2 Access:

Since HUB-1 has the highest priority, FortiSASE directs the traffic to HUB-1.

HUB-1 then routes the traffic to Branch-2, providing the remote users access to the internal resources.

The correct answer is D. Web filter with inline-CASB . The FortiSASE study guide states that FortiCASB provides cloud-based and API-based capabilities for deep inspection of SaaS applications, enabling monitoring, analysis, and reporting. It also states that FortiSASE provides inline CASB functionality with a web filter and application control security features , while DLP protects data at rest and in motion.

This question specifically describes restricting Microsoft Office 365 access by tenant, meaning users should be allowed to access company-approved Microsoft 365 resources but blocked from logging in to non-company or personal resources. Fortinet’s FortiSASE documentation describes this exact use case as “restricted SaaS access,” where organizations restrict access to Microsoft Office 365, Google Workspace, and similar SaaS services by tenant to block non-company login attempts and prevent access to non-approved cloud resources. Fortinet’s Office 365 example confirms this is implemented through FortiSASE Web Filter with Inline-CASB, using inline-CASB headers to allow corporate domains and deny personal accounts.

In FortiSASE, the accuracy of application usage reports depends on two primary factors: the ability to identify the application (visibility) and the configuration to log that data (reporting).

Deep Inspection Requirement (D): Modern applications frequently use encryption (SSL/TLS) and dynamic ports. Without Deep Inspection (SSL decryption), the FortiSASE security engine cannot see the application payload and is limited to inspecting headers or SNI. This results in many applications being identified only by their generic protocol (e.g., " SSL " or " HTTPS " ) and subsequently appearing as Unknown in reports because the specific Layer 7 application signature cannot be matched.

Application Control Monitor Setting (B): Even when an application is correctly identified, it must be properly logged to appear accurately in the " Daily report for application usage " . In the inline-CASB (Application Control) profile, categories are assigned actions such as " Allow " , " Block " , or " Monitor " . If categories are set to " Allow " instead of Monitor , the traffic is permitted but granular session details—including the specific application category—may not be logged for reporting purposes, causing them to be grouped into an " Unknown " or " Uncategorized " bucket in high-level summaries.

Analysis of Incorrect Options:

Option A: While certificate inspection provides more visibility than no inspection, it is still insufficient for many applications that require deep packet inspection for identification. Therefore, the lack of Deep inspection (Option D) is the more accurate technical explanation for " Unknown " results.

Option C: ZTNA tags are used for access control and posture-based policy enforcement; they do not impact the application identification engine ' s ability to categorize traffic flows.

For small branch offices (thin edges) where users utilize unmanaged personal devices (BYOD) like laptops and mobile phones, the most efficient way to provide Secure Internet Access (SIA) with minimal configuration is by deploying a FortiAP .

Thin Edge Integration: FortiSASE includes expanded integrations with the Fortinet WLAN portfolio, allowing FortiAP wireless access points to function as " thin edge " devices. These access points intelligently offload and steer traffic from the branch directly to the nearest FortiSASE Security Point of Presence (PoP).

No Endpoint Agents Required: Because the devices are personal and unmanaged, installing the FortiClient agent (Option A) is often not feasible or desirable. The FortiAP deployment secures all client devices at the location without requiring any endpoint agents .

Minimal Configuration & Zero-Touch: This solution is specifically designed for small office locations with limited budgets and no local IT staff. FortiSASE offers cloud-delivered management with zero-touch provisioning for FortiAP. Once the AP is connected, it automatically establishes a secure CAPWAP or IPsec tunnel to FortiSASE, ensuring all connected users are protected by the cloud security stack (Antivirus, Web Filtering, etc.) with almost no manual setup on the end-user side.

Why other options are less ideal:

Option C and D: SD-WAN on-ramp and FortiGate LAN extensions typically require a physical FortiGate appliance at the branch. For a small office with only ten users and personal devices, this adds unnecessary hardware costs and configuration complexity compared to a simple, cloud-managed FortiAP.

The Network Lockdown feature in FortiSASE is a specialized security control designed to ensure that managed endpoints remain protected by the SASE security stack at all times.

Mechanism of Action: Network lockdown relies specifically on the connection status of the tunnel to FortiSASE . When this feature is enabled in the Endpoint Profile, the FortiClient agent monitors whether the secure VPN tunnel (SSL or IPsec) to a FortiSASE Point of Presence (PoP) is active.

Enforcement Logic: If the agent detects that the tunnel is disconnected , it immediately places the endpoint ' s network interface into a " locked " state. In this state, all inbound and outbound network traffic is blocked, with the exception of traffic required to re-establish the connection to the FortiSASE infrastructure.

Purpose: This prevents " leakage " where an endpoint might communicate directly with the internet without inspection if the VPN tunnel drops or is manually disabled by the user. It essentially mandates that the device is either connected to FortiSASE or has no network access at all.

Analysis of Incorrect Options:

Option A and B: While malware and vulnerabilities affect the security posture, they trigger different remediation actions (like quarantine or patching) rather than the " Network Lockdown " tunnel-state feature.

Option D: ZTNA tags identify the security posture to allow or deny access to specific applications , whereas Network Lockdown is a binary state (On/Off) affecting all network traffic based purely on tunnel connectivity.

FortiSASE supports zero trust network access (ZTNA) principles by identifying attributes on the endpoint for security posture checks. ZTNA principles require continuous verification of user and device credentials, as well as their security posture, before granting access to network resources.

Security Posture Check:

FortiSASE can evaluate the security posture of endpoints by checking for compliance with security policies, such as antivirus status, patch levels, and configuration settings.

This ensures that only compliant and secure devices are granted access to the network.

Zero Trust Network Access (ZTNA):

ZTNA is based on the principle of " never trust, always verify, " which requires continuous assessment of user and device trustworthiness.

FortiSASE plays a crucial role in implementing ZTNA by performing these security posture checks and enforcing access control policies.

In the FortiSASE architecture, there are two primary methods for delivering Secure Internet Access (SIA) : Agent-based (using FortiClient) and Agentless (using Secure Web Gateway/SWG).

Use Case Analysis: The scenario describes a contractor—an unmanaged user—who requires temporary access for a web-based application (the POS system). For contractors or guests using personal/non-corporate devices where installing the FortiClient agent is either not feasible or not desired, FortiSASE provides the SIA Agentless deployment model.

Mechanism (SWG & PAC): In this mode, FortiSASE functions as an explicit web proxy . To steer the contractor ' s web traffic (HTTP/HTTPS) to the SASE cloud for inspection, the administrator provides the user with a proxy auto-configuration (PAC) file . The contractor simply configures their browser or operating system to point to the URL of this PAC file.

Security Enforcement: Once the PAC file is applied, all web traffic from the contractor ' s device is redirected to the FortiSASE SWG PoP. Here, the traffic is subject to the organization’s full security stack, including SSL deep inspection, Antivirus, Web Filtering, and Application Control , ensuring that even temporary contractor access is fully secured and logged.

Why other options are incorrect:

Option B (Tunnel Policy): This refers to agent-based access where a VPN tunnel is established. This requires FortiClient, which is generally not used for temporary contractors on unmanaged devices.

Option C (ZTNA Unmanaged): While ZTNA supports agentless access to private applications (SPA), providing internet access (SIA) to an unmanaged endpoint is specifically the role of the SWG/Proxy service.

Option D (Self-registration): While FortiSASE has a User Portal for onboarding, it is a method for user registration/credential management, not the technical traffic-steering mechanism used to provide internet connectivity.

According to the FortiSASE 25 Secure Internet Access Architecture Guide , the SWG (Agentless) approach is the recommended best practice for securing web-only traffic from unmanaged endpoints and third-party contractors.

There are two deployment methods used to connect a FortiExtender as a FortiSASE LAN extension:

Connect FortiExtender to FortiSASE using FortiZTP:

FortiZero Touch Provisioning (FortiZTP) simplifies the deployment process by allowing FortiExtender to automatically connect and configure itself with FortiSASE.

This method requires minimal manual configuration, making it efficient for large-scale deployments.

Enter the FortiSASE domain name in the FortiExtender GUI as a static discovery server:

Manually configuring the FortiSASE domain name in the FortiExtender GUI allows the extender to discover and connect to the FortiSASE infrastructure.

This static discovery method ensures that FortiExtender can establish a connection with FortiSASE using the provided domain name.

The correct answers are C and D . FortiSASE SPA supports two private access models. The first model is ZTNA access proxy , where the endpoint connects directly to the FortiGate ZTNA access proxy. The study guide states that ZTNA provides a direct connection to protected resources without establishing a persistent VPN tunnel and that the ZTNA access proxy use case offers the direct shortest path to private resources. This validates option C and invalidates option B, because ZTNA access proxy traffic does not first traverse a FortiSASE POP.

The second model is SD-WAN private access, where FortiSASE acts as a spoke. The guide explains that FortiSASE SPA enables a FortiSASE POP to connect to a FortiGate hub or an existing Fortinet SD-WAN deployment using IPsec and BGP. In that design, endpoint traffic is steered to the FortiSASE POP, and the POP forwards traffic through the SPA tunnel to the FortiGate hub. That validates option D and makes option A incorrect.