Free FCP_FGT_AD-7.4 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The Fortinet Security Fabric operates in a hierarchical structure with one FortiGate designated as the 'root' or 'upstream' device. When other Fortinet devices (downstream FortiGates, FortiAnalyzers, etc.) are configured to join the fabric, they send an authorization request to this root FortiGate. The final step of integrating a new device requires an administrator to log in to the root FortiGate's GUI, navigate to the Security Fabric settings, and explicitly authorize the pending device. This action establishes the trust relationship and officially adds the device to the Security Fabric topology, completing the connection.

A. FortiManager: FortiManager is a centralized management platform, but the core device-to-device trust and authorization for the Security Fabric itself occurs on the root FortiGate.

C. FortiAnalyzer: FortiAnalyzer is a logging and analytics component that joins the fabric as a member; it must be authorized by the root FortiGate, it does not authorize other devices.

D. Downstream FortiGate: A downstream FortiGate is a subordinate member of the fabric. It is the device that requires authorization from the root, not the one that grants it.

1. Fortinet FortiOS 7.0.0 Administration Guide:

Section: "Building the Security Fabric" > "Adding a downstream FortiGate"

Page 100: "On the upstream FortiGate

go to Security Fabric > Fabric Connectors. A notification banner is displayed

indicating that a device is waiting for authorization... Select the FortiGate and click Authorize." This explicitly states that authorization is performed on the upstream (root) FortiGate.

2. Fortinet FortiOS 7.2.0 Administration Guide:

Section: "Security Fabric" > "Security Fabric settings"

Page 101: "When a device is configured to join the Security Fabric

the root FortiGate receives a request to authorize the device. The administrator must authorize the device from the root FortiGate to allow it to join the Security Fabric." This confirms the root FortiGate is the point of authorization.

3. Fortinet NSE 4 - FortiOS 7.2 Study Guide:

Module: "Security Fabric"

Page 10: "After you configure a FortiGate as a downstream device

you must authorize it on the root FortiGate." This reinforces that the authorization action is a mandatory step performed on the root device.

In the initial FortiOS 7.0 release, the GUI for configuring SD-WAN Performance SLAs (also known as Health Checks) provided a limited set of protocols, including Ping and DNS. The command-line interface (CLI), however, offered a more extensive list of configurable protocols. Among the options in the question, both Two-Way Active Measurement Protocol (TWAMP) and udp-echo were available in the CLI but were absent from the GUI in that release. While udp-echo was later added to the GUI in a subsequent minor version (7.0.1), TWAMP remains a CLI-only configuration option. Therefore, based on the foundational 7.0 version, both are correct.

A. DNS: This protocol has been a standard option available for selection directly within the Performance SLA GUI since the initial FortiOS 7.0 release. C. ping: This is the default and most common protocol for health checks and has always been a primary, visible option in the Performance SLA GUI.

1. Fortinet FortiOS 7.0.0 Administration Guide, Page 900, "SD-WAN > To create a new Performance SLA in the GUI:". Step 6 and the accompanying screenshot list the available GUI protocols as "Ping, HTTP, TCP Echo, or DNS," which notably excludes udp-echo and TWAMP.

2. Fortinet FortiOS 7.0.0 CLI Reference, Page 3198, "config system sdwan > config health-check". The entry for set protocol lists the available options as {ping | tcp-echo | udp-echo | http | https | dns | ftp | twamp}, confirming that both udp-echo and twamp were available in the CLI from the initial 7.0 release.

3. Fortinet FortiOS 7.2.4 Administration Guide, Page 1030, "SD-WAN > Performance SLA". This later guide shows that udp-echo was added to the GUI's protocol list, illustrating the version-specific nature of the question, but TWAMP remains absent from the GUI options.

The most precise and recommended method to resolve this issue without affecting other services is to isolate the configuration change to only the specific traffic flow. This is achieved by creating a new, custom service object specifically for the Telnet traffic that requires a longer session timeout. Then, a new, dedicated firewall policy is created for this specific traffic (SSL VPN users to the Linux server via Telnet) using the new custom service object. By placing this new policy above the existing, more general SSL VPN policy, FortiGate will match the specific Telnet traffic first and apply the longer session timeout, while all other traffic falls through to the original policy with its default settings.

A. Modifying the predefined TELNET service object is a global change that would affect all firewall policies using this service, violating the requirement not to impact other services.

B. Setting the session TTL on the entire SSL VPN policy would apply the longer timeout to all traffic matching that policy (e.g., HTTP, DNS), not just Telnet, which is an unnecessarily broad change.

1. FortiOS 7.0.1 Administration Guide

Page 448 (Firewall policies): "FortiGate matches traffic to the first policy in the list that meets the criteria. Once a match is found

no other policies are checked. For this reason

you should place more specific policies at the top of the policy list." This supports the strategy in option D of creating a more specific policy and placing it first.

2. FortiOS 7.0.0 CLI Reference

Page 1018 (config firewall service custom): This section details the commands for creating a custom firewall service. Within this configuration context

the set session-ttl command is available. This confirms that a custom service object can be created with a specific session TTL

as described in option C.

3. Fortinet Cookbook (KB)

"Changing the session TTL" (FD30062): This document explains the different methods for modifying session TTL. It states

"The session TTL value can be configured globally

per VDOM

in a firewall policy

or in a firewall service." It implicitly supports the best practice of using the most granular method (a custom service within a specific policy) to avoid unintended consequences on other traffic.

The hard-timeout is an absolute session timer configured on a user group. This timer begins as soon as a user successfully authenticates. Once the configured time elapses, FortiGate terminates the user's session and requires them to re-authenticate, regardless of whether the user was active or idle during the session. This behavior directly matches the administrator's requirement for a fixed-duration session that is independent of user activity.

A. auth-on-demand is a user group setting that triggers authentication only when a user initiates a new session, rather than being a session timeout mechanism. B. soft-timeout is not a standard or valid timeout configuration option for user groups within FortiOS. C. idle-timeout disconnects a user only after a specific period of inactivity. The timer resets each time the user generates traffic, which contradicts the requirement. D. new-session is not a timeout setting. It is a parameter that controls how to handle new sessions from an already authenticated user's IP address.

1. FortiOS 7.0.0 Administration Guide, Page 1013, "User Groups" section: "Hard timeout: Enter the number of minutes before the user must re-authenticate. This is an absolute timeout that is not affected by user activity. The range is 0 to 10080 minutes (seven days). The default is 0, which means no hard timeout."

2. FortiOS CLI Reference 7.0.0, Page 2618, config user group command: set hard-timeout - "Set hard timeout in minutes (0 - 10080)." This confirms it as the absolute timeout setting. In contrast, set idle-timeout is described as the inactivity timer.

By default, a FortiGate device configures both the SSL VPN portal and the administrative management GUI to listen on the same TCP port, which is 443 for HTTPS. The FortiGate appliance differentiates between administrative access and SSL VPN user access based on the URL path requested by the client's browser. This shared port configuration simplifies firewall policy creation and external access setup, as only a single port needs to be opened for both services on the external-facing interface.

A. By default, FortiGate does not use WINS servers for name resolution for SSL VPN clients. It uses the DNS servers configured in the FortiGate's system settings.

B. Requiring a client certificate for SSL VPN authentication is a security enhancement that is disabled by default. The default authentication method relies on user credentials.

C. By default, split tunneling is disabled for the full-access portal. This ensures all traffic from the remote client is routed through the FortiGate for complete security inspection.

1. Fortinet FortiOS 7.4 Administration Guide

SSL VPN

Section: SSL VPN settings.

"By default

the SSL VPN daemon runs on port 443. This may conflict with administrative access to the FortiGate on the same port. It is recommended to change the port to 10443 or 4433

or change the administrative access port." This statement confirms that by default

both services use port 443.

2. Fortinet FortiOS 7.4 CLI Reference

vpn ssl settings.

The documentation for the config vpn ssl settings command shows the default value for port is 443 and the default for client-cert is disable.

3. Fortinet FortiOS 7.4 SSL VPN Guide

Portals

Section: Configuring a portal.

The guide details the configuration of SSL VPN portals. The default full-access portal has split-tunneling disabled. The CLI default for set split-tunneling within a portal configuration is disable.

The provided configuration set av-failopen pass explicitly instructs the FortiGate to allow traffic to pass without inspection if the antivirus scanning daemon (scand) fails. The debug output for scand confirms two key points: the scand daemon state is stopped, and the av-failopen mode is pass. Therefore, any new session that matches a firewall policy requiring antivirus inspection will be allowed to proceed without being scanned. While the IPS engine is also down and would block traffic, option A accurately describes the direct consequence of the specific, non-default configuration provided in the exhibit.

B. It is allowed and inspected as long as the inspection is flow based: This is incorrect because the relevant inspection daemons (scand, ipsmonitor) are stopped, meaning no inspection of any kind can occur.

C. It is dropped: This is not universally true. While traffic requiring IPS inspection would be dropped, traffic requiring only antivirus inspection is explicitly allowed due to the av-failopen pass setting.

D. It is allowed and inspected, as long as the only inspection required is antivirus: This is incorrect because the traffic is allowed but it is not inspected. The purpose of the fail-open mechanism is to bypass inspection when the service is unavailable.

1. FortiOS Administration Guide 7.4.1

Page 1018

"Fail-open behavior": "By default

when a daemon fails

traffic that is supposed to be processed by that daemon is blocked. This is fail-close behavior. You can configure fail-open behavior to allow traffic to pass through without being processed when the daemon fails." This document confirms the principle of fail-open.

2. FortiOS CLI Reference 7.4.1

Page 103

config system global: The set av-failopen pass command is documented here. It enables traffic to pass when the AV service is unavailable

which is the scenario shown in the debug output.

3. FortiOS Handbook - Security Profiles for FortiOS 7.4.0

Page 21

"Fail-open configuration": "You can configure fail-open to allow traffic to pass through the FortiGate unit without being scanned if the IPS or antivirus scanner fails." This directly supports that av-failopen pass allows traffic when the antivirus scanner has failed.

In FortiOS, an administrator's access rights and permissions are defined by their assigned Administrator Profile. To access and modify global settings, which affect the entire FortiGate device, an administrator account must be associated with a profile that has global access permissions. The default superadmin profile provides this level of access. If an administrator cannot see the global settings, their current profile is likely restricted to a specific Virtual Domain (VDOM). Therefore, changing the account's assigned profile to one with global permissions (like superadmin) is the necessary action.

A. This feature restricts login access to specific IP addresses for security but does not grant permissions to view or edit global settings. B. Changing the password only alters the authentication credential; it does not modify the account's authorization level or configuration permissions. C. This enhances login security by requiring a second factor for authentication but does not change the permissions assigned to the administrator profile.

1. FortiOS 7.4.0 Administration Guide, System > Administrators > Admin profiles, Page 481: "Admin profiles are used to grant administrators permissions to access and configure the FortiGate... The default superadmin profile has full permission to the FortiGate, including all VDOMs and global settings. The default profadmin profile has full permission to the VDOMs it is assigned to, but no access to global settings." This directly confirms that the profile dictates access to global settings.

2. FortiOS 7.4.0 Administration Guide, System > Administrators > Administrators, Page 478: "When creating a new administrator, you must assign them an admin profile... The profile determines what the administrator can see and do in the GUI and CLI after they log in." This reinforces that all permissions are tied to the profile.

Performance SLA (Service Level Agreement) in FortiGate SD-WAN is used to monitor the performance of member interfaces based on defined targets for latency, jitter, and packet loss.

An SD-WAN rule configured with the Best Quality strategy must reference a Performance SLA. This strategy relies on the SLA targets to compare the quality of available links and select the one that best meets the criteria. Therefore, SLA targets are a mandatory component for this specific rule strategy.

Furthermore, while Performance SLAs actively measure link quality once configured, these measurements only influence traffic routing decisions when an SD-WAN rule explicitly references that SLA. Without being linked to a rule, the SLA performs its measurements, but no traffic steering action is taken based on the results.

A. You can configure multiple SLA targets (latency, jitter, packet loss) within a single Performance SLA, and you can create many Performance SLAs. There is no limit of two.

B. This statement is too general. While you can configure SD-WAN without using Performance SLAs (e.g., with a manual strategy), they are mandatory for certain strategies like Best Quality.

1. Fortinet FortiOS 7.0 SD-WAN Administration Guide

Page 23

"SD-WAN rules":

"The Best Quality strategy selects a link based on the link quality

which is measured by a performance SLA. You must select a performance SLA in the Interface preference field." This directly supports option C.

2. Fortinet FortiOS 7.0 SD-WAN Administration Guide

Page 18

"Performance SLA":

"Performance SLAs

also known as health checks

are used to monitor the health and performance of SD-WAN members that are used to route traffic. SD-WAN rules use the results from performance SLAs to route traffic to the best link to maintain performance for business-critical applications." This supports option D

as the use of the SLA results for routing is tied to the SD-WAN rules.

3. Fortinet FortiOS 7.0 SD-WAN Administration Guide

Page 20

"Configuring the performance SLA":

The configuration steps show that within one Performance SLA

you can set thresholds for Latency

Jitter

and Packet Loss. This refutes the arbitrary limit of two targets mentioned in option A.

The FortiGate Web Application Firewall (WAF) is the security feature specifically designed to protect web servers from application-layer attacks. It inspects HTTP and HTTPS traffic for threats targeting web applications, such as SQL injections, cross-site scripting (XSS), and other OWASP Top 10 vulnerabilities. By applying signatures and constraints to web traffic destined for internal servers, the WAF can identify and block malicious requests before they reach the application.

A. Denial of Service: This feature protects against traffic floods and resource exhaustion attacks, not application-layer code injection attacks like SQL injection.

C. Antivirus: This scans files for known malware signatures. It is not designed to analyze and block malicious code embedded within web application requests.

D. Application control: This feature identifies and manages the use of specific applications on the network but does not inspect the content of allowed traffic for attacks.

1. Fortinet FortiOS 7.0.0 Administration Guide

Security Profiles > Web Application Firewall

Page 1218: "The FortiGate web application firewall (WAF) feature examines HTTP and HTTPS traffic for web-based attacks

such as SQL injection and cross-site scripting."

2. Fortinet Cookbook

WAF profile for common web vulnerabilities (5.6)

Document Version 1.0: "A WAF profile can be used to protect your web servers from sophisticated attacks

such as... SQL injection

Cross-site scripting

[and] Generic attacks."

3. Fortinet Product Matrix

FortiGate-FortiWiFi 70F Series Datasheet

Page 2: The datasheet lists "Web Application Firewall" as a core security service provided by the FortiGate platform to protect against web application attacks.

The root FortiGate in a Security Fabric acts as the central management and orchestration point. Two key functions exclusive to the root device are direct administrative control over fabric members and centralized threat response. From the Security Fabric topology on the root FortiGate, an administrator can reboot or shut down a downstream FortiGate. Furthermore, the root FortiGate is responsible for managing the fabric-wide compromised host list, allowing an administrator to ban or unban an IP address across the entire Security Fabric. This centralized command and control is a core aspect of the root FortiGate's role.

B. Disabling FortiAnalyzer logging is a local configuration on the downstream device itself. You can log in to the downstream FortiGate to change this setting.

C. A FortiSwitch is managed by the FortiGate it is directly connected to via FortiLink. This managing FortiGate could be a downstream device, not necessarily the root.

1. FortiOS Administration Guide 7.0.0

Page 1011

"Security Fabric topology": "From the root FortiGate

you can right-click a device in the topology to perform actions

such as logging in to the device

upgrading the firmware

or rebooting the device." This directly supports option A.

2. FortiOS Administration Guide 7.0.0

Page 1043

"Banning an IP address": "When a compromised host is detected

the FortiGate can ban the host's IP address from accessing the network. In the Security Fabric

the root FortiGate shares the banned IP address with the other FortiGates in the Security Fabric." This confirms that managing the banned IP list is a root FortiGate function

supporting option D.

3. FortiOS Administration Guide 7.0.0

Page 833

"Log Settings": This section details that log settings are configured on a per-device basis under the Log & Report menu

demonstrating that this is not an action exclusive to the root FortiGate. This refutes option B.

4. FortiOS Administration Guide 7.0.0

Page 487

"FortiSwitch Manager": The documentation explains that FortiSwitch devices are managed from the FortiGate they are connected to. This management is not exclusive to the root FortiGate in a multi-FortiGate fabric. This refutes option C.

FortiGate, like other systems implementing Public Key Infrastructure (PKI), builds and validates certificate chains by linking a certificate to its issuer. This is primarily achieved using the Authority Key Identifier (AKI) and Subject Key Identifier (SKI) extensions. The AKI extension within a signed certificate contains a value that matches the SKI value of the issuing Certificate Authority's (CA) certificate. This direct correspondence allows FortiGate to unambiguously identify the specific issuer certificate and key used for signing, which is essential for constructing the correct chain of trust.

B. S/MIME Capabilities value: This extension is specific to the S/MIME standard and describes the cryptographic capabilities of an email client, not the issuer-subject relationship in a certificate chain.

C. Subject value: The Subject field identifies the entity to whom the certificate is issued. While the Issuer field of this certificate must match the Subject field of the CA's certificate, the SKI provides a more precise link to the specific key used.

D. Subject Alternative Name value: This extension lists additional identities (like hostnames or IP addresses) for the certificate's subject, but it does not provide any information about the certificate's issuer.

1. Fortinet FortiOS 7.0.1 Handbook - Public Key Infrastructure: In the "Certificate verification" section

it states

"The Authority Key Identifier (AKI) extension in a certificate points to the Subject Key Identifier (SKI) of the certificate that signed it. This allows the FortiGate to build the certificate chain of trust." (p. 21).

2. IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile:

Section 4.2.1.1

"Authority Key Identifier

" explains that this extension identifies the public key used to sign a certificate

typically by referencing the issuer's Subject Key Identifier.

Section 4.2.1.2

"Subject Key Identifier

" defines this extension as a means of identifying certificates that contain a particular public key

which is then referenced by the AKI of certificates it issues.

FortiGate is a stateful firewall that establishes a session for new connections. A route lookup is performed on the first packet from the session originator to determine the egress interface and next-hop gateway for the forward path. This information is then stored in a new session table entry. Subsequently, when the first reply packet is received from the responder, a second route lookup is performed for the original source IP address (which is the destination for the reply packet). This confirms the return path and fully populates the session table. All subsequent packets for that session are processed quickly using the established session information, without requiring additional route lookups.

B. A route lookup is not performed on the last packet; forwarding is based on the already established session table entry.

C. This describes stateless behavior. FortiGate is stateful and uses a session table to avoid resource-intensive lookups for every packet.

1. Fortinet. (2024). FortiGate / FortiOS 7.0.12 / Administration Guide. Fortinet Document Library. In the "Firewall" chapter

section "Life of a packet"

the "New session" subsection states: "The FortiGate then does a route lookup to determine the egress interface that it can use to forward the packet to its destination." This directly supports the lookup on the first packet from the originator.

2. Fortinet. (2021). FortiOS Handbook - Firewall for FortiOS 7.0.0. Fortinet Document Library. On page 10

under "Packet flow and session management"

the text confirms the process for the initial packet: "When the first packet of a new session arrives...the FortiGate performs a route lookup for the destination address to find the egress interface."

3. The route lookup on the first reply packet is a fundamental aspect of establishing the bidirectional session state. The FortiGate must determine the return path to the originator. This principle is a core component of the official Fortinet Certified Professional (FCP) curriculum

which explains that the session table stores information for both directions of traffic

and this information is populated by lookups on the initial and reply packets.

The antivirus profile successfully blocks the EICAR test file over unencrypted HTTP, which confirms that the antivirus engine and its definitions are functioning correctly. The failure to detect the virus when downloaded over encrypted HTTPS indicates that the FortiGate is not decrypting the traffic to inspect its content. For FortiGate to apply security profiles like Antivirus to encrypted traffic, the SSL/SSH Inspection profile must be configured for 'deep-inspection'. The described behavior suggests the profile is either not applied or is incorrectly set to 'certificate-inspection', which only examines the server certificate but does not decrypt and inspect the traffic payload.

A. Application control is not enabled: Application control is used to identify and manage applications; it is not the primary feature responsible for decrypting and scanning encrypted content for viruses.

C. Antivirus profile configuration is incorrect: The antivirus profile is proven to be working correctly because it successfully blocks the EICAR file over HTTP.

D. Antivirus definitions are not up to date: The antivirus definitions are effective, as demonstrated by the successful detection and blocking of the EICAR file in the unencrypted HTTP download.

---

1. Fortinet FortiOS 7.0.0 Administration Guide

Security Profiles > SSL/SSH Inspection

Page 1138.

The guide states: "Deep inspection... allows FortiGate to inspect the content of secure traffic... This allows FortiGate to enforce security features such as... Antivirus

Web Filtering

and DLP." This confirms that deep inspection is required for the antivirus profile to function on HTTPS traffic.

2. Fortinet FortiOS 7.0.0 Security Profiles Guide

SSL/SSH Inspection

Page 10.

This document explicitly differentiates the inspection modes: "Certificate Inspection... The content of the packet is not inspected... Deep Inspection... The content of the packet is inspected by FortiGuard and other security profiles." This directly supports the conclusion that the failure to inspect content is due to the SSL/SSH inspection mode.

The FortiOS Intrusion Prevention System (IPS) engine is a core component that performs pattern matching and protocol decoding for multiple security functions, especially in flow-based inspection mode. Application control is fundamentally built on the IPS engine, using its decoders and signature-matching capabilities to identify application traffic. Similarly, when operating in flow-based mode, both the web filter and antivirus features leverage the high-performance IPS engine to scan traffic content for threats and policy violations without the need for full proxying, enabling faster throughput.

C. DNS filter: This feature is primarily handled by a dedicated daemon (dnsfilterd) and process, which is distinct from the core IPS engine used for general signature matching.

D. Web application firewall: The WAF feature on a FortiGate uses its own specialized engine for deep inspection of HTTP/S traffic and protection against web application attacks, separate from the IPS engine.

1. Fortinet FortiOS 7.0.0 Administration Guide: In the "Security Profiles" section

under "Application Control

" it is stated that "Application control uses IPS protocol decoders and signatures to identify the applications that generate network traffic." (p. 689).

2. Fortinet FortiOS 7.0.0 Handbook - Architecture: The "Life of a Packet" chapter details the packet flow. In the flow-based inspection path

the diagram and accompanying text show that the ipsengine is responsible for processing IPS

Application Control

flow-based Web Filtering

and flow-based Antivirus. (Section: "Flow-based inspection").

3. Fortinet FortiOS 7.0.0 Handbook - Security Profiles: The "Antivirus" chapter explains

"In flow-based inspection

the FortiGate uses the IPS engine to scan content as it passes through the FortiGate without any buffering." This same principle is described for flow-based Web Filtering. (Section: "Inspection modes").

When a FortiGate is configured in transparent mode, it functions as a Layer 2 bridge or switch. By default, all physical interfaces are placed into a single virtual switch, effectively making them part of the same broadcast domain. In this mode, the FortiGate inspects and forwards Ethernet frames based on their destination MAC address. It does not modify the source or destination MAC addresses of the original frames as they pass through, making its presence on the network "transparent" to other devices. This allows the FortiGate to be inserted into an existing network without requiring any changes to the IP addressing scheme.

B. The primary advantage of transparent mode is that it can be deployed without altering the existing network's IP address schema, making this statement false.

C. Transparent mode operates at Layer 2, forwarding frames based on a MAC address table. Static routes, a Layer 3 concept, are not required for traffic forwarding through the device.

1. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "In Transparent mode

the FortiGate is installed between the internal network and the router. In this mode

the FortiGate acts as a transparent bridge

forwarding frames without modifying the MAC addresses." This directly supports option D.

2. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "When you install a FortiGate in Transparent mode

you do not have to change the IP addresses of the computers on the private network." This directly refutes option B.

3. FortiOS Administration Guide 7.0.0

System > Operation Mode > Example: Transparent mode

Page 220: "When you change the operating mode to Transparent

the FortiGate configuration is reset and the FortiGate restarts. All physical interfaces are now part of the default virtual switch

root." This supports option A

as a virtual switch groups interfaces into a single broadcast domain.

4. FortiOS Administration Guide 7.0.0

System > Operation Mode > Transparent mode

Page 218: "The FortiGate unit functions like a bridge

and traffic is not routed." This refutes the premise of option C

which implies Layer 3 routing is the primary forwarding mechanism.

In FortiOS, the Internet Service Database (ISDB) objects are treated as a special category within firewall policies. Due to their dynamic nature and complex definitions (which can include multiple IP addresses, ports, and protocols), they cannot be combined with other object types like IP addresses, FQDNs, or user groups within the same source or destination field. When an Internet Service is selected, the policy matching engine is dedicated to that specific object type for that field, and the GUI/CLI prevents the addition of any other objects to maintain policy integrity and avoid matching conflicts.

A. IP address: An IP address object is a standard address type and cannot be added to the source field once an Internet Service object has been selected. C. User or User Group: User and User Group objects are used for identity-based policies and cannot be mixed with Internet Service objects in the source field. D. FQDN address: An FQDN address object is another type of standard address object and is not permitted in the source field alongside an Internet Service object.

1. Fortinet FortiOS 7.4.0 Administration Guide: In the section describing firewall policy components, it explicitly states the limitation. "When an Internet Service is selected as the source or destination in a firewall policy, other types of addresses cannot be added." (See FortiOS Administration Guide 7.4.0, Page 818, "Firewall policies > Internet Service").

2. Fortinet FortiOS 7.2.0 Administration Guide: This behavior is consistent across versions. The guide notes, "When an Internet Service is selected as the source or destination in a firewall policy, other types of addresses cannot be added." (See FortiOS Administration Guide 7.2.0, Page 778, "Firewall policies > Internet Service").

3. Fortinet Cookbook: In a recipe detailing the use of the Internet Service Database, the configuration steps and notes reinforce this rule. "Note that you cannot add any other addresses to the policy when using an Internet Service." (See Fortinet Cookbook, "Internet Service Database (ISDB)", Version 7.4.0, Configuration section).

The FortiGate sniffer command diagnose sniffer packet any '...' 4 0 l uses verbosity level 4. According to the FortiOS Command Line Interface (CLI) Reference, verbosity level 4 is defined to "print header of packets with interface name."

The exhibit's output confirms this:

1. Interface name (A): The line begins with port1 out, explicitly showing the interface.

2. IP header (C): The summary line 10.0.1.254 -> 10.0.1.10 icmp: echo request contains information parsed from the IP and ICMP headers.

3. Ethernet header (B): The hexadecimal dump below the summary line displays the raw packet data, which starts with the Layer 2 Ethernet header (containing source and destination MAC addresses).

Therefore, all three are present in the output.

D. Application header: The sniffer does not parse or explicitly display application (Layer 7) headers in this mode. The protocol shown, ICMP, operates at the network layer.

E. Packet payload: Verbosity level 4 is specified to show only packet headers. While the payload is present within the raw hexadecimal dump, levels designed to show payload data (e.g., 2, 5, 6) also include an ASCII representation, which is absent here.

1. Fortinet FortiOS 7.4.0 CLI Reference: In the diagnose sniffer packet command documentation

the description for verbosity level 4 is "print header of packets with interface name." This supports that the primary information displayed includes headers and the interface name. (FortiOS 7.4.0 CLI Reference

p. 1985).

2. FortiGate Infrastructure 7.4 Study Guide: The troubleshooting chapter explains packet sniffing. It clarifies the verbosity levels

stating that level 4 adds the interface name to the header information provided by level 1. The guide distinguishes header-only levels (1

4) from levels that also display data/payload (2

3

5

6). (FortiGate Infrastructure 7.4 Study Guide

"Troubleshooting" chapter

section "Packet Sniffer").

3. Fortinet Document Library: The technical article "Troubleshooting Tip: Using the FortiOS built-in packet sniffer" details the output for each verbosity level. It shows that the hex dump is included in level 4

but the descriptive text emphasizes that its purpose is to display headers

contrasting with levels that are meant to display "header and data". (Document ID: FD33742).

In an IPsec VPN, the Internet Key Exchange (IKE) protocol establishes Security Associations (SAs). The Phase 1 SA (IKE SA) is a single, bidirectional channel created to authenticate the peers and secure the negotiation of the Phase 2 SAs. The Phase 2 SAs (IPsec SAs) are unidirectional and are used to apply security services, such as encryption and authentication via ESP or AH, to the actual data traffic flowing through the tunnel. To ensure security, Phase 2 SAs have a finite lifetime, which can be configured to expire based on a set time duration, a specific volume of processed data, or whichever of these two limits is reached first.

B. An SA never expires.

This is incorrect. All SAs have a defined lifetime (time or volume-based) to force re-keying, which is a critical security practice to limit the impact of a compromised key.

E. Both the phase 1 SA and phase 2 SA are bidirectional.

This is incorrect. The Phase 1 (IKE) SA is bidirectional, but the Phase 2 (IPsec) SAs are unidirectional. Two Phase 2 SAs are required for bidirectional data communication.

1. Fortinet FortiOS 7.0 Administration Guide:

In the "IPsec VPN concepts > IKE and IPsec > Phase 1 and Phase 2" section

it states: "The IKE SA is a bidirectional secure channel... The purpose of IKE phase 2 is to negotiate IPsec SAs to set up the IPsec tunnel. The IPsec SAs are unidirectional... The IPsec SAs handle the encryption and decryption of traffic in the IPsec tunnel." This supports options A and C.

In the "IPsec VPN concepts > IKE and IPsec > Phase 2 settings" section

it details lifetime settings: "You can define the SA lifetime in seconds

in kilobytes of data processed

or both. The SA expires when one of these values is reached." This supports option D and refutes B.

2. RFC 4301

Security Architecture for the Internet Protocol:

Section 4.1

"Security Associations": "An SA is unidirectional. That is

it is a security relationship that applies to traffic in one direction... For peer-to-peer communication

two SAs are required

one in each direction." This confirms the unidirectional nature of IPsec (Phase 2) SAs

supporting option C and refuting E.

3. RFC 7296

Internet Key Exchange Protocol Version 2 (IKEv2):

Section 1.2

"The IKESA": "An IKESA is a bidirectional entity that is created as the result of an IKESAINIT exchange... All IKE messages are protected by an IKESA." This confirms the bidirectional nature of the IKE (Phase 1) SA

supporting option C.

According to the FortiOS packet processing order, also known as the "Life of a Packet," Denial of Service (DoS) policy checks are performed at the very beginning of the packet flow. This happens immediately after the packet is received on the ingress interface and before a session is created. Intrusion Prevention System (IPS) scanning, which evaluates signatures and filters, occurs much later in the process, after a firewall policy has accepted the traffic and a session has been established. Therefore, the ipsrcsession anomaly defined in the DoS policy is the first item to be evaluated by FortiGate.

A. SMTP.Login.Brute.Force: This is an IPS signature, which is evaluated by the IPS engine after the DoS policy check and session establishment. B. IMAP.Login.brute.Force: This is an IPS signature, which is processed later in the packet flow by the IPS engine, not before the DoS policy. D. Location: server Protocol: SMTP: This is an IPS filter used to apply specific signatures. It is part of the IPS engine's logic, which runs after the DoS policy.

1. Fortinet FortiOS 7.4.0 Administration Guide, Packet flow and security profiles > Life of a packet, Page 1031. The packet flow diagram and description clearly show that the dos-policy check occurs at the ingress stage, well before session setup and the application of security profiles like IPS (ipsscan).

2. Fortinet FortiOS 7.4.0 Administration Guide, Security Profiles > DoS Protection, Page 568. This section explains that DoS policies are designed to "protect the FortiGate unit from denial of service attacks" by inspecting traffic before it is processed by the CPU, confirming its early position in the packet flow.

When a FortiGate unit is set to split VDOM mode, the system automatically partitions its resources into two predefined Virtual Domains (VDOMs). The root VDOM is created specifically for management purposes, isolating administrative traffic and typically containing only the dedicated management interfaces. Concurrently, a second VDOM named FG-traffic is created to handle all data plane traffic, and all non-management interfaces are moved into this VDOM. This architecture enhances security by separating network management from general network traffic.

B. Mgmt: This is not a default VDOM name. The management VDOM is named root by default in split VDOM mode.

C. FG-Mgmt: This is not a default VDOM name created by FortiGate in split VDOM mode.

1. Fortinet. (2023). FortiOS Administration Guide 7.4.0. Fortinet Document Library. In the "System > VDOMs > Split VDOM mode" section

it states

"When split VDOM mode is enabled

two VDOMs are created: root and FG-traffic. The root VDOM is the management VDOM and contains only the management interfaces. All remaining interfaces are in the FG-traffic VDOM."

2. Fortinet. (2022). FortiGate Infrastructure 7.2 Study Guide. Fortinet Training Institute. Page 318

under the "Split VDOM Mode" heading

specifies

"When split VDOM mode is enabled

two VDOMs are created: root and FG-traffic."