Fortinet FCP_FGT_AD-7.4 Practice Questions

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