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:

To retrieve AD user group information in agentless polling mode, the administrator must add an LDAP server to the FortiGate device.

Explanation:

FortiGate interfaces can be configured in different roles, such as WAN or LAN. If an interface is set as a "WAN" role, you cannot configure it to act as a DHCP server through the GUI. The interface role must be set to "LAN" or "Undefined" to allow DHCP server configuration.

Explanation:

FortiGate applies web filters in the following order: Static URL filter, FortiGuard category filter, Web content filter, Web script filter, and Antivirus scanning.

Explanation:

To configure redundant IPsec VPN tunnels on FortiGate with failover capability, the following two key configuration changes are required:

A. Enable Dead Peer Detection (DPD): Dead Peer Detection is crucial for detecting if the remote peer is unreachable. By enabling DPD, FortiGate can quickly detect a dead tunnel, ensuring a faster failover to the secondary tunnel when the primary tunnel goes down.

C. Configure a lower distance on the static route for the primary tunnel and a higher distance on the static route for the secondary tunnel: The static route with the lower distance (higher priority) will be used when both tunnels are operational. If the primary tunnel fails, the higher distance (lower priority) route for the secondary tunnel will take over, ensuring traffic is routed correctly.

The other options are not suitable:

B. Enable Auto-negotiate and Autokey Keep Alive on the phase 2 configuration of both tunnels:

This option is not directly related to the requirements of failover between two IPsec VPN tunnels.

D. Configure a higher distance on the static route for the primary tunnel and a lower distance on the static route for the secondary tunnel: This would prioritize the secondary tunnel over the primary tunnel, which is opposite to the desired configuration.