Summary
When a FortiGate is configured as a Profile-based NGFW, it uses security profiles (like IPS, Application Control, and Antivirus) that are applied to traffic matching firewall policies. The default and most common inspection mode for this methodology is flow-based inspection. This mode provides a balance of strong security and high performance by scanning traffic as it flows through the device without breaking the client-server session.

Correct Option

D. Flow-based inspection:
This is correct. In a profile-based NGFW configuration, the primary inspection mode is flow-based. The security profiles (IPS, Application Control, Antivirus, Web Filter, DNS Filter) are processed by a single-pass engine that inspects the traffic as it streams through the FortiGate. This method is less resource-intensive than proxy-based inspection and is designed for high-throughput scenarios while maintaining deep inspection capabilities.

Incorrect Option

A. Full content inspection:
This is a vague term and not the specific name of an inspection mode in this context. "Full content inspection" is a capability that can be performed by both flow-based and proxy-based inspection engines. However, it is not the official term for the default mode used by a profile-based NGFW.

B. Proxy-based inspection:
This is incorrect. Proxy-based inspection is a separate, more intensive mode where the FortiGate terminates the client and server connections and acts as an intermediary. While it can be enabled for specific protocols or policies, it is not the default inspection mode for a profile-based NGFW deployment. Policy-based NGFW (a different methodology) uses proxy-based inspection.

C. Certificate inspection:
This is incorrect. Certificate inspection is a specific function related to SSL/TLS decryption and analysis. It is not the overarching inspection mode for the entire set of application profiles. Certificate inspection can occur within either flow-based or proxy-based inspection modes when dealing with encrypted traffic.

Reference
Fortinet Documentation Library: Security inspection modes

Summary
Equal-Cost Multi-Path (ECMP) routing allows a FortiGate to load-balance traffic across multiple next-hop gateways for the same destination network. The configuration method differs based on whether SD-WAN is enabled. When SD-WAN is disabled, ECMP settings are controlled via CLI system settings. When SD-WAN is enabled, its own load-balancing algorithms take precedence for member selection.

Correct Option

A. If SD-WAN is enabled, you control the load balancing algorithm with the parameter load-balance-mode.:
This is correct. When the SD-WAN feature is enabled, it manages the load-balancing behavior for its member interfaces. The set load-balance-mode command within the SD-WAN configuration is used to choose the algorithm, such as source-destination-ip-based (default), volume-based, or usage-based.

D. If SD-WAN is disabled, you configure the load balancing algorithm in config system settings.:
This is correct. When SD-WAN is not in use, the global ECMP behavior for static and dynamic routes is controlled in the main system settings via the config system settings section. The set v4-ecmp-mode command is used here to define the load-balancing method.

Incorrect Option

B. If SD-WAN is disabled, you can configure the parameter v4-ecmp-mode to volume-based.:
This is incorrect. The v4-ecmp-mode parameter, configured in config system settings, determines how the FortiGate distributes sessions, not volume. The available options are source-ip-based (default), weight-based, and usage-based. There is no volume-based option for this specific command. Volume-based load balancing is a feature of SD-WAN.

C. If SD-WAN is enabled, you can configure routes with unequal distance and priority values to be part of ECMP:
This is incorrect. A fundamental rule of ECMP is that the routes must have the same distance (also known as administrative distance) and priority (metric) to be considered equal-cost. If SD-WAN is enabled and routes have different distances or priorities, the route with the best (lowest) distance and priority will be active, and the others will be passive backups, not part of an ECMP group.

Reference
Fortinet Documentation Library: ECMP load balancing method

Fortinet Documentation Library: SD-WAN rule settings (See the load-balance-mode setting)

Summary
Automation stitches are a powerful feature on FortiGate that link a trigger event to a set of automated actions. A key characteristic is that a single stitch can be configured with multiple triggers, such as a specific log event occurring AND a high CPU condition, providing flexible and conditional automation logic.

Correct Option

C. They can have one or more triggers.:
This is correct. An automation stitch is defined by its triggers and its actions. The FortiOS interface allows you to add multiple triggers to a single stitch. These triggers can be combined with logical operators (AND, OR), allowing for complex automation scenarios that only execute when a specific set of conditions is met.

Incorrect Option

A. They can be run only on devices in the Security Fabric.:
This is incorrect. While automation stitches are a core component of the Security Fabric and can be triggered by fabric events, they are a local device feature. You can create and run automation stitches on a standalone FortiGate that is not part of any fabric.

B. They can be created only on downstream devices in the fabric.:
This is incorrect. Automation stitches can be created and run on any FortiGate in the fabric, including the root FortiGate (Security Fabric leader). There is no restriction limiting their creation to downstream (child) devices.

D. They can run multiple actions at the same time.:
This is misleading and not the most accurate description. While a stitch can contain multiple actions, they are executed sequentially by default, not simultaneously. The stitch executes its list of actions one after the other. It does not fork a process to run actions in parallel.

Reference
Fortinet Documentation Library: Automation stitches

Summary
The scenario involves a single, mobile user (a sales employee) who needs to establish a secure VPN connection back to the corporate network from various remote locations. This is the classic use case for a remote access VPN, where individual clients dynamically get an IP address and connect to a central gateway.

Correct Option

A. Remote Access:
This is the correct wizard template. The Remote Access IPsec Wizard is specifically designed to configure the FortiGate as a VPN head-end for connecting individual users. It automates the setup of parameters like user authentication, client IP address assignment, and firewall policies to allow the remote user access to the internal network, which is precisely what is needed for a traveling employee.

Incorrect Option

B. Site to Site:
This template is used to create a permanent VPN tunnel between two fixed locations, such as a corporate headquarters and a branch office. It connects two entire networks, not a single roaming user, making it unsuitable for this scenario.

C. Dial up User:
This is a distractor. While "dial-up" conceptually relates to remote access, it is not the primary or recommended wizard for a standard IPsec VPN for a traveling employee. The "Remote Access" wizard is the standard and correct choice for configuring IPsec for mobile users.

D. iHub-and-Spoke:
This template is part of FortiGate's SD-WAN functionality for building overlay networks between multiple sites (hubs and spokes). It is not intended for providing remote access to a single, mobile end-user.

Reference
Fortinet Documentation Library: IPsec VPN wizards (The Remote Access wizard is described as being for "client-to-gateway" configurations).

Summary
When FortiGate performs SSL certificate inspection, it needs to identify the intended destination server (hostname) to make accurate security policy decisions, such as applying the correct web filter or application control policy. It does this by examining specific parts of the SSL/TLS handshake and the server's certificate before potentially blocking the connection based on its security profiles.

Correct Option

A. The host field in the HTTP header.:
This is correct for HTTP/HTTPS traffic. After the SSL/TLS session is established, the client sends an HTTP request. The Host: header in this request explicitly states which website the client is trying to reach. The FortiGate can use this information for deeper application-level filtering.

B. The server name indication (SNI) extension in the client hello message.:
This is correct and is the primary method. The SNI is an extension sent by the client very early in the TLS handshake (in the ClientHello message). It contains the hostname of the server the client wants to connect to, allowing the FortiGate to identify the service before the certificate is even exchanged.

C. The subject alternative name (SAN) field in the server certificate.:
This is correct. The server presents its certificate to the client. The SAN field within this certificate lists all the domain names for which the certificate is valid. The FortiGate can inspect this field to verify the hostname it identified via SNI matches one of the entries in the SAN.

Incorrect Option

D. The subject field in the server certificate.:
While the Subject field contains a Common Name (CN) which was historically used to specify the hostname, modern best practices and certificates rely primarily on the SAN extension for this purpose. The FortiGate may check the CN if the hostname is not found in the SAN, but the SAN is the definitive and standard source.

E. The serial number in the server certificate.:
This is incorrect. The serial number is a unique identifier assigned by the Certificate Authority (CA) for internal management and revocation purposes (e.g., CRL). It does not contain any information about the server's hostname and is not used by the FortiGate for hostname identification.

Reference
Fortinet Documentation Library: Certificate inspection (The process involves deep packet inspection of the TLS handshake, including SNI and certificate fields).

Summary
Profile-based mode is one of the two primary Next-Generation Firewall (NGFW) operation modes on FortiGate. In this mode, administrators create security profiles (like AV, IPS, Web Filter) and then apply a collection of these profiles to traffic that is permitted by a firewall policy. It is the most common and flexible mode, allowing a mix of inspection types and supporting advanced features like application control.

Correct Option

C. NGFW profile-based mode policies support both flow inspection and proxy inspection.:
This is correct. A key feature of profile-based mode is its flexibility in inspection methods. While the default and most common inspection is flow-based for performance, the administrator can enable proxy-based inspection for specific protocols (like HTTP, FTP, SMTP) within a firewall policy if deeper, protocol-specific analysis is required.

D. NGFW profile-based mode supports applying applications and web filtering profiles in a firewall policy.:
This is correct. The defining characteristic of profile-based mode is the ability to attach security profiles directly to firewall policies. This includes Application Control and Web Filter profiles, which allow the administrator to control which applications and websites are allowed by the policy that permits the traffic.

Incorrect Option

A. NGFW profile-based mode can only be applied globally and not on individual VDOMs.:
This is incorrect. The NGFW mode (both profile-based and policy-based) is a per-VDOM setting. An administrator can configure one VDOM to use profile-based mode while another VDOM on the same FortiGate uses policy-based mode, providing flexibility in multi-tenant environments.

B. NGFW profile-based mode must require the use of central source NAT policy.:
This is incorrect. Profile-based mode is fully compatible with the standard, policy-based NAT configuration (where NAT is enabled or disabled within each individual firewall policy). The Central SNAT policy is an alternative, advanced method for managing NAT, but it is not a requirement for using profile-based mode.

Reference
Fortinet Documentation Library: NGFW operation modes

Summary
This question concerns out-of-band management access, which is crucial when the FortiGate's network interfaces are down or misconfigured. The method that allows CLI access independently of the device's IP configuration, network stack, or physical network connectivity is the direct physical serial connection.

Correct Option

C. Serial console:
This is the correct method. The serial console port on the FortiGate provides direct, out-of-band access to the CLI using a physical RS-232 serial connection. It operates at a hardware level, completely independent of the device's software network configuration. This makes it the primary method for initial setup, password recovery, and troubleshooting when network-based management is unavailable.

Incorrect Option

A. SSH console:
This is incorrect. SSH (Secure Shell) is a network protocol that requires the FortiGate's network interfaces to be configured, IP addresses to be assigned, and the SSH service to be enabled on an interface. If there is no network connectivity or the network stack is faulty, SSH will not be accessible.

B. CLI console widget:
This is incorrect. The CLI console widget is a feature within the FortiGate's web-based manager (GUI). Accessing it requires a successful GUI login, which itself depends on network connectivity to the management IP address (via HTTP/HTTPS). It is a form of in-band management.

D. Telnet console:
This is incorrect. Similar to SSH, Telnet is a network protocol. It requires the FortiGate to have a functional network configuration with an IP address and the Telnet service enabled on an interface. It is not available if network connectivity is lost.

Reference
Fortinet Documentation Library: Using the serial console

Summary
In a FortiGate High Availability (HA) cluster, configuration synchronization is a core function that maintains a consistent operating state across all members. The process uses checksums to verify configuration consistency and can synchronize configuration changes made on any cluster unit, not just the primary.

Correct Option

A. Checksums of devices are compared against each other to ensure configurations are the same.:
This is correct. The HA cluster members periodically calculate a checksum (hash) of their configuration files. These checksums are compared between units. If a mismatch is detected, it indicates a configuration drift, and the cluster can automatically synchronize the configuration from the primary unit to the subordinate unit(s) to restore consistency.

C. Incremental configuration synchronization can occur from changes made on any FortiGate device within the HA cluster.:
This is correct. While the primary unit is the authoritative source for the running configuration, you can make configuration changes directly on a subordinate unit (for example, via a dedicated management interface). When this happens, the cluster performs an "election," the unit that was changed becomes the new primary, and its configuration is synchronized to all other members. This ensures the most recent change is propagated cluster-wide.

Incorrect Option

B. Incremental configuration synchronization can occur only from changes made on the primary FortiGate device.:
This is incorrect. As explained above, changes made on a subordinate unit will trigger a synchronization event. The cluster is designed to synchronize the most recent configuration change, regardless of which unit it originates from, by promoting the changed unit to primary.

D. Checksums of devices will be different from each other because some configuration items are not synced to other HA members.:
This is incorrect. The purpose of the checksum comparison is to ensure configurations are identical. While there are a very few device-specific settings (like the HA priority and hostname) that are not synchronized, the cluster management logic accounts for this. The compared checksums are calculated on the synchronizable parts of the configuration. A persistent checksum mismatch is treated as an error condition, not a normal state.

Reference
Fortinet Documentation Library: HA configuration synchronization

Summary
The scenario describes a Man-in-the-Middle (MITM) SSL inspection setup where the FortiGate uses its own Private CA certificate to resign all HTTPS traffic. The browser warnings occur because the client workstations do not trust this Private CA. For this inspection to work seamlessly, the FortiGate's Private CA certificate must be installed into the "Trusted Root Certification Authorities" store on every client machine.

Correct Option

C. The browser does not recognize the certificate in use as signed by a trusted CA.:
This is the correct and direct reason. During full SSL inspection, the FortiGate intercepts the server's certificate and generates a new one signed by its own Private CA. The client browser checks the certificate chain and flags it as untrusted because the FortiGate's Private CA is not in the browser's or operating system's list of trusted root certificate authorities, resulting in the warning error.

Incorrect Option

A. The SSL cipher compliance option is not enabled on the SSL inspection profile. This setting is required when the SSL inspection profile is defined with a private CA certificate.:
This is incorrect. The "Certificate-based SSL cipher compliance" feature is used to block connections to servers that use weak ciphers. It is a security enforcement setting and is not a requirement for the basic function of certificate replacement in SSL inspection. It does not cause the described certificate trust warnings.

B. The certificate used by FortiGate for SSL inspection does not contain the required certificate extensions.:
This is unlikely to be the primary cause. While a poorly configured certificate could cause issues, the FortiGate automatically generates certificates with the necessary extensions (like Subject Alternative Name) during inspection to mimic the original server certificate. The core issue remains the lack of trust in the root CA, not the structure of the individual site certificate.

D. With full SSL inspection it is not possible to avoid certificate warning errors at the browser level.:
This is incorrect. It is absolutely possible to avoid these warnings. The standard and recommended practice is to deploy the FortiGate's Private CA certificate to all client machines on the network. Once the clients trust this CA, the FortiGate's resigned certificates will be accepted as valid, and the warnings will cease.

Reference
Fortinet Documentation Library: SSL inspection (The documentation explains the requirement for clients to trust the CA certificate used for deep inspection).

Summary
NTurbo is a performance acceleration technology available on certain FortiGate models. It is specifically designed to optimize flow-based inspection, which is the default mode for profile-based policies. It works by creating a highly efficient, shortcut data path within the FortiGate's network processor, allowing traffic to bypass the more resource-intensive general CPU path for sessions that only require basic security profiling.

Correct Option

D. NTurbo creates a special data path to redirect traffic between the IPS engine its ingress and egress interfaces.:
This is the most accurate description. NTurbo establishes an optimized data path that integrates the flow-based IPS engine directly with the network interfaces on a specialized processor (like an NP6 or SoC4). This allows for traffic to be inspected and forwarded at near-wire speed by keeping the entire process within the accelerated hardware path, minimizing latency and maximizing throughput for flow-based traffic.

Incorrect Option

A. NTurbo offloads traffic to the content processor.:
This is incorrect. The Content Processor (CP) is a separate ASIC designed for compute-intensive tasks like virus scanning, deep packet inspection, and encryption. NTurbo's function is not to offload traffic to the CP, but rather to keep traffic within the Network Processor (NP) path, which is faster for basic flow-based inspection.

B. NTurbo creates two inspection sessions on the FortiGate device.:
This is incorrect. NTurbo does not create multiple sessions. Its purpose is to optimize the handling of a single session by using a more efficient data path, reducing the processing overhead per session.

C. NTurbo buffers the whole file and then sends it to the antivirus engine.:
This is incorrect. This description characterizes proxy-based inspection, which is the opposite of what NTurbo is designed for. NTurbo accelerates flow-based inspection, where files are scanned as a stream without full buffering. Buffering an entire file would introduce latency and defeat the performance benefits of NTurbo.

Reference
Fortinet Documentation Library: NTurbo

Summary
When a FortiGate is managed by a FortiManager, a unique identifier is added to each firewall policy. This UUID allows the FortiManager to accurately track, manage, and push updates to specific policies across multiple devices and policy packages. This same identifier is also used in logs sent to FortiAnalyzer, ensuring that log entries can be correctly associated with their originating policy for consistent reporting and analysis.

Correct Option

D. Universally Unique Identifier (UUID):
This is correct. When a FortiGate is integrated with FortiManager (and by extension, FortiAnalyzer for logging), each firewall policy is assigned a unique, persistent UUID. This allows FortiManager to precisely identify and manage the policy across administrative changes. In logs, this UUID ensures that even if the policy ID number changes locally due to policy reordering, the log can still be correctly correlated to the intended policy in FortiAnalyzer reports.

Incorrect Option

A. Log ID:
This is incorrect. A "Log ID" typically refers to the unique identifier for an individual log entry itself (e.g., a log serial number), not a persistent attribute of the firewall policy that created the log.

B. Policy ID: This is incorrect. The Policy ID is a sequential number (1, 2, 3...) assigned by the local FortiGate. This number can change if policies are reordered, inserted, or deleted. It is not a stable, unique identifier for centralized management and logging correlation, which is why the UUID is used.

C. Sequence ID:
This is incorrect and is generally a distractor. "Sequence ID" is not a standard attribute used for this purpose. The standard sequential number is the Policy ID.

Reference
Fortinet Documentation Library: FortiManager Administration Guide - Policy UUID (Explains the purpose and importance of the UUID for policy management).

Summary
When High Availability (HA) override is disabled, the FortiGate cluster determines the primary device based on a hierarchy of conditions. The process prioritizes the device with the most functioning monitored interfaces. If that is equal, it then compares manually configured priority values, followed by the device with the longest uptime as a final, deterministic tie-breaker.

Correct Option

C. Connected monitored ports > Priority > HA uptime > FortiGate serial number:
This is the correct sequence. The election process is:

Connected monitored ports: The device with the highest number of working monitored interfaces becomes primary.

Priority: If the number of working monitored interfaces is equal, the device with the lower configured priority number (e.g., 200 is higher than 100) becomes primary.

HA Uptime: If priority is also equal, the device that has been part of the HA cluster for the longest time (its HA uptime) becomes primary.

Serial Number: This is the ultimate tie-breaker. If all other criteria are identical, the device with the lower serial number becomes primary.

Incorrect Option

A. Connected monitored ports > Priority > System uptime > FortiGate serial number:
This is incorrect because it uses "System uptime" instead of "HA uptime." System uptime is the total time since the device was last rebooted, which is not relevant to the cluster's formation. The correct metric is "HA uptime," which is the duration the device has been a stable member of the current HA cluster.

B. Connected monitored ports > System uptime > Priority > FortiGate serial number:
This is incorrect for two reasons. It incorrectly prioritizes "System uptime" over the configured "Priority," and it uses "System uptime" instead of "HA uptime." The configured priority is a more important factor in the election than the device's total uptime.

D. Connected monitored ports > HA uptime > Priority > FortiGate serial number:
This is incorrect because it prioritizes "HA uptime" over the manually configured "Priority." The administrator-defined priority value is a more significant factor in the election decision than how long a device has been in the cluster.

Reference
Fortinet Documentation Library: HA operating parameters and election process