Fortinet FCP_FGT_AD-7.4 Practice Questions

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

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).