Summary
When a FortiGate is configured to use FortiGuard servers for DNS resolution using the default settings, it uses the standard DNS protocol. This involves sending DNS queries directly to the FortiGuard servers' IP addresses over the well-known port for DNS, which is UDP port 53. This is the same method used by most traditional DNS resolvers.

Correct Option

D. It uses UDP 53.:
This is correct. By default, DNS communication between the FortiGate and the FortiGuard servers is unencrypted and uses the standard User Datagram Protocol (UDP) on port 53. This is the foundational protocol for DNS resolution across the internet.

Incorrect Option

A. It uses UDP 8888.:
This is incorrect. UDP port 8888 is used by the FortiGate for communication with the FortiGuard Distribution Network (FDN). This channel is for services like antivirus and IPS updates, web filtering categorization, and license validation, but it is not used for standard DNS queries.

B. It uses DNS over HTTPS.:
This is incorrect. While FortiGate supports DNS over HTTPS (DoH) as a client to forward queries from its own DNS server, and can even filter DoH traffic, the default configuration for using FortiGuard servers as DNS servers directly is standard DNS (UDP 53), not DoH.

C. It uses DNS over TLS.:
This is incorrect. Similar to DoH, DNS over TLS (DoT) is an encrypted DNS standard that uses TCP port 853. The FortiGate can be configured to use DoT, but this is not the default behavior when simply setting the FortiGuard servers as the DNS servers in the system network settings.

Reference
Fortinet Documentation Library: FortiGuard services ports (Lists UDP 53 for DNS and UDP 8888 for FDN communication).

Summary
The Fortinet Single Sign-On (FSSO) Collector Agent has two primary modes: Standard and Advanced. Advanced mode offers more sophisticated user and group identification by integrating directly with Active Directory. It supports complex group structures and uses a specific format for user identification that is compatible with Windows conventions.

Correct Option

B. Advanced mode supports nested or inherited groups.:
This is correct. A key advantage of advanced mode is its ability to resolve nested group memberships within Active Directory. If a user is a member of Group A, and Group A is a member of Group B, advanced mode will correctly identify the user as a member of both Group A and Group B, allowing for more granular and flexible firewall policies.

D. Advanced mode uses the Windows convention —NetBios: Domain\Username.:
This is correct. In advanced mode, user identities are presented in the standard Windows format DOMAIN\Username. This format is widely recognized and simplifies the creation of firewall policies, as it clearly distinguishes users from different domains and matches the format commonly used in Active Directory.

Incorrect Option

A. In advanced mode, FortiGate can be configured as an LDAP client and group filters can be configured on FortiGate.:
This is incorrect. This statement describes the FSSO LDAP Polling Agent method, not the Collector Agent in advanced mode. In the Collector Agent model, the agent software (running on a Windows server) handles the AD communication and group resolution, then forwards the user information to the FortiGate. The FortiGate itself is not acting as the LDAP client in this scenario.

C. In advanced mode, security profiles can be applied only to user groups, not individual users.:
This is incorrect. Firewall policies on FortiGate can use FSSO users as a source, and these policies can be applied to either individual users (DOMAIN\jsmith) or user groups (DOMAIN\Sales_Team). The advanced mode of the Collector Agent does not impose a restriction that prevents policies from being applied to individual users.

Reference
Fortinet Documentation Library: FSSO Collector Agent advanced mode (The documentation details the support for nested groups and the user identity format).

Summary
The Reverse Path Forwarding (RPF) check is a security feature used to mitigate IP spoofing attacks. It works by verifying that the source IP address of an incoming packet is reachable through the same interface on which the packet was received. This check is performed at the very beginning of a session to determine if the traffic is legitimate before establishing a session entry.

Correct Option

A. The RPF check is run on the first sent packet of any new session.:
This is correct. The RPF check is triggered by the very first packet that initiates a new session (the "sent" packet from the perspective of the originator). The FortiGate uses this packet to verify the validity of the source IP before creating a session in the session table.

D. The RPF check is a mechanism that protects FortiGate and the network from IP spoofing attacks.:
This is correct. This is the primary purpose of the RPF check. By ensuring that a packet arrives on the interface that would be used to route traffic back to its source, it prevents an attacker from forging (spoofing) a source IP address, which is a common technique in reflection and amplification attacks.

Incorrect Option

B. The RPF check is run on the first reply packet of any new session.:
This is incorrect. The RPF check is performed on the initial packet that starts the session. Once a session is established in the session table, subsequent packets, including reply packets, are matched to the existing session and do not undergo a new RPF check.

C. The RPF check is run on the first sent and reply packet of any new session.:
This is incorrect. The check is a one-time operation performed only on the initial packet of a session to validate the source. The reply packet is part of the established session and is not subject to a second RPF verification.

Reference
Fortinet Documentation Library: Reverse path forwarding

Summary
During SSL/SSH full inspection on FortiGate, if an invalid certificate is detected (e.g., expired, untrusted, or mismatched), administrators can configure specific actions in the SSL/SSH inspection profile. Valid responses include blocking the connection outright, allowing it silently, or combining block/allow with a warning page to inform users, balancing security and usability.

Correct Option

A. Allow & Warning
FortiGate permits the SSL/SSH session to proceed despite the invalid certificate but injects a warning page (for HTTPS) or notification to alert the user. This allows controlled access while maintaining visibility into potential risks.

D. Block & Warning
FortiGate blocks the connection and displays a warning page explaining the certificate issue (e.g., expired or untrusted). This enforces strict security while educating users, commonly used in high-security environments.

E. Block
FortiGate immediately drops the SSL/SSH session without any user notification when an invalid certificate is detected. This silent enforcement ensures no risky connections proceed, ideal for automated or strict policy compliance.

Incorrect Option

B. Trust & Allow
There is no "Trust & Allow" action in FortiGate SSL/SSH inspection profiles. Certificates are either validated against trusted CAs or marked invalid; FortiGate cannot dynamically "trust" an invalid certificate without manual CA import.

C. Allow
While allowing invalid certificates may seem plausible, FortiGate does not offer a standalone "Allow" action without warning in full inspection mode. Silent allowance contradicts deep inspection security principles and is not a configurable option.

Reference
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/432567/ssl-inspection#deep-inspection

Summary
SD-WAN rules use strategies to determine how traffic is distributed across member interfaces. These strategies are based on performance measurements (SLA) and can be configured to either use a single best-performing member or to load-balance across multiple members that meet the performance criteria.

Correct Option

A. Manual with load balancing:
This is a valid strategy. It ignores SLA targets and distributes traffic according to a manually configured weight (ratio) assigned to each SD-WAN member interface. This is useful for basic, non-performance-based distribution of traffic.

B. Lowest Cost (SLA) with load balancing:
This is a valid strategy. It identifies all member interfaces that meet the configured SLA targets and then performs load balancing across them. The "Lowest Cost" refers to the interface priority/weight, where traffic is preferably sent over higher-priority (lower cost) members.

C. Best Quality with load balancing:
This is a valid strategy. It identifies all member interfaces that meet the SLA targets and then load-balances sessions across them. This strategy is focused on maintaining quality by only using members that pass the SLA health checks.

Incorrect Option

D. Lowest Quality (SLA) with load balancing:
This is not a valid strategy. There is no defined strategy that intentionally selects the lowest quality members. The purpose of SD-WAN is to enhance performance and reliability by using the best-available paths, not the worst.

E. Lowest Cost (SLA) without load balancing:
This is a distractor and not a direct strategy name. The standard "Lowest Cost" strategy without the load-balancing option simply selects the single highest-priority (lowest cost) member that meets the SLA targets. It does not actively load balance across multiple members.

Reference
Fortinet Documentation Library: SD-WAN rule strategy (Documents the Manual, Lowest Cost, and Best Quality strategies and the load-balance option).

Summary
This scenario describes a site-to-site connection using SSL VPN between two FortiGate devices, where one acts as the client (initiator) and the other as the server (listener). For this to work, the client must be configured with the correct tunnel interface type to establish the connection, and both parties must use certificates for authentication, with the server trusting the CA that issued the client's certificate.

Correct Option

A. The client FortiGate requires the SSL VPN tunnel interface type to connect SSL VPN:
This is correct. On the client FortiGate, the SSL VPN is configured under a tunnel interface (usually of type ssl-vpn). This interface is the endpoint for the tunnel and is used in firewall policies and routing, just like an IPsec tunnel interface. This configuration is mandatory for the client to initiate the connection.

C. The client FortiGate requires a client certificate signed by the CA on the server FortiGate.:
This is correct. For certificate-based authentication, the client FortiGate must have a certificate (a "client certificate") that is signed by a Certificate Authority (CA) which the server FortiGate trusts. The server uses its CA certificate to verify the signature on the client's certificate, establishing trust.

Incorrect Option

B. The server FortiGate requires a CA certificate to verify the client FortiGate certificate.:
This is partially true but not strictly "required" in all cases. While certificate authentication is highly recommended and more secure, the server FortiGate can also be configured to use pre-shared keys (PSK) for authentication. Therefore, a CA certificate is not an absolute requirement for the SSL VPN to function.

D. The client FortiGate requires a manually added route to remote subnets.:
This is not a requirement for the SSL VPN to function (establish). While a static route is necessary for the client FortiGate to know to send traffic for the remote network over the SSL VPN tunnel, the tunnel interface can be established without it. The route is needed for traffic to flow through the tunnel after it is up, but it is not a prerequisite for the tunnel itself to come online.

Reference
Fortinet Documentation Library: SSL VPN for FortiGate (This guide covers the configuration of both the server and client FortiGate, including interface and certificate settings).

Summary
A high-latency connection causes significant delays in packet delivery. The SSL VPN negotiation process has built-in timers that expect a response within a specific window. If the round-trip time exceeds this window due to latency, the negotiation will fail. Adjusting the timer for the initial handshake phase can resolve this.

Correct Option

C. SSL VPN dtls-hello-timeout:
This is the correct setting. DTLS (Datagram Transport Layer Security) is the protocol often used to accelerate SSL VPN performance by running over UDP. The dtls-hello-timeout defines how long the FortiGate will wait for a response to its initial DTLS "ClientHello" message. On a high-latency link, increasing this value gives the remote client more time to respond, preventing the FortiGate from prematurely terminating the negotiation.

Incorrect Option

A. SSL VPN idle-timeout:
This setting determines how long an established SSL VPN tunnel can remain idle before it is automatically disconnected. It does not affect the initial connection negotiation phase and will not help with a negotiation failure.

B. SSL VPN login-timeout:
This setting defines how long a user has to enter their credentials on the SSL VPN web portal after the HTTP connection is established. It is unrelated to the underlying DTLS/TLS handshake that happens during the tunnel negotiation.

D. SSL VPN session-ttl:
This setting defines the maximum total lifetime of an SSL VPN session, after which the user must reconnect. It is a limit for active sessions and does not impact the initial setup handshake on a slow link.

Reference
Fortinet Documentation Library: config vpn ssl web portal (The set dtls-hello-timeout command is available within this context to adjust the wait time).

Summary
The FortiGate Collector Agent (CA) for Fortinet Single Sign-On (FSSO) uses AD polling to gather user logon information when event log-based methods are unavailable. It supports three polling methods: WMI for remote logon session queries, NetAPI for browser-based domain enumeration, and WinSecLog for Windows Security Event Log polling, enabling reliable identity mapping in diverse environments.

Correct Option

B. WMI
The Collector Agent uses Windows Management Instrumentation (WMI) to remotely query domain controllers for active logon sessions. It polls every 10 seconds by default, retrieving username, IP, and workstation details without requiring event logs, ideal for environments with restricted DC access.

C. NetAPI
NetAPI (Network API) allows the CA to query domain controllers via NetSessionEnum and NetWkstaUserEnum calls. This method enumerates logged-on users per server, supporting legacy systems and providing fallback when WMI is blocked or unavailable.

A. WinSecLog
WinSecLog polls Windows Security Event Logs (specifically event IDs 4624/4768) on domain controllers at configurable intervals. It captures logon events in real-time if polling is frequent, serving as an alternative to DC agent push methods.

Incorrect Option

D. FSSO REST API
The FSSO REST API is used for communication between FortiGate and Collector Agent or for third-party integrations, not as a polling method. The CA does not poll AD via REST; it relies on native Windows protocols like WMI/NetAPI.

E. FortiGate polling
FortiGate itself does not poll AD for FSSO; it receives user-to-IP mappings from the Collector Agent or DC Agent. Direct FortiGate polling of AD is limited to LDAP group filters, not logon session discovery.

Reference
https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/975464/collector-agent-based-polling

Explanation:

In agentless polling mode, the FortiGate acts as a collector to retrieve user information directly from a Microsoft Windows domain controller. It does this by querying the controller's Active Directory (AD) service. The standard protocol for querying and updating directory services like Active Directory is LDAP (Lightweight Directory Access Protocol). Therefore, the administrator must configure an LDAP server entry on the FortiGate, pointing it to the domain controller's IP and providing the necessary bind credentials and base distinguished name (DN) for the search. The FortiGate uses this LDAP connection to poll the AD for user-to-IP mappings and group memberships.

Why the other options are incorrect:

B. RADIUS server:
RADIUS is a protocol primarily used for authentication, authorization, and accounting (AAA) for network access (e.g., VPN users, Wi-Fi logins). It is not the protocol used to query Active Directory for user lists and group memberships. While FortiGate can use RADIUS for authentication, it is not the required component for agentless AD polling.

C. DHCP server:
A DHCP server assigns IP addresses to clients on a network. While the FortiGate agentless collector uses IP addresses to identify users, it does not retrieve user or group information from a DHCP server. The DHCP server itself holds no user identity data.

D. Windows server:
While this is technically true that the source of the information is a Windows server (the domain controller), it is not the specific component that must be added to the FortiGate configuration. The precise configuration object created on the FortiGate is an LDAP server entry, which targets the Windows server. The option is too vague; the exam expects the specific protocol/service (LDAP) used for the connection.

Reference:
Fortinet Documentation Library - "FortiGate FortiOS 7.4 Administration Guide," specifically the chapters on User & Authentication and Fortinet Single Sign-On (FSSO) agentless polling mode configuration

Explanation:

On a FortiGate, the ability to enable a DHCP server on an interface is directly tied to the interface's Role. If an interface is configured with the role WAN (in many default configurations or SD-WAN zones), the GUI will not provide the option to enable a DHCP server on that interface. This is a design restriction because WAN interfaces typically receive dynamic addresses from an ISP and are not intended to act as DHCP servers for internal networks. To enable a DHCP server, the interface must have its role set to LAN or another non-WAN role (or have no specific role assigned).

Why the other options are incorrect:

B. The DHCP server setting is available only on the CLI:
This is false. The DHCP server is fully configurable via both the GUI and the CLI. The issue described is a GUI-specific restriction based on interface role.

C. Another interface is configured as the only DHCP server on FortiGate:
This is false. A FortiGate can have a DHCP server enabled on multiple interfaces simultaneously. There is no restriction that limits the device to only one DHCP server instance.

D. The FortiGate model does not support the DHCP server:
This is false. The DHCP server is a fundamental, universally supported feature across all FortiGate models and firmware versions.

Reference:
This behavior is documented in the FortiGate administration guide under Network -> Interfaces and Network -> DHCP Server. The GUI dynamically shows or hides configuration options based on the interface's assigned role.

Explanation:

FortiGate follows a specific, hierarchical order when inspecting HTTP traffic with multiple web filtering features enabled. When a request is made, the firewall evaluates it against the configured filters in this fixed sequence. Features like Safe Search are considered "advanced filters" (also referred to as content filters or feature filters in some documentation). The correct, general order is:

Static URL Filter: Exact URL matches in block/allow lists are checked first.
FortiGuard Category/Rating Filter: The URL is categorized by FortiGuard.
Advanced Filters: Finally, features like Safe Search, YouTube Education filter, script blocking, etc., are applied.

This order ensures that explicit allows/blocks take precedence, followed by categorization, and finally specific content manipulations or checks.

Why the other options are incorrect:

A. FortiGuard category filter and rating filter:
This is incomplete. While these are key components, they come after static URL filtering in the order of operations.

B. Static domain filter, SSL inspection filter, and external connectors filters:
This sequence is incorrect. SSL inspection is a prerequisite for deep inspection of HTTPS traffic but is not part of the sequential logic of the web filter scan. External connectors (like ICAP) are typically applied at a different stage. The core, internal web filter evaluation order is different.

C. DNS-based web filter and proxy-based web filter:
These are different modes or methods of web filtering (DNS Filter vs. Flow/Proxy-based Web Filter), not the sequential order of feature evaluation within a single profile.

Reference:

FortiOS Administration Guide, specifically the Web Filter chapter, details the "order of scanning" for web filter profiles. The documentation states that Web Filter processing follows the sequence: Static URL Filter -> FortiGuard Web Filtering (Category/Rating) -> Web Content Filter (which includes features like Safe Search, YouTube restrictions, etc.).

Explanation:
The requirement has two main objectives:
Path Selection: Ensure the primary tunnel is used when both are up.

Fast Failover: Detect a dead tunnel quickly to fail over to the secondary.
To achieve this, two specific configuration changes are needed:

C. Configure route distances:
In FortiOS (and standard IP routing), the route with the lowest administrative distance is preferred. Therefore, to make the primary tunnel the preferred path, its associated static route must have a lower distance value than the route for the secondary tunnel. This ensures the primary route is installed in the routing table when the tunnel is active, meeting the "all traffic must be routed through the primary" requirement.

A. Enable Dead Peer Detection (DPD):
DPD is a mechanism that allows an IPsec peer to determine if another peer is still alive ("reachable"). When enabled, the FortiGate can detect a failed tunnel more quickly than waiting for a Phase 1 or Phase 2 timeout. This "speeds up tunnel failover" as explicitly required. DPD is configured within the IPsec VPN Phase 1 settings.

Reference:

Route Distance:
FortiOS Administration Guide -> Routing chapter explains that the route with the lowest distance is preferred.
Dead Peer Detection:
FortiOS Administration Guide -> IPsec VPN chapter details DPD settings for faster failure detection.

Why the other options are incorrect:

B. Enable Auto-negotiate and Autokey Keep Alive on the phase 2 configuration:
This is incorrect and partially misleading.
Auto-negotiate is typically a Phase 1 setting that allows automatic renegotiation of Security Associations (SAs), but it is not the primary mechanism for fast failure detection.
Autokey Keep Alive is not a standard FortiGate IPsec term for tunnel health checking. The correct feature for fast tunnel failure detection is Dead Peer Detection (DPD), which is configured in Phase 1.

D. Configure a higher distance on the static route for the primary tunnel...:
This is the opposite of what is required. A higher administrative distance makes a route less preferred. Configuring this would cause the secondary tunnel to be used even when the primary is up, violating the core requirement.