Free NSE7_SSE_AD-25 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

In the FortiSASE architecture, Secure Internet Access (SIA) is the service that protects remote users and devices as they access the internet. The policies that govern this traffic, including web filtering, application control, and threat protection for internet-bound connections from FortiClient endpoints, are configured as secure web gateway (SWG) policies. These policies are the specific mechanism for controlling this traffic flow.

A. VPN policy: This term typically refers to policies for site-to-site or traditional remote access VPNs, not the specific policy type for FortiSASE's integrated internet security service.

B. thin edge policy: This policy type is used in the context of FortiSASE Secure SD-WAN Integration for traffic originating from a physical site (Thin Edge), not a remote FortiClient endpoint.

C. private access policy: This policy type is used for FortiSASE's ZTNA use case to control access to internal, private applications, not for general internet access.

1. FortiSASE 23.3 Administration Guide, "Secure Internet Access", section "Configuring security". This section details the process: "You can configure an SWG firewall policy to control network traffic for remote users."

FortiExtender can be connected to FortiSASE as a LAN extension for a thin branch using two primary methods. The first is an automated, zero-touch process using FortiZTP, where the device automatically discovers and connects to the FortiSASE service upon being powered on. The second is a manual method where an administrator logs into the FortiExtender's GUI and explicitly configures the FortiSASE domain name (fortisase.com) as the static discovery server, which initiates the connection process.

B. Enable Control and Provisioning Wireless Access Points (CAPWAP) access on the FortiSASE portal: CAPWAP is a protocol for managing access points from a controller; it is not used for connecting the FortiExtender device itself to FortiSASE.

D. Configure an IPsec tunnel on FortiSASE to connect to FortiExtender: While the underlying connection is an IPsec tunnel, the administrator does not manually configure it on the FortiSASE portal. The tunnel configuration is automated via the ZTP or manual discovery process.

1. FortiSASE Administration Guide, Version 23.3, "Secure Internet Access > Thin Edge > FortiExtender as a SASE LAN extension". This section explicitly states: "You can connect a FortiExtender to FortiSASE using FortiZTP or by manually configuring the FortiExtender."

2. FortiSASE Administration Guide, Version 23.3, "Secure Internet Access > Thin Edge > FortiExtender as a SASE LAN extension > Manually connecting a FortiExtender". This section details the manual process: "In the FortiExtender GUI...For Type, select FortiSASE. For Server, enter fortisase.com."

To exclude specific internet traffic from the FortiSASE tunnel and route it directly out of the user's local internet connection (the endpoint physical interface), you must configure split tunneling via traffic steering. In FortiSASE, this is achieved by modifying the Endpoint Profile. By adding the specific destination (such as an FQDN, IP, or ISDB object for Google Maps) as a steering bypass destination within the endpoint profile, FortiClient is instructed to exclude this traffic from the IPsec/SSL VPN tunnel. This allows the traffic to go directly to the internet, providing local breakout while all other traffic remains steered into FortiSASE for inspection.

A: ZTNA TCP access proxy forwarding rules are designed to securely publish private enterprise applications, not to control outbound internet traffic routing or bypass SASE tunnels.

B: Firewall policies enforce security on traffic after it reaches the FortiSASE gateway. They cannot instruct the local FortiClient to redirect traffic to the endpoint's physical interface.

C: URL filtering exemptions only bypass web inspection for traffic already inside the tunnel; they do not route traffic out of the physical interface or bypass the tunnel itself.

Fortinet Official Documentation: FortiSASE Administration Guide (v23.4 / v24.1), Section: "Endpoint Configuration" -> "Endpoint profiles" -> "Configuring traffic steering". This section details how to use steering bypass rules to exclude traffic from the FortiSASE tunnel.

Fortinet Official Documentation: FortiSASE Administration Guide, Section: "Split tunneling". This section explains the architecture of bypassing the VPN tunnel to allow direct internet access from the endpoint's physical network adapter.

FortiSASE functions as an inline Cloud Access Security Broker (CASB) by leveraging its Secure Web Gateway (SWG) capabilities. To achieve this, it requires SSL deep inspection to decrypt and analyze encrypted cloud application traffic. The specific application signatures and controls are then applied through policies configured within the Web Filter profile, which includes the inline-CASB database and features. These two components work together to provide visibility and granular control over sanctioned and unsanctioned cloud applications.

A. intrusion prevention system (IPS): IPS focuses on network-based threats and vulnerabilities, which is a different security function from the application-centric visibility and control provided by inline-CASB.

C. DNS filter: DNS filtering operates at the domain level, blocking or allowing access before a connection is established. It lacks the deep-packet inspection capability to control specific in-app activities.

- FortiSASE Administration Guide, "Inline-CASB". The guide states, "FortiSASE inline-CASB requires enabling SSL deep inspection and application control in a security policy." It also details the configuration of CASB features within the Web Filter security component.

Based on the provided FortiSASE security log, the traffic was denied by the Web Filter with the specific message: "URL was blocked because it contained banned word(s)." The log also explicitly identifies the banned word as "fight." In Fortinet architectures, including FortiSASE and FortiOS, inspecting webpage payloads to block or exempt access based on specific words, phrases, or regular expressions is exclusively handled by the web content filter within the broader web filter profile. To restore access to the requested URL, the administrator must navigate to the active web filter configuration and adjust the content filter list by removing the word "fight" or modifying its action.

A. FortiGuard category-based filter: This feature blocks entire domains based on predefined vendor classifications (e.g., blocking all "Gambling" or "Social Media" sites), rather than parsing page payloads for specific banned vocabulary.

C. URL Filter: URL filtering explicitly allows or denies traffic based on predefined lists of URLs, domain names, or wildcards (e.g., blocking *.bbc.com/*), not by scanning the actual text content of the page for banned words.

D. inline cloud access security broker (CASB) headers: Inline CASB is used to inject or modify HTTP headers to control access to specific SaaS tenants (e.g., restricting Microsoft 365 access to a corporate domain). It does not perform banned word filtering.

Fortinet Document Library: FortiOS Administration Guide, Section: Security Profiles > Web Filter > Web content filter. (This document explains that to block or exempt web pages containing specific words or patterns, administrators must configure the web content filter block/exempt lists).

Fortinet Document Library: FortiSASE Administration Guide, Section: Security > Web Filter. (Confirms that FortiSASE inherits FortiOS web filtering mechanisms, including content filtering for banned words).

To resolve internal hostnames using internal DNS servers for remote endpoints in FortiSASE, you need to configure Split DNS rules to direct specific domain queries to internal DNS servers instead of public ones. Additionally, Split tunnelling destinations must be configured to ensure that DNS traffic for internal domains is routed through the SASE tunnel to reach the internal DNS servers. These two components work together to enable proper internal hostname resolution while maintaining security and connectivity for remote users.

A. SSL deep inspection: This is for inspecting encrypted traffic, not for DNS resolution routing.

D. DNS filter: This is for blocking/allowing domains, not for directing queries to specific DNS servers.

1. Fortinet FortiSASE 23.4 Administration Guide, "Split DNS Configuration" section, pages 187-192

2. Fortinet NSE7 Cloud Security 7.0 Study Guide, Chapter 8 "DNS and Split Tunneling", pages 245-248

3. FortiSASE Cloud Security Reference Architecture, Document ID: SASE-RA-23.4, "DNS Resolution for Remote Users" section 4.3

4. Fortinet Technical Documentation Portal, "FortiSASE Split Tunneling Best Practices", Document #FD-54329, pages 12-15

5. FortiSASE Deployment Guide v23.4, "Configuring Split DNS and Tunneling", pages 78-82

Based on the provided exhibits, FortiSASE leverages its SD-WAN integration to route traffic to internal networks via Secure Private Access (SPA). The "Priority settings" exhibit explicitly demonstrates that HUB-1 is configured with the highest priority (P1) for the designated region, whereas HUB-2 holds a secondary priority (P2). Consequently, FortiSASE's SD-WAN routing engine will direct traffic destined for Branch-2 toward the primary path, HUB-1. Once the traffic reaches HUB-1, the hub’s internal routing table forwards the packets across the existing overlay network to the target spoke, Branch-2. FortiSASE does not negotiate direct IPsec/ADVPN shortcuts directly to branch spokes for remote user traffic.

A: Incorrect because the priority settings exhibit shows HUB-2 assigned a lower priority (P2) than HUB-1. SD-WAN logic will select the highest priority path first.

B: Incorrect because FortiSASE relies on the SD-WAN hub-and-spoke topology for Secure Private Access and does not initiate direct ADVPN shortcut tunnels to branch spokes using static routes.

D: Incorrect because FortiSASE does not utilize ADVPN dynamic routing protocols to establish direct, spontaneous shortcuts to branch locations; traffic must transit the designated Hubs.

Fortinet, Inc. (2023). FortiSASE Administration Guide. Section: "Secure Private Access (SPA) - Hub-and-spoke architecture". This document details how FortiSASE Security Points-of-Presence (PoPs) act as spokes and rely on hub prioritization to route traffic to corporate networks.

Fortinet, Inc. (2023). FortiOS 7.2 Secure SD-WAN Architecture Guide. Section: "SD-WAN Rules and BGP Route Prioritization". Explains the mechanics of how priority tags (P1, P2) in SD-WAN deployments dictate path selection for inbound and outbound overlay traffic.

Zero-trust tags are central to Fortinet's ZTNA solution. First, they represent the security posture of an endpoint, classifying it based on rules configured in FortiClient EMS (e.g., OS version, AV status). Second, these tags are used by the enforcement point (FortiSASE) in ZTNA and SWG policies as a dynamic criterion to explicitly allow or deny access to specific network resources or applications. This ensures continuous verification of the device state before granting access.

C. Zero-trust tags are applied by endpoint profiles; they do not create the profiles themselves. The relationship is the reverse of what is stated.

D. While tags can be used for SWG access, this is a specific instance of the broader principle described in option A ("access to network resources"). Option A is the more fundamental advantage.

1. FortiOS 7.4.0 ZTNA Guide, "ZTNA components", page 6. It states, "ZTNA rules on the FortiGate use these tags to grant or deny access to applications." This supports option A.

2. FortiClient EMS 7.2.3 Administration Guide, "Zero Trust Tags", page 118. It states, "Zero Trust tags allow you to classify endpoints based on a defined set of criteria." This supports that tags represent the determined security posture (Option B).

In FortiSASE (built upon modern FortiOS 7.x architecture), configuring a regex-based DLP mechanism requires a bottom-up configuration approach due to object dependencies. First, you must create a DLP Data Pattern to define the exact Regular Expression. Second, this pattern is incorporated into a DLP Dictionary, which groups related data types for scanning. Third, you create a DLP Profile to serve as the container for your security policies. Finally, you configure a DLP Rule within that profile. The rule references the dictionary and dictates the enforcement action (e.g., block or log) when the regex is triggered. "DLP Sensor" is an incorrect distractor, as sensors were deprecated and merged directly into DLP Profiles starting in FortiOS 7.0.

FortiSASE Administration Guide, Section: Configuration > Security > Data leak prevention. Details the hierarchical configuration of data patterns, dictionaries, and profiles.

FortiOS 7.2 Administration Guide, Section: Security Profiles > Data leak prevention. Explains the creation order: DLP Data Types (Patterns) -> DLP Dictionaries -> DLP Profiles -> DLP Rules.

FortiOS 7.0 Release Notes, Section: Changes in default behavior > DLP. Documents the architectural change where the "DLP sensor" object was officially deprecated and merged into the "DLP profile," proving "DLP Sensor" is the invalid option for current FortiSASE deployments.

In a FortiSASE Secure Internet Access (SIA) deployment utilizing the FortiClient agent, traffic steering and routing are managed via the endpoint profile. To direct specific internet traffic—such as Google Maps—out of the endpoint's local physical network interface rather than through the FortiSASE VPN tunnel, split tunneling must be utilized. FortiSASE allows administrators to define split tunneling exclusions directly within the endpoint profile using Fully Qualified Domain Names (FQDNs), IP addresses, subnets, or Internet Service Database (ISDB) objects. By configuring the Google Maps FQDN as a split tunneling destination, the FortiClient dynamically injects local routes to ensure that specific domain traffic bypasses the inspection tunnel.

A: System proxy exemptions apply strictly to Secure Web Gateway (SWG) explicitly proxied environments, not to the VPN tunnel-based traffic routing shown in the exhibit.

B: Operating systems generally do not support static routing directly via FQDNs. This dynamic routing must be handled by the FortiClient agent via the split tunnel configuration.

D: Changing DNS server configurations alters how domain names are resolved but does not dictate the physical or virtual routing path the resulting IP traffic will take.

Fortinet. (2023). FortiSASE Administration Guide: Endpoint Profile. Section: Configuring split tunneling. Retrieved from Fortinet Document Library (https://www.google.com/search?q=docs.fortinet.com).

Fortinet. (2023). FortiSASE Architecture Guide. Section: Traffic Steering and Secure Internet Access (SIA). Retrieved from Fortinet Document Library (https://www.google.com/search?q=docs.fortinet.com).

The VPN diagnostic output from the FortiGate hub (Exhibit 1) shows that Phase 2 is established, but the hub has only decrypted 3 packets (dec:pkts/bytes=3/120). This extremely low count indicates that the FortiSASE spoke is not forwarding the user's ICMP traffic into the IPsec tunnel. In FortiSASE Secure Private Access (SPA) architectures, dynamic routing via BGP over the IPsec tunnel is required to advertise hub subnets to the SASE nodes. If FortiSASE does not receive the BGP route for the webserver's destination subnet, it cannot route the ping traffic toward the hub. Exhibit 2 confirms the firewall policy explicitly allows ICMP, meaning routing is the point of failure.

A: The FortiSASE Secure Private Access policy exhibit explicitly shows the configured Service is set to ALL_ICMP, which natively permits ping traffic.

B: The diagnostic output shows src: 0.0.0.0-255.255.255.255 and dst: 0.0.0.0-255.255.255.255. These are universal wildcard selectors (0.0.0.0/0) that do not restrict any subnet traffic.

D: If NAT were the missing component, the packets would still route into the tunnel, meaning the hub's decrypted packet count (dec:pkts) would be actively incrementing rather than stuck at 3.

Fortinet, Inc. FortiSASE Administration Guide: Secure Private Access (SPA) Hub configuration. (Section: Configuring BGP routing for SPA). Details the requirement of BGP peering over IPsec dial-up interfaces to exchange routes between the FortiGate hub and FortiSASE security PoPs.

Fortinet, Inc. FortiOS CLI Reference. (Section: diagnose vpn tunnel list). Explains the interpretation of IPsec tunnel statistics, specifically that dec:pkts represents inbound ESP packets decrypted by the local gateway.

When Single Sign-On (SSO) is enabled on FortiSASE, all users are authenticated exclusively by the external identity provider; FortiSASE automatically disables or ignores local, RADIUS, or MFA settings that were configured earlier.

A. Local users are ignored once SSO is active.

C. RADIUS is bypassed when SSO is enabled.

D. MFA tied to local/RADIUS accounts is not consulted after SSO takeover.

1. FortiSASE for Remote Users Administration Guide 23.4, “Configuring SSO” – note: “SSO overrides any other user authentication method.”

2. Fortinet KB Article FD56069, “SSO precedence in FortiSASE,” para 1.

For a contractor working within the HQ office using a personal device, installing a full VPN client is often undesirable. FortiSASE can function as an explicit web proxy, providing Secure Web Gateway (SWG) services. By configuring the contractor's browser with a Proxy Auto-Configuration (PAC) file, their web traffic can be securely directed to FortiSASE for inspection and policy enforcement without requiring an agent. This method is ideal for providing temporary, secure internet access to guest or unmanaged endpoints on a corporate network.

B. A tunnel policy is for remote access users connecting via FortiClient VPN, not for users already on the corporate network needing internet access.

C. ZTNA is designed for secure access to specific private applications, not for providing general, secure internet access.

D. A self-registration portal is for user onboarding or guest network access, but the underlying security mechanism for internet traffic would still be SWG/proxy.

Fortinet. (2024). FortiSASE Architecture Guide 24.1. "Secure Web Gateway". p. 11. This section describes agentless access using a PAC file to direct browser traffic to FortiSASE for SWG inspection.

Fortinet. (2024). FortiSASE Administration Guide 24.1. "Explicit web proxy". p. 158. This section details how to configure FortiSASE as an explicit proxy and use PAC files for client configuration.

FortiSASE includes a built-in geofencing feature that evaluates the public IP address of a registering FortiClient. By defining allowed or blocked countries, the administrator can prevent endpoints located in those geographies from establishing the tunnel to any FortiSASE point-of-presence (PoP). The control is applied before FortiClient registration is completed, thereby fulfilling the requirement to “restrict endpoints from certain countries from connecting to FortiSASE.”

A. Network-lockdown only isolates the endpoint’s local network access; it does not examine the source country of a connection to FortiSASE.

B. Source IP anchoring fixes a user’s traffic to a selected PoP, not to country-based admission control.

C. Geography address objects work inside FortiSASE firewall policies—after a tunnel exists—so they cannot stop the initial connection.

1. Fortinet. “FortiSASE for Remote Users – Administration Guide v23.3,” Section “Geofencing,” pp. 62-64.

2. Fortinet KB Article #FD55792, “Using geofencing to allow or block FortiClient connections,” para. 2-3 (2023).

For full SSL deep inspection, FortiSASE performs a man-in-the-middle re-encryption process and therefore must act as a certificate authority. It generates a self-signed (or internal PKI-signed) root CA certificate that administrators distribute to all endpoint trust stores; only after the root certificate is trusted can FortiSASE present forged site certificates and decrypt HTTPS, allowing all security profiles—including web filtering, antivirus, application control, and file inspection—to examine the plaintext.

A – FortiSASE must be trusted by endpoints; third-party CA use without import is impossible for MITM.

B – A root or intermediate CA certificate is mandatory.

C – SSL inspection supports all content-inspection profiles, not just antivirus/file filter.

1. FortiSASE Administration Guide v23.4, “SSL/TLS Deep Inspection”, pp. 90-92.

2. FortiOS 7.4 SSL Inspection Handbook, “Distributing the SASE root CA”, §4.2.

3. Fortinet NSE7 SSE-AD courseware, Module 5 lab manual, Step 3 “Export and install SASE CA”.