74 of 149 questions · Page 2/2 · Nse4 System Network topic · Answers revealed
Drag and drop the steps to troubleshoot a user unable to access the internet through FortiGate into the correct order.
Drag or tap steps into the slots.
Why this order
Troubleshooting follows a logical flow: policy, NAT, routing, packet capture, then logs.
A network administrator needs to configure a FortiGate to allow HTTPS access to the GUI from the internal network. Which two steps must be performed?
FortiGate evaluates interface-to-interface traffic against firewall policies, so a policy permitting HTTPS from the internal subnet to the FortiGate interface IP is required for GUI access. This satisfies the stem's constraint alongside enabling HTTPS administrative access.
Why this answer
To allow HTTPS access to the GUI from the internal network, two actions are required. First, a firewall policy must be created to permit HTTPS traffic (TCP/443) from the internal network to the FortiGate's interface IP. This can be done via CLI with 'config firewall policy' or through the GUI.
Second, HTTPS administrative access must be enabled on the internal interface. This is configured either via CLI with 'config system interface' and 'set allowaccess https' or by checking 'HTTPS' under Administrative Access in the GUI. Without both steps, GUI access will fail.
How to eliminate wrong answers
Option C is wrong because disabling HTTP administrative access is not a required step for allowing HTTPS GUI access; it is an optional security hardening step. Option D is wrong because SSH administrative access is used for CLI management, not GUI access, and enabling it does not affect HTTPS GUI connectivity.
A FortiGate administrator needs to configure a static route to reach a remote network 192.168.100.0/24 via next-hop 10.0.0.1. Which CLI command should be used?
This is the exact FortiOS syntax for a static route. 'config router static' enters the static routing table, 'edit 1' creates or edits the route with sequence number 1, and 'set dst' accepts the destination address followed by subnet mask. 'set gateway' defines the next-hop IP, then 'next' commits the entry and 'end' exits configuration mode. This block is valid and works as intended.
Why this answer
It uses the proper FortiGate CLI syntax for configuring a static route. The command 'config router static' enters the static route configuration context, and 'set dst' specifies the destination network with a subnet mask (not CIDR notation), while 'set gateway' defines the next-hop IP address. This matches the FortiGate CLI structure for static routes.
Exam trap
The trap here is that candidates familiar with Cisco IOS may use 'set destination' or 'set next-hop' (similar to Cisco's 'ip route' command) or CIDR notation, but FortiGate requires 'set dst' with a subnet mask and 'set gateway' for the next-hop, testing knowledge of vendor-specific CLI syntax.
How to eliminate wrong answers
Option A is wrong because 'config network route' is not a valid FortiGate CLI command; FortiGate uses 'config router static' for static route configuration. Option C is wrong because 'config route static' is incorrect syntax; the correct command is 'config router static', and 'set destination' and 'set next-hop' are not valid parameters (FortiGate uses 'set dst' and 'set gateway'). Option D is wrong because while it uses the correct 'config router static' command, it incorrectly uses CIDR notation '192.168.100.0/24' with 'set dst'; FortiGate requires a subnet mask in dotted decimal format (e.g., 255.255.255.0) for the destination.
A FortiGate has two internet connections: port1 (ISP1) and port2 (ISP2). An administrator configures two static default routes with equal distance and priority. Traffic to a specific public IP is observed going out port1, but the admin wants it to go out port2. What should be configured?
A policy route is evaluated before the routing table, so matching the specific destination and setting the output interface to port2 overrides the default route for only that traffic. You can specify source, destination, and optionally protocol or port criteria, while all other traffic continues to follow the normal administrative-distance-selected default route. This gives exact policy-based control without affecting other destinations.
Why this answer
Policy routes (also called PBR) override the routing table for specific traffic matches. Since both default routes have equal distance and priority, the FortiGate uses ECMP or the route with the lowest cost by default. A policy route can match the specific destination IP and force the traffic out port2, bypassing the routing table lookup.
Exam trap
The trap here is that candidates assume ECMP or route metrics can selectively steer a single destination, but policy routing is the only method that overrides the routing table for specific traffic without affecting other flows.
How to eliminate wrong answers
Option A is wrong because ECMP with source-based hashing distributes traffic across multiple paths based on source IP, not destination; it would not force a specific destination to a single egress. Option C is wrong because increasing the administrative distance of the default route on port1 would make it less preferred for all traffic, not just the specific destination, breaking load balancing. Option D is wrong because a blackhole route discards traffic matching the destination, preventing it from reaching the public IP entirely.
A FortiGate administrator needs to allow SSH management access from a specific IP address 10.0.0.100. Which configuration is required?
Setting the trusted host for the admin account to 10.0.0.100 is the correct method because FortiGate's trusted-host feature restricts administrative logins to traffic originating from that exact source IP address. When configured, the SSH management daemon will reject authentication attempts from any other IP, regardless of which interfaces have SSH enabled. This provides a precise, per-admin source-IP allowlist that directly matches the requirement to permit only one specific management host.
Why this answer
FortiGate uses the 'trusted host' feature to restrict administrative access to specific source IP addresses. By setting the trusted host to 10.0.0.100 for the admin account, only that IP can initiate SSH sessions to the FortiGate management interface, regardless of which interface SSH is enabled on.
Exam trap
The trap here is that candidates often confuse firewall policies (which control transit traffic) with administrative access controls (which control traffic destined to the FortiGate itself), leading them to incorrectly select option D.
How to eliminate wrong answers
Option A is wrong because enabling SSH on the WAN interface and allowing all IPs would permit SSH access from any source, violating the requirement to restrict access to 10.0.0.100 only. Option C is wrong because configuring an access list on the upstream router is an external network control and does not enforce FortiGate's own administrative access restrictions; the FortiGate itself must be configured to limit management access. Option D is wrong because firewall policies control traffic passing through the FortiGate, not traffic destined to the FortiGate itself; management access is governed by administrative access settings and trusted hosts, not by firewall policies.
Which FortiGate operating mode allows the device to act as a transparent layer 2 bridge, forwarding traffic without performing NAT or routing?
Transparent mode places the FortiGate as a layer 2 bridge, forwarding frames between interfaces without routing or NAT, so existing IP addressing remains unchanged. NAT/route mode performs routing and address translation, which the scenario explicitly excludes.
Why this answer
Transparent mode is the correct answer because in this mode, FortiGate operates as a Layer 2 bridge, forwarding traffic based on MAC addresses without performing Network Address Translation (NAT) or routing. The device does not have an IP address on its interfaces for forwarding decisions, making it invisible to the network at Layer 3.
Exam trap
The trap here is that candidates often confuse 'transparent mode' with 'VDOM mode' because VDOMs can be configured in transparent mode, but VDOM mode itself is a virtualization feature, not the operating mode that defines Layer 2 bridging behavior.
How to eliminate wrong answers
Option B (HA mode) is wrong because High Availability mode is a clustering configuration for redundancy and failover, not an operating mode that changes the device's Layer 2 or Layer 3 forwarding behavior. Option C (VDOM mode) is wrong because Virtual Domain mode is a virtualization feature that allows partitioning a single FortiGate into multiple logical firewalls, each operating in its own mode (transparent or NAT/route), but it does not inherently make the device a transparent bridge. Option D (NAT/Route mode) is wrong because this is the default Layer 3 operating mode where the FortiGate performs routing and NAT, acting as a router with IP addresses on interfaces, which is the opposite of transparent bridging.
You notice that the FortiGate HA cluster is not failing over when the primary unit loses power. The HA configuration shows 'set ha-priority 250' on the primary and 'set ha-priority 200' on the secondary. What is the most likely cause?
The HA heartbeat interface is the dedicated link used by both units to exchange state and health information. If this interface is not configured correctly or is down, the secondary cannot reliably monitor the primary's heartbeat; in this scenario, the cluster may not even form, or if it did form, the secondary will not detect the primary's failure and will not initiate a failover. In some cases, a failed heartbeat with a still-functioning management plane can lead to split-brain, but a correctly working heartbeat is fundamental to failover detection and to avoid the cluster being stuck with an inactive primary.
Why this answer
The most likely cause is that the HA heartbeat interface is not configured correctly or is down (Option D). FortiGate HA relies on heartbeat packets exchanged over dedicated or VLAN interfaces to monitor peer status. If the heartbeat interface fails, the secondary unit cannot detect the primary's loss of power, so no failover occurs regardless of priority settings.
The HA priority values (250 vs. 200) are valid and would normally cause the primary to be elected as the active unit, but a broken heartbeat link prevents failover detection.
Exam trap
The trap here is that candidates often assume priority values alone determine failover behavior, but FortiGate HA failover requires a working heartbeat link to detect peer failure; without it, even a complete power loss goes unnoticed.
How to eliminate wrong answers
Option A is wrong because the secondary unit's lower priority (200) does not prevent it from taking over; in fact, when the primary fails, the secondary with the next highest priority becomes active. Option B is wrong because an incorrect HA synchronization password would cause configuration sync failures, not a failure to detect a power loss and trigger failover. Option C is wrong because session pickup (or session failover) is a feature for preserving active sessions during failover, not a requirement for the failover itself to occur.
A network administrator has two FortiGate units that need to be configured as an HA cluster. Which TWO of the following are prerequisites for HA formation?
Both units in a FortiGate HA cluster must run the exact same FortiOS firmware version and build. Mismatched versions can cause the HA protocol to behave unpredictably, leading to split-brain scenarios or failed failovers. Fortinet only supports HA when all cluster members share identical firmware, so this is a hard prerequisite before configuring HA.
Why this answer
FortiGate HA clusters require all members to run the exact same FortiOS firmware version to ensure protocol compatibility and configuration synchronization. Mismatched firmware versions can cause cluster instability, failover failures, or split-brain scenarios, as the HA heartbeat protocol relies on consistent state machine behavior across units.
Exam trap
The trap here is that candidates often assume hostnames must match (Option B) because they confuse HA synchronization with general network device clustering, but FortiGate actually overwrites hostnames during sync, making mismatched hostnames irrelevant as a prerequisite.
An administrator is configuring a loopback interface on a FortiGate for management purposes. Which three statements are true about loopback interfaces? (Choose three.)
FortiGate supports the creation of multiple loopback interfaces, each with its own unique IP address and routing table entries. This allows administrators to deploy several logical endpoints for different services—such as OSPF router IDs, BGP update sources, or management gateways—without consuming physical interface resources. The number of loopbacks is not limited by hardware ports, giving flexibility in network design.
Why this answer
FortiGate allows the creation of multiple loopback interfaces (up to 16, depending on the model) for various purposes such as management, routing, or VPN termination. Each loopback interface is a virtual interface that does not depend on any physical port, providing flexibility in network design.
Exam trap
The trap here is that candidates may confuse loopback interfaces with sub-interfaces or VLAN interfaces, incorrectly assuming they support VLAN tagging or require a physical port, when in fact loopback interfaces are purely logical and independent of hardware.
Which command is used to back up the full FortiGate configuration including all settings and objects?
execute backup config is the correct FortiGate CLI command to back up the full configuration. It captures all system, network, and firewall policy settings into a single plain-text file. This command can be run interactively to save to local disk or with parameters like tftp, ftp, or scp for remote transfer. It is the standard, intended method for creating a complete configuration backup.
Why this answer
The 'execute backup config' command is the correct method to back up the full FortiGate configuration, including all settings and objects, to a TFTP or FTP server. This command exports the entire running configuration in a text format that can be restored later. It is the standard CLI command for a complete configuration backup.
Exam trap
The trap here is that candidates may confuse the correct command with similar-sounding but invalid options like 'execute backup full-config' or 'config backup tftp', or assume a 'system' subcommand exists for backups, when FortiGate uses the 'execute' command structure for operational tasks.
How to eliminate wrong answers
Option B is wrong because 'execute backup full-config' is not a valid FortiGate CLI command; the correct syntax uses 'config' not 'full-config'. Option C is wrong because 'config backup tftp' is not a valid command; the correct command uses 'execute backup config tftp' to specify the protocol. Option D is wrong because 'system backup configuration' is not a valid CLI command; FortiGate uses 'execute backup config' for configuration backups, not a 'system' subcommand.
An administrator needs to back up the FortiGate configuration to a TFTP server at 10.0.0.10. Which command should be used?
This is the correct FortiGate CLI command for backing up the configuration to a TFTP server. The command 'execute backup config' specifies the backup operation, 'tftp' selects the protocol, 'mybackup.conf' is the destination filename on the server, and '10.0.0.10' is the server IP. On FortiGate, this initiates a TFTP put from the unit, and it is the exact syntax required to meet the administrator's need.
Why this answer
The correct command to back up a FortiGate configuration to a TFTP server is 'execute backup config tftp <filename> <server-ip>'. This is a standard FortiOS CLI command that uses TFTP (Trivial File Transfer Protocol) to transfer the configuration file to the specified server at 10.0.0.10. Option B matches this syntax exactly.
How to eliminate wrong answers
Option A is wrong because 'tftp -p -l mybackup.conf 10.0.0.10' is a client-side TFTP command used on a Linux/Windows host, not a FortiGate CLI command; FortiGate does not support raw TFTP client commands. Option C is wrong because it specifies 'ftp' instead of 'tftp', which would attempt an FTP transfer, not TFTP, and the server at 10.0.0.10 is a TFTP server, not an FTP server. Option D is wrong because 'copy config tftp://10.0.0.10/mybackup.conf' is not a valid FortiOS CLI command; FortiGate uses 'execute backup' for configuration backups, not a 'copy' command with a URI.
A FortiGate administrator is troubleshooting a high CPU usage issue. The 'get system performance status' command shows that the CPU usage is consistently above 80% with no traffic. Which of the following is the most likely cause?
A stuck process like the IPS engine can enter an infinite loop or deadlock in user space, consuming an entire CPU core even when no traffic is passing through the device. This is a well-known software defect scenario; the process runs continuously, executing instructions without yielding, causing high CPU while traffic counters remain low. Administrators can confirm this with `diag sys top` to identify the process ID, then restart the engine or the FortiGate, and also check for crash logs to identify the underlying bug.
Why this answer
When CPU usage remains high (above 80%) with no traffic, the most likely cause is a process stuck in an infinite loop, such as the IPS engine. This is a known software bug or process hang that consumes CPU cycles even without network traffic, and it can be verified using 'diagnose sys top' to identify the offending process.
Exam trap
The trap here is that candidates often associate high CPU with external attacks or configuration errors, but the key clue 'with no traffic' eliminates those options, pointing instead to an internal process malfunction.
How to eliminate wrong answers
Option A is wrong because an interface in error-disable state would cause link flaps or port shutdown, generating CPU interrupts only when traffic is present, not with no traffic. Option B is wrong because a misconfigured firewall policy causing packet drops would only consume CPU when packets are being processed, not when there is zero traffic. Option C is wrong because a DDoS attack requires incoming traffic to overwhelm the CPU; with no traffic, there is no attack vector to cause high CPU usage.
A network administrator is configuring a FortiGate for the first time and needs to enable administrative access via HTTPS from the internal network. Which configuration step is required?
To manage a FortiGate via HTTPS on a specific interface, you must explicitly enable HTTPS in the interface's administrative access settings. This is done with `config system interface` and `set allowaccess https` (or `set allowaccess ping https ...`), which tells the control plane to accept HTTPS sessions destined to that interface's IP address. Without this setting, even if the interface has a valid IP and the firewall permits HTTP(S) traffic, the FortiGate will drop management connection attempts.
Why this answer
Administrative access to a FortiGate interface is controlled per-interface under the interface configuration. By default, HTTPS access is disabled on all interfaces. To enable administrative HTTPS access from the internal network, you must set the administrative access to HTTPS on the specific internal interface.
This allows the FortiGate to listen for HTTPS management traffic on that interface's IP address.
Exam trap
The trap here is that candidates confuse firewall policies (which control traffic passing through the FortiGate) with local-in policies (which control traffic destined to the FortiGate), leading them to incorrectly select Option C.
How to eliminate wrong answers
Option B is wrong because HTTPS is not enabled globally; it is enabled per-interface under config system interface. The global settings only control the HTTPS port (default 443) and certificate, not the interface-level access. Option C is wrong because firewall policies control traffic passing through the FortiGate, not traffic destined to the FortiGate itself.
Administrative access is governed by the local-in policy, which is implicitly controlled by the interface's administrative access settings. Option D is wrong because a static route is only needed if the management subnet is not directly connected; for the internal network, the FortiGate already has a directly connected route, so no static route is required.
A FortiGate administrator is upgrading firmware from version 6.0 to 7.0. The upgrade path requires multiple steps. Which of the following is the recommended method to ensure a successful upgrade?
Fortinet firmware upgrades must follow the documented sequential path because configuration syntax and daemon behaviour change between major releases; jumping directly from 6.0 to 7.0 risks an unsupported conversion. Stepping through 6.2 and 6.4 lets each release migrate the configuration incrementally, satisfying the multi-step upgrade constraint in the stem.
Why this answer
FortiGate firmware upgrades must follow a specific path to ensure compatibility of the firmware image, configuration database, and bootloader. Skipping intermediate versions (e.g., 6.2 and 6.4) can cause configuration corruption or boot failure because each major version may change the internal data structures or require a specific bootloader version. The official upgrade path from 6.0 to 7.0 is 6.0 → 6.2 → 6.4 → 7.0, as documented in Fortinet's release notes.
Exam trap
The trap here is that candidates may think a direct upgrade is acceptable because they assume firmware is backward-compatible, or they confuse the 'execute update-now' command with an automatic path resolver, when in fact Fortinet requires strict adherence to the documented upgrade path to prevent bootloader and configuration schema mismatches.
How to eliminate wrong answers
Option B is wrong because performing a factory reset after upgrading to 7.0 does not address the need for a correct upgrade path; it only resets the configuration, but the firmware itself must still be upgraded in the correct sequence to avoid bootloader or database incompatibilities. Option C is wrong because the 'execute upgrade-version' command does not exist; FortiGate uses 'execute update-now' for firmware updates, but there is no automatic path determination command—the administrator must manually follow the documented upgrade path. Option D is wrong because directly uploading and installing 7.0 firmware from 6.0 is not supported; it can result in a failed upgrade or a non-booting unit due to incompatible firmware structures, and restoring a configuration from backup after a direct upgrade may also fail if the configuration format has changed.
A FortiGate in NAT/Route mode has multiple internal networks. The administrator wants to configure a loopback interface for management access. Which THREE statements about loopback interfaces are correct? (Choose three.)
Because a loopback interface has no physical hardware behind it, its link status is always administratively and operationally up as long as the FortiGate unit itself is powered on and running. This is a key advantage over physical interfaces, which may go down due to cable disconnection, switch failure, or negotiated link loss. The persistent up state makes loopback interfaces ideal for dynamic routing protocols and management sources that need a stable endpoint.
Why this answer
Option B is correct because a FortiGate loopback interface is a logical interface with no dependency on any physical link, so its operational state remains up even if physical ports go down. Option C is correct because the loopback's stable IP address is commonly configured as the source-ip for management protocols such as HTTPS, SSH, SNMP, and syslog, ensuring consistent management reachability. Option E is correct because loopback interfaces can be included in routing protocol configurations (for example, OSPF or BGP) and advertised as a stable router ID or network, which is a standard design practice.
Option A is wrong because a loopback is a logical interface that is not bound to a physical port. Option D is wrong because loopback interfaces can absolutely be referenced in firewall policies as source or destination interfaces.
Exam trap
The trap here is that candidates often assume loopback interfaces cannot be used in firewall policies or must be tied to a physical port, but FortiGate treats them as fully functional interfaces for both routing and policy enforcement.
A FortiGate is configured with two WAN links (port1 and port2) and uses ECMP routing. The administrator wants to ensure that traffic from a specific internal subnet (192.168.10.0/24) always uses port1, while all other traffic uses ECMP. Which configuration should be applied?
Equal-distance static routes create an ECMP group that load-balances traffic across port1 and port2, but this balances based on destination and may not honor source-based preferences. Adding a policy route for 192.168.10.0/24 with outgoing interface port1 forces all traffic originating from that source subnet to egress via port1, overriding the ECMP decision for that specific source. This combination gives you both the high-availability/load-balancing benefit of ECMP and the required source-specific egress control.
Why this answer
Policy routes override the routing table for matching traffic, allowing you to force traffic from 192.168.10.0/24 out port1 while ECMP handles all other traffic. ECMP distributes traffic across multiple equal-cost routes, but a policy route takes precedence over the routing table for specified traffic. This meets the requirement without disrupting ECMP for other traffic.
Exam trap
The trap here is confusing firewall policies with routing decisions; candidates often think a firewall policy can change the outgoing interface, but it only controls access, not the path traffic takes through the network.
How to eliminate wrong answers
Option A is wrong because creating a separate VDOM for a single subnet is overkill and introduces administrative overhead; VDOMs are for multi-tenant isolation, not simple source-based routing. Option C is wrong because a VIP translates destination IPs, not source subnets, and does not control outbound interface selection. Option D is wrong because firewall policies do not change routes; they match traffic and apply actions like allow/deny, but routing decisions are made by the routing table or policy routes.
An administrator wants to back up the FortiGate configuration to a remote FTP server. Which command should be used?
`execute backup config ftp <filename> <server>` is the correct FortiGate CLI command to export the current configuration to a remote FTP server. The command specifies the object type `config` (the device configuration), the protocol `ftp`, the destination filename, and the server's hostname or IP address. FortiOS will prompt for FTP credentials if they are not provided, and the resulting backup file can later be restored with the corresponding `execute restore config ftp` command. This is the standard, supported method for a configuration backup via FTP.
Why this answer
The `execute backup config ftp` command is the specific FortiGate CLI command designed to back up the configuration file to a remote FTP server. This command directly initiates an FTP transfer of the current system configuration, ensuring the backup is stored externally for disaster recovery.
Exam trap
The trap here is confusing the `backup` and `restore` commands, or using a Cisco-style command like `copy running-config startup-config`, which is not valid on FortiGate devices.
How to eliminate wrong answers
Option A is wrong because `execute restore config ftp` is used to restore a configuration from an FTP server, not to back up. Option B is wrong because `copy running-config startup-config` is a Cisco IOS command for saving the running configuration to NVRAM, not a FortiGate command for backing up to an FTP server. Option C is wrong because `execute backup system ftp` is not a valid FortiGate command; the correct syntax uses `config` to specify the configuration file, not `system`.
A FortiGate administrator needs to allow SNMP monitoring from a management station at 10.10.10.50. Which TWO configuration steps are required? (Choose two.)
The FortiGate's SNMP agent is disabled by default; without enabling it globally under System > SNMP, the device will not respond to any SNMP get/set requests regardless of other configuration. Enabling the agent is the mandatory first step to allow a management station to poll MIB objects such as interface utilization, CPU, and memory. This is a global toggle, not per-interface, and once enabled the agent listens on port 161 for all configured SNMP communities.
Why this answer
The SNMP agent must be globally enabled on the FortiGate before any SNMP queries can be processed. Option B is correct because an SNMP community with read-only access defines the authentication and access control parameters, and restricting it to 10.10.10.50 ensures only that management station can poll the device.
A FortiGate is configured with two VDOMs: root and vdom1. The administrator wants to allow a server in vdom1 to be accessible from the internet via a virtual IP (VIP) configured in the root VDOM. Which configuration is required to achieve this?
Inter-VDOM links are required to route traffic between VDOMs. The VIP in the root VDOM will translate the destination IP to the server's IP in vdom1. Firewall policies on both VDOMs must allow the traffic. This setup enables the server in vdom1 to be reachable from the internet through the root VDOM's VIP.
Why this answer
To allow a server in one VDOM to be accessible via a VIP in another VDOM, inter-VDOM links must be configured to route traffic between them. Firewall policies on both VDOMs are also required to permit the traffic. This ensures that the VIP in the root VDOM can forward traffic to the server in vdom1, and return traffic can flow back.
Exam trap
The trap here is thinking that a static route to a VIP or sharing interfaces can bridge VDOMs, when the correct method is inter-VDOM links with firewall policies.
You are troubleshooting a FortiGate HA cluster that is not failing over correctly. The cluster has two units in active-passive mode. You check the HA status and see both units are in 'standalone' mode. Which THREE configurations could cause this? (Choose three.)
The HA group ID is a mandatory matching parameter for cluster membership; each heartbeat packet carries the group ID, and a FortiGate only processes heartbeats from units with the same group ID. If the two units are configured with different group IDs, they will silently discard each other's heartbeat messages, so neither ever sees a peer and both remain in standalone mode. This is a classic misconfiguration when units are pre-staged separately or when a configuration template is not synchronized. Setting both units to the same group ID (0 through 255) is required before they can form an HA cluster.
Why this answer
The HA group ID must match on all cluster members for them to recognize each other as part of the same cluster. If the group IDs differ, each unit will operate independently in standalone mode, as they cannot form a common HA session.
Exam trap
The trap here is that candidates often overlook the HA password requirement or assume transparent mode disables HA, but FortiGate supports HA in all operational modes, and password mismatches are a common misconfiguration.
An administrator is configuring ECMP (Equal-Cost Multi-Path) on a FortiGate. Which TWO conditions are required for ECMP to load balance traffic across multiple routes?
The route priority setting, also known as the metric, must be identical for all routes to be eligible for ECMP in FortiGate. FortiGate evaluates routes by administrative distance first, then priority, and only when both values match are the routes considered equal cost and installed simultaneously. If one route has a lower priority, it will always be preferred, and the higher-priority route will be ignored, preventing load balancing. Therefore, ensuring the same priority is a correct and essential condition for ECMP.
Why this answer
ECMP requires that multiple routes have the same priority (also known as 'distance' in some contexts) to be considered equal-cost. In FortiGate, priority is a metric that determines route preference; only routes with identical priority can be used simultaneously for load balancing. Option C is also correct because administrative distance must be the same for routes to be considered equal; if administrative distances differ, the route with the lower distance is preferred, and ECMP will not apply.
Exam trap
The trap here is that candidates often confuse 'priority' with 'administrative distance' or assume ECMP requires different next-hop IPs, but FortiGate actually requires both priority and administrative distance to be identical, and next-hop IPs can be the same if interfaces differ.
An administrator needs to forward logs from a FortiGate to a FortiAnalyzer for centralized logging. The FortiAnalyzer IP is 10.10.10.10. Which configuration is required on the FortiGate?
This is the correct FortiOS CLI branch for enabling FortiAnalyzer log forwarding. 'set status enable' activates the FortiAnalyzer connection, and 'set server 10.10.10.10' defines the destination FortiAnalyzer appliance's IP address; optional settings like 'set upload enable' control exactly how logs are pushed. Once committed, the FortiGate establishes a dedicated logging channel to FortiAnalyzer, which is the intended method for collecting logs on that platform.
Why this answer
The FortiGate uses the `config log fortianalyzer setting` command to configure direct logging to a FortiAnalyzer. This command enables the log forwarding feature (`set status enable`) and specifies the FortiAnalyzer's IP address (`set server 10.10.10.10`). The other options either use incorrect command paths or are intended for different logging destinations (e.g., syslog or central management).
Exam trap
The trap here is that candidates confuse the `config log fortianalyzer setting` command with the `config system central-management` command (used for FortiManager) or the syslog configuration, leading them to select options that configure the wrong service or miss the required `set status enable` step.
How to eliminate wrong answers
Option A is wrong because `config system central-management` is used for centralized management (e.g., FortiManager), not for log forwarding to FortiAnalyzer. Option B is wrong because `config log setting` is a global log configuration context, but the correct subcommand for FortiAnalyzer is `config log fortianalyzer setting`, not a direct `set fortianalyzer ip` syntax. Option C is wrong because `config log syslogd setting` configures syslog forwarding, which uses a different protocol (UDP/TCP syslog) and is not the native FortiAnalyzer logging method.
An admin needs to configure a FortiGate to send logs to a FortiAnalyzer. Which TWO steps must be performed? (Choose two.)
The command `config system log-fortianalyzer` enters the FortiAnalyzer configuration mode, where the `set server <ip>` command specifies the IPv4 address of the FortiAnalyzer device that will receive logs. This is the mandatory first step in the CLI to point the FortiGate at its log collector. Without this address, the FortiGate has no destination for its syslog-like log streams to FortiAnalyzer. Optionally, parameters like `set upload-option` and `set source-ip` can also be set here, but the server IP is essential.
Why this answer
The FortiGate must be configured with the FortiAnalyzer IP address under the `config system log-fortianalyzer` hierarchy to establish the logging destination. Option E is correct because after setting the IP, the `set status enable` command must be issued to activate log forwarding to that FortiAnalyzer; without this, no logs are sent even if the IP is configured.
Exam trap
The trap here is that candidates often think a firewall policy is required to allow outbound log traffic, but FortiGate management traffic (including logs to FortiAnalyzer) bypasses the firewall policy engine and is controlled solely by the management VDOM or system settings.
An administrator has configured two FortiGate units in an active-passive HA cluster. The primary unit fails. How does the secondary unit become active?
FortiGate HA uses heartbeat packets over the HA link; when the secondary stops receiving them within the configured thresholds, it assumes the primary has failed and transitions to active, taking over the cluster's IP addresses and sessions.
Why this answer
In an active-passive HA cluster, the secondary unit monitors the primary unit's health via heartbeat messages. When the primary fails and stops sending heartbeats, the secondary unit detects the loss of heartbeat and initiates a failover, transitioning to the active role. This is the default behavior in FortiGate HA, where the secondary unit does not require manual intervention or additional conditions to become active.
Exam trap
The trap here is that candidates may think the secondary unit requires the heartbeat link to be down or manual intervention to become active, but FortiGate HA automatically promotes the secondary unit upon detecting the primary's failure via heartbeat loss.
How to eliminate wrong answers
Option B is wrong because FortiGate HA is designed for automatic failover; the administrator does not need to manually reboot the secondary unit, as that would defeat the purpose of high availability. Option C is wrong because the secondary unit becomes active when the primary fails, regardless of whether the heartbeat link is also down; the heartbeat link being down alone would not trigger a failover if the primary is still active. Option D is wrong because the secondary unit does not wait for a configuration change; it becomes active based on the failure detection, and configuration synchronization occurs after the failover.
An administrator configures a policy route to send all traffic from a specific subnet to a different next-hop. However, traffic from that subnet is still using the default route. Which configuration could be causing this?
Policy routes are tied to a specific incoming interface, so if the traffic arrives on a different interface than the one specified in the policy route, the route will never be evaluated. The administrator must confirm that the policy route's incoming interface matches the physical port where the traffic actually enters the FortiGate. Since the policy route is not applied on the wrong interface, the traffic follows the normal routing table, and the intended policy behavior is not observed.
Why this answer
Policy routes are evaluated based on the incoming interface of the traffic. If the policy route is applied to the wrong incoming interface, traffic from the specified subnet arriving on a different interface will not match the policy and will instead follow the default route. This is a common misconfiguration where the administrator assumes the policy applies globally rather than per-interface.
Exam trap
The trap here is that candidates often assume policy routes apply globally to all traffic matching the source/destination, forgetting that FortiGate requires the incoming interface to be explicitly specified for policy routes to be evaluated.
How to eliminate wrong answers
Option A is wrong because firewall policies are evaluated after policy routing in FortiGate's processing order; if policy routing matches, the traffic is forwarded to the policy route's next-hop before any firewall policy is checked, so a deny firewall policy would not cause the traffic to use the default route. Option C is wrong because a higher administrative distance makes a route less preferred, so if the default route had a higher administrative distance, it would be less likely to be used, not more; the issue is that the policy route is not being matched at all. Option D is wrong because setting the policy route destination to 'all' would match all destinations, which would actually increase the likelihood of the policy route being applied, not cause it to be ignored; the problem is the interface mismatch, not the destination setting.
A FortiGate is operating in transparent mode. The administrator needs to configure a new VLAN interface for segmenting traffic. Which statement about VLAN interfaces in transparent mode is correct?
Correct: In transparent mode, you can create VLAN subinterfaces on physical ports to segment the Layer-2 network. These interfaces operate purely at Layer 2, bridging frames between 802.1Q-tagged segments without any IP configuration for forwarding. A management IP is optional and only for administrative access, not for the VLAN interface's traffic path. This design lets the firewall apply security policies to VLAN traffic while remaining invisible to Layer 3 routing.
Why this answer
In transparent mode, FortiGate acts as a layer-2 bridge, forwarding traffic based on MAC addresses. VLAN interfaces can be created on physical interfaces to segment traffic at layer 2, and they do not require IP addresses for forwarding; IP addresses are only needed for management access if desired.
How to eliminate wrong answers
Option A is wrong because VLAN interfaces in transparent mode are layer-2 only and do not require IP addresses for traffic forwarding; they are not routed interfaces. Option C is wrong because VLAN interfaces do not require a separate IP address in the management VDOM; IP addresses are optional and only for management. Option D is wrong because VLAN interfaces are fully supported in transparent mode; the administrator does not need to switch to NAT/Route mode.
An administrator wants to upgrade the FortiOS firmware on a FortiGate. Which step is critical before starting the upgrade process?
Backing up the configuration file is the correct and mandatory prerequisite before upgrading FortiOS. Use the 'execute backup config' CLI command or the GUI's System > Backup feature to save a copy of the current configuration to a local host or remote server. If the upgrade fails or you need to downgrade to a previous firmware version, this backup allows you to restore the exact pre-upgrade settings, preventing configuration loss or manual re-entry of policies, routes, and objects.
Why this answer
Backing up the configuration file is critical before upgrading FortiOS because the upgrade process may fail or corrupt the configuration, and a backup ensures you can restore the FortiGate to its previous operational state. Without a valid backup, a failed upgrade could result in a complete loss of configuration, requiring manual reconfiguration or a factory reset. Fortinet recommends always backing up the configuration before any firmware upgrade to mitigate risks.
Exam trap
The trap here is that candidates may confuse operational steps (like clearing sessions or disabling policies) with the critical prerequisite of configuration backup, assuming the upgrade process will automatically preserve settings without risk.
How to eliminate wrong answers
Option A is wrong because rebooting the FortiGate before an upgrade is unnecessary and may disrupt current operations; the upgrade process itself handles rebooting as needed. Option B is wrong because clearing all sessions is not a prerequisite for upgrading; the FortiGate will terminate sessions during the reboot phase of the upgrade automatically. Option D is wrong because disabling all firewall policies is not required; the upgrade process preserves policy configurations, and disabling them could cause unintended traffic disruptions if the upgrade fails or is rolled back.
A FortiGate administrator needs to configure a VLAN interface and an aggregate interface. Which THREE statements are correct regarding these interface types?
For an aggregate interface to pass traffic, FortiOS requires at least one physical member interface to be administratively enabled and have a live link; if every member is down, the aggregate port is marked down. This is the basis of the correct answer because it accurately reflects a physical requirement for aggregate interfaces in FortiOS.
Why this answer
An aggregate interface (LAG) requires at least one physical member port to be administratively and operationally up for the aggregate itself to be considered up. If all member ports are down, the aggregate interface goes down, which is a fundamental behavior of link aggregation groups (LAGs) per IEEE 802.3ad.
Exam trap
The trap here is that candidates often confuse the mode restrictions for VLANs and aggregates, incorrectly assuming VLANs cannot be used in Transparent mode or that aggregates are limited to NAT/Route mode, when in fact both interface types have broader support.
A FortiGate administrator is configuring a new VLAN interface on a managed FortiSwitch. The FortiGate is the FortiLink parent. The administrator wants to ensure that the VLAN is properly recognized and that traffic can flow between the FortiGate and devices on that VLAN. Which two actions must the administrator perform? (Choose two.)
The FortiSwitch must have the VLAN defined and assigned to the ports where devices will connect. This is typically done via the FortiGate's managed switch configuration, which pushes the VLAN settings to the FortiSwitch. Without this, the VLAN is not present on the switch ports.
Why this answer
For a VLAN to function on a FortiLink-managed FortiSwitch, the FortiGate must have a VLAN interface with the matching VLAN ID bound to the FortiLink interface, and the FortiSwitch must have the VLAN configured on the appropriate ports. These two steps ensure the VLAN is recognized and traffic can flow. Other options are either optional security features or unnecessary configuration steps.
Exam trap
The trap here is assuming that creating the VLAN on the FortiGate alone is sufficient, without also configuring the VLAN on the FortiSwitch ports.
A FortiGate admin needs to create a loopback interface for management purposes. Which two statements about loopback interfaces are correct? (Choose two.)
A loopback interface in FortiOS is a virtual interface that has no physical hardware dependency; its operational status is tied to the system's presence and never to any link state. Consequently, the loopback stays up unless the FortiGate itself is rebooted or powered off, even if every physical port is down. This makes it the preferred logical anchor for router IDs, management sessions, and services that need uninterrupted reachability.
Why this answer
Loopback interfaces are virtual interfaces that are always in an up/up state as long as the FortiGate is operational. They do not depend on any physical link or carrier status, making them ideal for management access and stable routing protocol peering.
Exam trap
The trap here is that candidates often assume loopback interfaces are only for routing protocols or that they cannot have an IP address, but FortiGate loopback interfaces fully support IP addressing and are used for multiple purposes including management and VPN termination.
A FortiGate is configured with two equal-cost static routes to the same destination network (0.0.0.0/0) via two different ISPs. The administrator wants to use both links simultaneously for load balancing. What must be enabled?
FortiGate interprets multiple static routes to the same destination with identical distance and priority as equal-cost paths, installing all of them in the routing table. It then uses a per-destination hash (not per-packet) to select the egress interface for each new session, which preserves session stickiness and enables load sharing across links. This behavior is enabled by default and does not require any additional feature or configuration.
Why this answer
Equal Cost Multi-Path (ECMP) routing is the correct feature to enable because it allows a FortiGate to load-balance traffic across multiple static routes that have the same metric (distance) to the same destination (0.0.0.0/0). By default, FortiGate uses a single best route; enabling ECMP distributes sessions across both ISP links based on a hash algorithm (e.g., source-destination IP), achieving simultaneous utilization without requiring dynamic routing protocols.
Exam trap
The trap here is that candidates confuse ECMP with SD-WAN, assuming SD-WAN is mandatory for any multi-WAN load balancing, when in fact ECMP alone suffices for equal-cost static routes without application-aware steering or link health monitoring.
How to eliminate wrong answers
Option B (SD-WAN) is wrong because SD-WAN is a broader solution for intelligent path control, application steering, and link quality monitoring, but it is not required solely for basic load balancing across equal-cost static routes—ECMP handles that natively. Option C (Link load balancing) is wrong because it is not a specific FortiGate feature; the term is generic and often refers to external hardware or SD-WAN, whereas ECMP is the precise mechanism for equal-cost route load sharing. Option D (Policy routing) is wrong because policy routing (PBR) overrides the routing table based on user-defined policies (e.g., source IP, protocol), which is used for selective traffic steering, not for automatically load-balancing all traffic across equal-cost static routes.
An administrator is planning a firmware upgrade from FortiOS 6.0 to 7.2. Which THREE steps should be performed before starting the upgrade process?
Release notes are the authoritative source for firmware-specific changes, upgrade caveats, and known issues that can affect the FortiGate during or after the upgrade. They detail critical items such as changes to default behavior, deprecated features, and special instructions for the target version — skipping them can lead to unexpected post-upgrade behavior or service outages.
Why this answer
Reading the release notes for the target firmware version (FortiOS 7.2) is essential because they document critical upgrade-specific information, such as deprecated features, changed default behaviors, known issues, and hardware compatibility requirements. Skipping this step can lead to unexpected service disruptions or feature loss after the upgrade, as the release notes often include mandatory pre-upgrade actions like disabling certain features or adjusting configurations.
Exam trap
The trap here is that candidates may think disabling security features (Option E) is a safe precaution, but Fortinet explicitly advises against disabling security profiles unless a specific release note entry warns of a conflict, making it a distractor that wastes time and reduces security posture.
An administrator attempts to configure a policy route to route specific traffic from an internal subnet (10.1.1.0/24) to the internet via a different ISP. The policy route is created but traffic is still using the default route. What is the most likely cause?
In FortiGate, policy routes are only considered valid when the specified outgoing interface is in an up state. If that interface is down, the policy route is automatically excluded from the forwarding decision, and packets are instead processed by the normal routing table. This fallback behavior explains why traffic continues to use the default route rather than the intended policy-based path.
Why this answer
Policy routes in FortiGate have a higher priority than static routes, but they are only applied if the specified outgoing interface is operationally up. If the outgoing interface is down, the policy route is skipped, and traffic falls back to the default route. This is the most likely cause because the administrator confirmed the policy route was created but traffic still uses the default route.
Exam trap
The trap here is that candidates often assume policy routes always override static routes, but they forget that FortiGate requires the outgoing interface to be up for the policy route to be active, leading them to incorrectly select administrative distance or source interface issues.
How to eliminate wrong answers
Option B is wrong because the source interface in a policy route is optional; if omitted, the policy matches based on source IP alone, so an incorrect source interface would not cause the policy to be ignored entirely. Option C is wrong because an incorrect destination address would cause the policy to not match the traffic, but the question states the policy route was created and traffic is still using the default route, implying the policy exists but is not being applied. Option D is wrong because policy routes have a higher precedence than static routes regardless of administrative distance; administrative distance only applies to static route selection, not to policy route enforcement.
A FortiGate in an HA active-passive cluster is experiencing frequent failovers. The administrator checks the HA statistics and sees that the primary unit's heartbeat interface has a high error rate. What is the most likely cause?
A faulty heartbeat cable or duplex mismatch causes physical-layer errors (CRC, late collisions, high error counts) on the dedicated HA link. Because the FortiGate continuously sends heartbeat packets to verify the peer's liveness, any corruption or drop of those packets is interpreted as a lost heartbeat. This repeated loss of consistency checks makes the cluster flap—each missed heartbeat triggers failover, then the link recovers and the cluster rejoins, causing frequent, disruptive failovers.
Why this answer
A high error rate on the heartbeat interface indicates physical-layer issues such as a faulty cable or duplex mismatch. In an HA active-passive cluster, the heartbeat link must be reliable and low-latency; errors cause packet loss, leading the primary unit to appear unresponsive and triggering a failover to the secondary unit.
Exam trap
The trap here is that candidates often attribute frequent failovers to configuration mismatches (like passwords) or threshold settings, overlooking the physical-layer cause indicated by the high error rate on the heartbeat interface.
How to eliminate wrong answers
Option B is wrong because while a single heartbeat link without redundancy increases risk, it does not directly cause a high error rate on the interface; the error rate is a physical-layer symptom. Option C is wrong because a low failover threshold would cause failovers based on monitored metrics (e.g., link status or ping response), not a high error rate on the heartbeat interface itself. Option D is wrong because mismatched HA passwords prevent the cluster from forming or synchronizing, but they do not cause interface-level errors; the heartbeat link would still show no errors if the cable and duplex settings are correct.
A FortiGate administrator is troubleshooting a problem where users cannot access the Internet. The FortiGate has a default route pointing to the ISP gateway. The administrator runs 'execute ping 8.8.8.8' from the FortiGate CLI and it succeeds. However, internal users behind NAT are unable to reach external servers. Which is the most likely cause?
If no NAT policy is configured for internal users' traffic, the FortiGate forwards packets with the original private source IP addresses (e.g., 10.0.0.0/8). The external server sends reply packets to that private address, which is not routable across the public internet, causing return traffic to be dropped or blackholed. The FortiGate's own ping works because it uses its interface's public IP as the source, so replies are routable. This mismatch—successful ping from the FortiGate but failures for internal users—is a classic symptom of missing source NAT.
Why this answer
The administrator confirmed that the FortiGate itself can reach the Internet (ping 8.8.8.8 succeeds), so the default route and basic connectivity are working. However, internal users behind NAT cannot reach external servers, which indicates that traffic from internal users is either not being translated or is being blocked. The most likely cause is that no NAT policy (or firewall policy with NAT enabled) exists to perform source NAT for internal users, so their private IP addresses are not translated to the FortiGate's public IP, and the ISP gateway drops the packets because private addresses are not routable on the Internet.
How to eliminate wrong answers
Option A is wrong because the default route is correctly configured — the 'execute ping 8.8.8.8' succeeded, proving the route works. Option B is wrong because an implicit deny policy would block all traffic, including the ping from the FortiGate itself; since the ping succeeded, there is no implicit deny blocking outbound traffic. Option D is wrong because the external access profile is a GUI/administrative access setting that controls read/write permissions for the web interface, not a factor in NAT or traffic forwarding.
A FortiGate administrator is setting up a new FortiGate in a network that requires the firewall to bridge traffic between two subnets without routing. Which operating mode should the administrator select?
In Transparent mode, the FortiGate operates as a Layer 2 bridge, forwarding Ethernet frames between interfaces based on MAC addresses, much like a wire or switch. It performs no routing or NAT, so existing IP addressing and subnetting remain unchanged, and the device is effectively invisible to the network. This is the correct answer because transparent mode is specifically designed for inline deployment without modifying the Layer 3 topology.
Why this answer
Transparent mode allows the FortiGate to act as a Layer 2 bridge, forwarding traffic between two subnets without performing any routing or NAT. In this mode, the firewall operates like a 'bump in the wire,' inspecting and filtering traffic based on MAC addresses and Layer 2 headers, while the IP addresses of connected devices remain unchanged. This is ideal for scenarios where the FortiGate must be inserted into an existing network without altering the IP topology.
How to eliminate wrong answers
Option B (NAT/Route mode) is wrong because it operates at Layer 3, performing routing and NAT, which changes the IP topology and is not suitable for bridging traffic without routing. Option C (HA mode) is wrong because it is a high-availability configuration for redundancy, not an operating mode for traffic forwarding; it can be used in either transparent or NAT/Route mode. Option D (VLAN mode) is wrong because it is not a standard operating mode on FortiGate; VLANs are configured as interfaces within transparent or NAT/Route mode, not as a separate mode.
What is the purpose of configuring an aggregate interface on a FortiGate?
An aggregate interface (also called a link aggregation group or LACP bundle) combines multiple physical interfaces into one logical interface to increase total throughput and provide link redundancy. It leverages link aggregation protocols like 802.3ad or static configuration to treat several physical members as a single logical link, with traffic load-balanced across members and automatic failover if a member link goes down. This is the foundational definition of link aggregation, making this the correct answer.
Why this answer
An aggregate interface (also known as a Link Aggregation Group or LAG) combines multiple physical FortiGate interfaces into a single logical interface. This increases throughput by load-balancing traffic across the member links and provides redundancy: if one physical link fails, traffic continues over the remaining links. FortiGate supports both static aggregation and LACP (IEEE 802.3ad) for dynamic negotiation.
Exam trap
The trap here is that candidates confuse link aggregation with VLAN trunking or interface redundancy protocols like VRRP, but aggregate interfaces specifically combine bandwidth and provide link-level redundancy, not IP-level failover or VLAN separation.
How to eliminate wrong answers
Option A is wrong because VLAN tagging is configured on a physical or aggregate interface via subinterfaces, not by creating an aggregate interface itself. Option C is wrong because separating management traffic from data traffic is achieved through dedicated management interfaces, administrative access controls, or VDOMs, not by link aggregation. Option D is wrong because connecting two different network segments with a firewall in between describes the fundamental role of a firewall (routing/security), not the purpose of an aggregate interface.
An admin configures two static routes to the same destination with different distances. The route with distance 10 points to ISP1, and the route with distance 20 points to ISP2. The admin wants to use ISP2 only if ISP1 fails. What is the expected behavior?
The lower administrative distance (10) on the ISP1 route makes it the most preferred static route, so it is installed as the active route in the routing table and all matching traffic uses ISP1. As long as that route exists and is reachable, the distance-20 ISP2 route stays inactive. If the ISP1 route is removed—for example, because the interface goes down or the route is administratively deleted—the FortiGate reevaluates the RIB and promotes the ISP2 route, shifting traffic to ISP2.
Why this answer
When two static routes have different administrative distances, the route with the lower distance (10) is preferred and installed in the routing table. The route with distance 20 remains in the routing table as a backup. If the preferred route (via ISP1) is removed due to a failure, the backup route (via ISP2) is automatically activated.
This behavior is fundamental to how FortiGate (and most routers) handle static routes with unequal distances.
Exam trap
The trap here is that candidates often think both routes are active and load-balancing occurs, but FortiGate only uses the route with the lowest administrative distance unless equal-cost load balancing is explicitly configured.
How to eliminate wrong answers
Option A is wrong because load-balancing requires equal-cost routes (same distance), but here distances are different (10 vs 20), so only the best route is used. Option C is wrong because the route with distance 20 is not ignored; it remains in the routing table as a backup and will be used if the primary route is removed. Option D is wrong because both routes are not active simultaneously; only the route with the lowest distance is active, and source IP is not a factor in static route selection.
Refer to the exhibit. An administrator wants to enable SNMP access on the wan1 interface. Which of the following is the most efficient method?
The FortiGate CLI command 'config system interface' followed by 'edit wan1' and 'set allowaccess ping https ssh snmp' explicitly appends snmp to the interface's list of permitted management access services. This is the mandatory per-interface gate: even after defining an SNMP community globally, the FortiGate will only respond to SNMP requests on interfaces whose allowaccess includes snmp. Adding snmp to wan1 therefore enables SNMP agents to serve queries and traps on that interface while preserving existing ping, https, and ssh management access.
Why this answer
The 'allowaccess' parameter under 'config system interface' controls which management protocols (ping, https, ssh, snmp, etc.) are permitted on a given interface. By adding 'snmp' to the allowaccess list for wan1, the administrator enables SNMP access on that interface without changing its role or type.
Exam trap
The trap here is that candidates often confuse configuring an SNMP community (which defines who can query) with enabling SNMP access on an interface (which allows the SNMP agent to listen on that interface); both are required, but the question asks for the most efficient method to enable SNMP access on wan1, which is setting 'allowaccess snmp' on that interface.
How to eliminate wrong answers
Option B is wrong because changing the interface type to 'management' is not required; the 'management' type is used for dedicated management interfaces (e.g., FortiGate models with a separate MGMT port) and does not apply to a standard data interface like wan1. Option C is wrong because 'snmp-index' is used to assign an OID index for SNMP monitoring of the interface, not to enable SNMP access on the interface. Option D is wrong because configuring an SNMP community defines the community strings and hosts allowed to query the FortiGate, but it does not enable SNMP access on a specific interface; the interface-level 'allowaccess' must still be set.
Refer to the exhibit. The FortiGate has two default routes. The administrator attempts to ping 8.8.8.8 from the CLI and receives no response. What is the most likely reason?
The route via 203.0.113.1 on port1 has an administrative distance of 10, making it the preferred route for all traffic. If that next-hop gateway becomes unreachable—for instance, port1 goes down, the connected network fails, or ARP resolution for 203.0.113.1 fails—the active route is removed or becomes unusable. FortiGate will not immediately fail over to the distance-20 route unless the primary route is completely removed; in many scenarios, traffic is dropped because the lower-distance route is still considered valid in the RIB but cannot forward packets. Thus, unreachability of the primary gateway directly explains the total loss of connectivity.
Why this answer
When a FortiGate has multiple default routes, it uses the route with the lowest distance (administrative distance) as the primary route. If the gateway for the primary route (203.0.113.1 on port1) is unreachable, the FortiGate will not be able to reach 8.8.8.8, even if a secondary default route exists. The ping fails because the device cannot ARP for the gateway or the next-hop is down, causing the route to be inactive.
Exam trap
The trap here is that candidates often assume both default routes are active and load-balanced, but FortiGate uses administrative distance to select a single active route, and if the gateway of that route is unreachable, the route becomes invalid and no traffic is forwarded until the next route is considered.
How to eliminate wrong answers
Option A is wrong because a second default route does not 'overwrite' the first; FortiGate supports multiple default routes and selects the best one based on distance or priority, not by overwriting. Option B is wrong because both routes are not equal-cost (they have different distances, 10 and 20), so load-balancing is not applicable; FortiGate uses the route with the lowest distance. Option C is wrong because duplicate default routes are allowed in FortiGate; they are valid as long as they have different distances or priorities, providing redundancy.
NAT/Route mode is the default operating mode for FortiGate, where each interface is assigned an IP address and the device performs Layer 3 routing between networks. It also enables network address translation (NAT), allowing traffic to be translated between different address domains. This mode is distinctly different from Transparent mode, which operates at Layer 2 without routing or NAT. Because the question asks about an operating mode that supports routing and NAT, NAT/Route mode is the correct answer.
Why this answer
NAT/Route mode (option B) is correct because it configures the FortiGate as a Layer 3 device with distinct interfaces in different subnets, enabling it to perform routing (forwarding packets based on routing table entries) and Network Address Translation (NAT) to translate private IP addresses to public IP addresses. This mode is the default and most common operational mode for perimeter firewalls, allowing policy-based routing and NAT rules to be applied between zones.
Exam trap
The trap here is confusing operational modes (NAT/Route vs. Transparent) with inspection modes (Flow-based vs. Proxy-based), leading candidates to incorrectly select Flow-based inspection mode as the answer for Layer 3 routing and NAT capabilities.
How to eliminate wrong answers
Option A is wrong because Flow-based inspection mode is a processing mode (not an operational mode) that inspects packets in a single pass using pattern matching and heuristics, but it does not define the firewall's Layer 3 routing or NAT capabilities. Option C is wrong because VLAN mode is not a standard FortiGate operational mode; VLANs are configured as sub-interfaces within NAT/Route or Transparent modes to segment traffic, but they do not independently enable Layer 3 routing or NAT. Option D is wrong because Transparent mode operates as a Layer 2 bridge (similar to a switch) without IP addresses on its interfaces, meaning it cannot perform NAT or routing between interfaces—it forwards traffic based on MAC addresses.
An administrator is configuring a VLAN interface on a FortiGate. The physical interface is port2 and the VLAN ID is 100. Which of the following correctly creates the VLAN interface?
The correct CLI creates a VLAN subinterface by editing port2.100 under config system interface. The name uses the dot notation to associate the subinterface with physical port2; set vlanid 100 tags traffic with 802.1Q VLAN 100, while set type vlan marks the interface as a VLAN interface. This sequence fully defines the logical interface and is the only valid way to add a VLAN on a FortiGate.
Why this answer
It uses the correct CLI syntax to create a VLAN subinterface on a FortiGate. The command `config system interface` enters the interface configuration context, `edit port2.100` creates or edits the subinterface named with the physical interface and VLAN ID, `set vlanid 100` assigns the VLAN tag, and `set type vlan` explicitly defines the interface type as VLAN. This matches the required configuration for 802.1Q VLAN tagging on FortiGate.
Exam trap
The trap here is that candidates often confuse the FortiGate CLI with Cisco IOS, where `interface port2.100` automatically implies a VLAN subinterface without needing an explicit `set type vlan` or `set vlanid` command, leading them to choose Option C or D.
How to eliminate wrong answers
Option B is wrong because it attempts to set the VLAN ID directly on the physical interface `port2` instead of creating a separate VLAN subinterface; FortiGate does not allow a VLAN ID on a physical interface. Option C is wrong because it creates the subinterface `port2.100` and sets the type to VLAN but omits the `set vlanid 100` command, which is mandatory to specify the 802.1Q tag. Option D is wrong because it uses the invalid command `config system vlan`; FortiGate does not have a `system vlan` configuration context—VLAN interfaces are always configured under `config system interface`.
Drag and drop the steps to configure a static route on a FortiGate firewall into the correct order.
Drag or tap steps into the slots.
Why this order
Static routes on FortiGate are configured in the router static configuration context, requiring a sequence number, destination, device, and gateway.
A FortiGate is configured with two WAN interfaces (port1 and port2) connected to different ISPs. The administrator wants to load-balance outbound traffic across both links using equal-cost routes. Which routing configuration should be applied?
Static routes with equal administrative distance and priority to the same destination are installed as ECMP (Equal-Cost Multi-Path) routes, allowing the FortiGate to spread outbound traffic across both WAN interfaces simultaneously. The FortiGate supports several load-balancing algorithms for ECMP, such as source-IP-based, weight-based, or usage-based, enabling granular control while still using both links. This is the correct way to achieve dual-WAN load balancing with static routing, and it pairs well with link health monitors to remove dead links dynamically.
Why this answer
ECMP (Equal-Cost Multi-Path) routing allows a FortiGate to load-balance outbound traffic across multiple interfaces when static routes have the same distance (administrative distance) and destination. By configuring two static routes with equal distance (e.g., 10) to 0.0.0.0/0 via port1 and port2, the FortiGate automatically distributes sessions across both links using a hash-based algorithm (e.g., source-destination IP), achieving the desired load balancing without dynamic routing protocols.
Exam trap
The trap here is that candidates confuse 'different distances' (which creates failover) with 'equal distances' (which enables load balancing), often selecting option D because they think varying metrics distributes traffic, but in reality, only equal administrative distances trigger ECMP load sharing.
How to eliminate wrong answers
Option A is wrong because policy routes are used for policy-based routing (PBR) based on criteria like source IP, not for simple load balancing across equal-cost links; they override the routing table and do not inherently provide ECMP load sharing. Option B is wrong because BGP is a dynamic routing protocol that can learn routes from ISPs, but it requires ISP cooperation and is unnecessary for simple outbound load balancing; ECMP with static routes is simpler and sufficient. Option D is wrong because configuring static routes with different distances (e.g., 10 and 20) creates a primary/backup (failover) scenario, not load balancing; the route with the lower distance is always preferred, and traffic never uses the higher-distance route unless the primary fails.
Which TWO of the following are prerequisites for configuring a high availability (HA) cluster on FortiGate? (Choose two.)
Running the same firmware version is a strict prerequisite for FortiGate HA. Both units must have the exact same FortiOS build, including any minor patches or hotfixes, because differences in firmware can cause protocol incompatibilities and prevent successful HA synchronization. Even minor version discrepancies can break the HA heartbeat and failover behavior, so Fortinet requires matching firmware before enabling HA.
Why this answer
FortiGate HA requires all cluster members to run the same firmware version to ensure configuration compatibility and consistent behavior. Mismatched firmware can lead to synchronization failures or unpredictable failover events, as the HA heartbeat and session synchronization protocols depend on identical code bases.
Exam trap
The trap here is that candidates often assume identical configuration is required before forming the cluster, but FortiGate automatically synchronizes the primary's configuration to the secondary, making pre-existing identical configs unnecessary.
After upgrading FortiGate firmware, the administrator notices that the 'config router static' command now shows a new keyword 'distance' instead of 'weight'. The upgrade also changed the ECMP load-balancing behavior. What was the likely change in the ECMP algorithm?
The FortiOS upgrade replaced the legacy weighted ECMP algorithm with a hash-based algorithm that hashes both the source and destination IP addresses (source-dest-IP-based). Previously, the route's 'weight' value determined how much traffic each path carried; after the upgrade, that weight attribute is no longer used, and path selection for a session is deterministic based on the source and destination IP pair, ensuring session stickiness. The 'distance' setting still influences route selection but does not provide proportional load sharing; this is the default behavior in the upgraded FortiOS environment.
Why this answer
In FortiOS 6.4, the default ECMP method was weighted, using the 'weight' parameter in static routes. Starting with FortiOS 7.0, the 'weight' parameter was replaced by 'distance', and the default ECMP algorithm changed to source-IP-based hash (also referred to as source-dest-IP hash). This change enhances load balancing by distributing traffic based on source/destination IP addresses rather than priority weights.
Exam trap
The trap is that candidates may assume the change was from source-IP-based to weighted because the new keyword 'distance' seems like a weight metric. However, the actual change was from weighted to source-IP-based hash, as the 'weight' parameter was deprecated and replaced by 'distance' for administrative distance, not for load-balancing weight.
How to eliminate wrong answers
Option B is wrong because the change is from weighted to source-IP-based hashing, not from weighted to source-dest-IP; source-dest-IP is a separate hash algorithm that can be configured but is not the default after the upgrade. Option C is wrong because ECMP load-balancing is configured via 'config system settings' with the 'ecmp-algorithm' command, not via 'config system ecmp', which does not exist in FortiOS. Option D is wrong because the algorithm changed from weighted to source-IP-based hashing, not from source-dest-IP to round-robin; round-robin is not a supported ECMP algorithm in FortiOS.
A FortiGate administrator is planning an upgrade from FortiOS 6.4 to 7.2. Which THREE steps should be performed before the upgrade? (Choose three.)
Verify hardware compatibility by consulting Fortinet's Hardware Compatibility Guide before upgrading. Some FortiGate models have limited lifecycle support or hardware constraints such as insufficient memory or CPU architecture that prevent running newer FortiOS versions. Attempting an unsupported upgrade on such platforms can fail during installation or cause a device brick, so confirming model support is the first essential pre-flight check.
Why this answer
Verifying hardware compatibility with the target firmware is essential because FortiGate models have specific hardware limitations (e.g., CPU, RAM, storage) that may not support newer FortiOS versions. For example, older models like the FortiGate 100D cannot upgrade beyond FortiOS 6.0, and attempting to install 7.2 could result in a failed boot or bricked device. This step ensures the hardware meets the minimum requirements for the target firmware.
Exam trap
The trap here is that candidates may think removing firewall policies is necessary to avoid compatibility issues during the upgrade, but FortiOS automatically handles policy migration, and deleting them only adds unnecessary risk and downtime.
An administrator needs to configure a FortiGate to allow web traffic from the internal network to the Internet. The internal network is 192.168.1.0/24 and the WAN interface is port1 with IP 203.0.113.1. Which firewall policy is correct?
This policy correctly implements outbound web access: traffic originates from the internal network, exits via the port1 interface that connects to the Internet, and is restricted to HTTP/HTTPS services. Because FortiGate firewall policies are interface-based and stateful, this single policy also allows the corresponding return traffic from external web servers to flow back to the internal users without an explicit reverse rule. The Action ACCEPT ensures that the traffic is permitted, aligning with the required use case.
Why this answer
The firewall policy must match traffic originating from the internal network (source: internal) destined for the Internet via the WAN interface (destination: port1), and the service must be restricted to HTTP/HTTPS to allow web traffic only. The action ACCEPT permits the traffic. This aligns with the standard stateful inspection flow where source and destination interfaces are defined based on traffic direction.
Exam trap
The trap here is that candidates often confuse the source and destination interfaces in a policy, thinking the destination should be the internal network instead of the WAN interface for outbound traffic, or they select Service: ALL to avoid missing any protocol, ignoring the requirement for web traffic only.
How to eliminate wrong answers
Option B is wrong because it reverses the source and destination interfaces: traffic from port1 (WAN) to internal would be inbound, not outbound web traffic from internal to the Internet. Option C is wrong because 'external' is not a valid source interface in this context; the source must be the internal network interface, and the destination interface must be port1 for outbound traffic. Option D is wrong because it uses Service: ALL, which would allow all protocols (e.g., SSH, SMTP) instead of restricting to HTTP/HTTPS as required for web traffic only, violating the principle of least privilege.
An administrator wants to ensure that traffic to a specific web server always exits through a particular ISP link, regardless of route changes. Which feature should be configured?
Policy-based routing matches traffic against criteria such as source, destination or service, then forwards it via a specified gateway, overriding the destination-based lookup in the routing table. This guarantees the web server's traffic always exits the chosen ISP link despite route changes.
Why this answer
Policy-based routing (PBR) allows you to override the routing table by applying a route map to match traffic (e.g., source/destination IP, port) and explicitly set the next-hop interface or ISP link. This ensures traffic to the specific web server always exits through the designated ISP, regardless of dynamic route changes or the routing table's default behavior.
Exam trap
The trap here is that candidates confuse PBR with static routing or SD-WAN load balancing, thinking that a static route with a higher distance or SD-WAN can force traffic to a specific link, but only PBR provides the granular match-and-set logic to override the routing table for specific traffic flows regardless of route changes.
How to eliminate wrong answers
Option A is wrong because ECMP distributes traffic across multiple equal-cost paths for load balancing, not for pinning traffic to a specific link. Option C is wrong because a static route with a higher distance (administrative distance) acts as a backup route and only takes effect when the primary route is unavailable, not for forcing traffic to a particular link when the primary route is active. Option D is wrong because SD-WAN with load balancing distributes traffic across multiple WAN links based on policies or performance metrics, which does not guarantee that all traffic to a specific web server always uses the same ISP link.
A FortiGate is configured with two WAN interfaces in an SD-WAN zone. The administrator wants to ensure voice traffic uses the interface with the lowest latency. Which SD-WAN configuration should be used?
This is correct because a performance SLA defines the latency threshold and probing mechanism, and the Best Quality strategy inspects those live SLA results to choose the WAN interface with the lowest measured latency. When the SLA detects that a WAN link's latency exceeds the threshold, the FortiGate dynamically fails over voice traffic to the best-performing member, ensuring optimal real-time voice quality.
Why this answer
SD-WAN rules with a performance SLA allow the FortiGate to monitor real-time latency on each WAN interface and dynamically route voice traffic to the interface with the lowest latency. The 'Best Quality' strategy selects the best-performing interface based on the SLA metrics, ensuring optimal voice quality.
Exam trap
The trap here is that candidates often confuse policy-based routing (PBR) with SD-WAN rules, not realizing that PBR lacks dynamic SLA-based path selection and cannot automatically adapt to changing network conditions.
How to eliminate wrong answers
Option A is wrong because setting the strategy to 'Manual' requires the administrator to statically assign traffic to a specific interface, which cannot adapt to changing latency conditions. Option B is wrong because 'Load Balance' distributes traffic across interfaces based on load, not latency, and does not guarantee the lowest-latency path for voice traffic. Option D is wrong because policy-based routing (PBR) uses static routing rules that do not dynamically adjust based on real-time latency measurements, unlike SD-WAN rules with performance SLAs.
A FortiGate has been configured with two WAN interfaces (wan1, wan2) in an SD-WAN zone. The administrator wants to ensure that traffic for a specific internal server uses only wan1. What is the most appropriate method?
Creating an SD-WAN rule that matches the server's traffic (e.g., by destination IP address) and setting the preferred member to wan1 is the correct solution because SD-WAN rules are evaluated after policy routes and allow granular, application-aware egress selection. The preferred member setting ensures that wan1 is used for matching sessions, while other traffic can still be load-balanced or failed over across the WAN interfaces based on SD-WAN health-check and performance SLA. This approach is the recommended, flexible, and maintainable way to steer specific traffic in a Fortinet SD-WAN design.
Why this answer
SD-WAN rules allow granular traffic steering based on application, source, or destination. By creating an SD-WAN rule that matches the traffic destined for the internal server and setting the preferred member to wan1, the FortiGate will use SD-WAN's policy-based routing to ensure that traffic egresses exclusively via wan1, while other traffic can still use both WAN interfaces as per other rules.
Exam trap
The trap here is that candidates often confuse policy routing (Option B) with SD-WAN rules, not realizing that SD-WAN rules are the proper mechanism for per-traffic member selection within an SD-WAN zone, and that policy routing operates at a different layer and can override SD-WAN behavior if not carefully managed.
How to eliminate wrong answers
Option A is wrong because disabling wan2 in the SD-WAN zone removes it from all load-balancing and failover, which is overly broad and not a targeted solution for a single server's traffic. Option B is wrong because policy routing (PBR) operates independently of SD-WAN and can create conflicts; SD-WAN rules are the intended method for per-traffic member selection within an SD-WAN zone. Option C is wrong because configuring a static route with a higher distance for wan2 affects all traffic using that route, not just the specific server's traffic, and static routes do not integrate with SD-WAN's application-aware steering.
You run the following command on a FortiGate: ``` diagnose sys session filter dport 443 diagnose sys session list ``` The output shows: ``` proto=6 proto_state=01 duration=3600 expire=3599 ``` What does this indicate?
In FortiGate's session table output, the Duration field shows the total time elapsed since the session was first created, while the Expire field shows the remaining time before the session is removed from the table. A duration of 3600 seconds means the session has been active for exactly one hour, and an expire value of 3599 seconds indicates that timeout will occur in just under one hour. This interpretation is correct because these fields measure session age and remaining lifetime, not idle time or connection state.
Why this answer
The output shows `duration=3600` and `expire=3599`, which indicate the session has been active for 3600 seconds and has 3599 seconds remaining before timeout. The `proto=6` confirms TCP (protocol 6), and `proto_state=01` represents the TCP state for an established connection (ESTABLISHED), not a handshake state.
Exam trap
The trap here is confusing `duration` (time since session creation) with idle time, and misinterpreting `proto_state=01` as a handshake state (SYN_SENT) instead of the correct ESTABLISHED state.
How to eliminate wrong answers
Option B is wrong because `proto_state=01` in FortiGate's session table represents TCP state ESTABLISHED (not SYN_SENT); SYN_SENT would be state 02. Option C is wrong because `duration` measures the total time since the session was created, not idle time; idle time is tracked separately via the `idle` field in the session list. Option D is wrong because `proto=6` explicitly indicates TCP, not UDP (which would be proto=17).
An administrator configures a FortiGate to use NTP for time synchronization. After configuration, the FortiGate still shows the wrong time. Which command should the administrator run to verify NTP status?
The 'diagnose sys ntp status' command is the correct FortiOS diagnostic to display the current NTP daemon runtime status. It reports whether NTP synchronization has been enabled, the IP address of the last selected NTP server, the synchronization status (e.g., synchronized or unsynchronized), and the measured time offset. This is the only command among the listed options that shows real-time NTP synchronization information, making it the correct answer.
Why this answer
'diagnose sys ntp status' is the FortiGate CLI command that provides detailed NTP synchronization status, including whether the FortiGate is synchronized to an NTP server, the stratum level, and the last sync time. This command is specifically designed for troubleshooting NTP issues, unlike the other options which either show configuration or are invalid.
Exam trap
The trap here is that candidates confuse configuration commands (show system ntp) with diagnostic commands, or they assume a generic 'ntp status' command exists, when Fortinet specifically uses 'diagnose sys ntp status' for operational verification.
How to eliminate wrong answers
Option A is wrong because 'show system ntp' displays the NTP configuration (e.g., server addresses, authentication settings), not the operational status or synchronization state. Option B is wrong because 'execute ntp status' is not a valid FortiGate command; the correct execute command for NTP is 'execute ntp sync' to force synchronization. Option C is wrong because 'diagnose sys time status' shows the system time and time source (e.g., NTP, manual), but it does not provide detailed NTP peer status, offset, or jitter information.
An administrator configures a FortiGate in transparent mode. Which of the following is correct regarding transparent mode operation?
Transparent mode is designed to be invisible to end devices, acting as an inline security appliance without modifying IP addresses or making routing decisions. The FortiGate inspects frames at Layer 2, allowing IP packets to pass through unchanged, which is why it is often deployed without requiring any network redesign. This invisibility is the defining characteristic that makes the statement correct.
Why this answer
In transparent mode, the FortiGate operates as a Layer 2 bridge, forwarding traffic based on MAC addresses without performing any IP-level modifications. This means it does not perform NAT, and end devices are unaware of its presence, making option D correct.
Exam trap
The trap here is that candidates confuse transparent mode with NAT/Route mode, assuming that all FortiGate modes perform NAT or require IP addresses on each interface, when in fact transparent mode is purely Layer 2 and does not modify IP headers.
How to eliminate wrong answers
Option A is wrong because transparent mode does not perform NAT; NAT is a Layer 3 function used in NAT/Route mode. Option B is wrong because all interfaces in transparent mode must belong to the same subnet to maintain Layer 2 bridging. Option C is wrong because transparent mode requires only a single management IP (typically on the management interface or a dedicated VLAN), not an IP on each interface.
A FortiGate is set to NAT/Route mode. The admin wants traffic from internal users to the internet to use an IP address on the WAN interface for source NAT. Which configuration is required?
This is the correct method for source NAT in NAT/Route mode. By enabling NAT on the firewall policy from internal to WAN and specifying the outgoing interface as the WAN interface, the FortiGate translates the source IP of each internal packet to the address of that WAN interface (or the configured IP pool), allowing return traffic to be routed back and enabling internal hosts to access the Internet using public addressing.
Why this answer
In NAT/Route mode, source NAT (SNAT) is configured by enabling NAT on the firewall policy that governs traffic from the internal network to the WAN interface. When NAT is enabled on the policy and the outgoing interface is set to the WAN interface, FortiGate automatically translates the source IP of internal users to the primary IP address of that WAN interface (or a configured IP pool). This is the standard method for allowing internal users to access the internet with a public IP address.
How to eliminate wrong answers
Option A is wrong because transparent mode operates at Layer 2 without routing or NAT capabilities, which would prevent the required source NAT for internet access. Option B is wrong because policy routes control the path traffic takes based on routing criteria, not source NAT; they do not perform IP address translation. Option C is wrong because a virtual IP (VIP) is used for destination NAT (port forwarding), mapping an external IP/port to an internal server, not for source NAT of outbound traffic.
A FortiGate is deployed in NAT/Route mode. The administrator wants to create a policy that allows internal users to access the internet and also translates their private IP addresses to the public IP of the FortiGate's WAN interface. Which policy configuration is required?
Enabling NAT on the firewall policy is the explicit mechanism for source NAT in NAT/route mode. When checked, the FortiGate overwrites the source IP of matching outbound sessions with the IP address of the egress interface (or an IP pool if configured). This is the correct and minimal configuration to allow internal private hosts to initiate Internet-bound sessions.
Why this answer
In NAT/Route mode, enabling NAT on the firewall policy performs source NAT (SNAT) by default, translating the private source IP addresses of internal users to the public IP address of the FortiGate's WAN interface. This is the standard method for allowing internal users to access the internet while hiding their private addresses behind a single public IP.
Exam trap
The trap here is that candidates may confuse source NAT (enabled on the firewall policy) with destination NAT (configured via VIPs) or mistakenly think NAT is a routing feature, leading them to select options like static route with NAT or VIP configuration.
How to eliminate wrong answers
Option A is wrong because a virtual IP (VIP) is used for destination NAT (DNAT), translating incoming traffic's destination IP to an internal server, not for translating source IPs of outbound traffic. Option B is wrong because while setting the policy action to ACCEPT is necessary, SNAT is not a separate toggle in advanced options; NAT is enabled directly on the firewall policy, and there is no 'SNAT' checkbox distinct from the NAT option. Option C is wrong because static routes do not have a NAT feature; NAT is configured at the firewall policy level, not on routing entries.
A network administrator needs to configure a FortiGate to participate in SNMP monitoring. Which CLI command enables SNMP agent on the FortiGate?
The valid FortiGate CLI sequence to turn on SNMP is navigating to the `config system snmp` branch and running `set status enable`. This `config` block manages the SNMP agent hosted on the FortiGate; `status enable` is the required toggle to start the agent. Issuing these commands enables SNMP to listen on the management interface and allows you to then configure SNMP communities, hosts, and trap receivers within the same configuration section.
Why this answer
The correct command to enable the SNMP agent on a FortiGate is 'config system snmp' followed by 'set status enable'. This enters the SNMP configuration context and activates the SNMP agent, which is required for the FortiGate to respond to SNMP queries from management systems. Without this command, the SNMP service remains disabled regardless of other SNMP settings.
Exam trap
The trap here is that candidates often confuse the FortiGate CLI syntax with Cisco IOS commands, where 'snmp-server enable' or 'snmp-server community' are used, leading them to select a similarly phrased but incorrect option like 'enable snmp service'.
How to eliminate wrong answers
Option B is wrong because 'set system snmp enable' is not a valid FortiGate CLI command; the correct syntax requires entering the 'config system snmp' context first. Option C is wrong because 'set snmp agent enable' does not exist in FortiGate CLI; the agent is controlled via the 'status' parameter under 'config system snmp'. Option D is wrong because 'enable snmp service' is not a valid FortiGate command; SNMP is managed through the 'config system snmp' hierarchy, not a simple service enable command.
A FortiGate is configured with two ISPs (WAN1 and WAN2) and uses SD-WAN for load balancing. The administrator notices that traffic to a critical SaaS application is being sent over the slower link. What should the administrator do to ensure this traffic uses the faster link?
An SD-WAN rule configured with an application match for the SaaS traffic and a preferred member set to the faster link is the correct approach because SD-WAN rules can steer traffic based on Layer 7 application signatures and dynamic link performance metrics. The preferred member acts as a tie-breaker, forcing the traffic to use the specified interface as long as it meets the SD-WAN health-check SLA (latency, jitter, packet loss), while still allowing automatic failover to the backup link if the preferred link degrades. This preserves redundancy and ensures the SaaS application consistently uses the best-performing path.
Why this answer
SD-WAN rules allow you to define traffic steering policies based on application or destination, and setting a preferred member explicitly directs matching traffic to the faster link. This overrides the default load-balancing algorithm, ensuring critical SaaS traffic uses the optimal path without affecting other traffic.
Exam trap
The trap here is that candidates often confuse SD-WAN rules with policy-based routing, thinking PBR can achieve the same result, but PBR lacks SD-WAN's application awareness, SLA monitoring, and seamless failover integration.
How to eliminate wrong answers
Option B is wrong because removing the slower link from the SD-WAN interface would eliminate redundancy and failover capability, not solve the traffic steering issue. Option C is wrong because increasing bandwidth on the slower link does not change the SD-WAN load-balancing decision; the traffic would still be sent to that link based on the current algorithm. Option D is wrong because policy-based routing (PBR) is a static routing mechanism that does not integrate with SD-WAN's dynamic path selection, performance SLA monitoring, or application-based steering, and it can conflict with SD-WAN rules.
An administrator is configuring a FortiGate to send logs to a FortiAnalyzer. Which TWO of the following are required? (Choose two.)
Ensuring network connectivity between the FortiGate and FortiAnalyzer is the essential prerequisite because the FortiGate must be able to reach the FortiAnalyzer's IP address on the correct port (e.g., HTTPS 443, SSH 22, or Syslog 514). Without IP reachability, proper routing, and administrative access enabled on the interface, log transmission cannot occur regardless of any other configuration. This step verifies the underlying transport path and is often the root cause when logs fail to appear on the FortiAnalyzer.
Why this answer
Exam trap
The trap here is that candidates often think a firewall policy is needed to allow log traffic, but FortiGate's own traffic (including logs) is not subject to firewall policies; only transit traffic requires policies.
A network administrator needs to configure a FortiGate to allow administrative access from a specific management subnet only. Which configuration step should be taken?
Restricting administrative access to trusted hosts under System > Admin > Settings limits logins to the specified management subnet, satisfying the requirement that only that subnet may administer the FortiGate. Other admin settings do not enforce source-address restrictions.
Why this answer
The 'Trusted Hosts' feature under System > Admin > Settings allows you to restrict administrative access (HTTPS, SSH, Telnet, etc.) to specific source IP addresses or subnets. This is the intended method for limiting management access to a management subnet without affecting other traffic or interface configurations.
Exam trap
The trap here is that candidates often confuse local-in policies with trusted hosts, thinking that a local-in policy is the primary method for restricting management access, when in fact trusted hosts is the simpler and correct approach for source-based restriction.
How to eliminate wrong answers
Option A is wrong because a local-in policy filters traffic destined to the FortiGate itself, but it is typically used for advanced traffic shaping or rate limiting, not for restricting administrative access based on source subnet; using it for this purpose would be overly complex and not the standard practice. Option B is wrong because disabling administrative access on all interfaces except the management interface does not restrict access by source IP; it only limits which interfaces can be used for management, but any host on the management subnet could still access the FortiGate from that interface. Option C is wrong because an inbound firewall policy controls traffic passing through the FortiGate (forward traffic), not traffic destined to the FortiGate itself (local-in traffic); administrative access is governed by local-in policies or trusted hosts, not by standard firewall policies.
A FortiGate needs to resolve DNS names for outbound traffic. The administrator configures DNS servers under System > DNS. However, internal DNS queries for private domains fail. What additional configuration is required?
Creating a DNS database entry on the FortiGate is the correct solution because it statically maps the private domain to an IP address in the FortiGate's local DNS database. This allows the FortiGate to resolve that FQDN locally for its own outbound traffic, even when the upstream DNS servers have no record for the private domain. You can define this under Network > DNS as a static entry, and it takes precedence over normal DNS lookups.
Why this answer
When a FortiGate is configured with DNS servers under System > DNS, it can resolve public DNS names for outbound traffic. However, for private domains (e.g., internal.company.local), the FortiGate cannot resolve these because they are not registered in public DNS. Creating a DNS database entry for the private domain allows the FortiGate to act as an authoritative DNS server for that domain, providing local resolution for internal queries.
Exam trap
The trap here is that candidates often confuse the DNS proxy (which forwards queries) with the DNS database (which provides authoritative answers), leading them to select option D instead of A.
How to eliminate wrong answers
Option B is wrong because static routes are used for network-layer reachability, not for DNS resolution; DNS traffic will already follow the default route if the DNS server is reachable via the WAN. Option C is wrong because configuring a DNS server on the WAN interface is not a standard FortiGate feature; DNS servers are configured globally under System > DNS, and adding a DNS server on the WAN interface does not enable local domain resolution. Option D is wrong because enabling DNS proxy on the FortiGate only forwards DNS queries to configured DNS servers and does not provide local resolution for private domains; it is used for caching or filtering, not for authoritative responses.
A FortiGate administrator needs to backup the configuration to a remote TFTP server. Which CLI command should be used?
This is the correct command for backing up a FortiGate configuration to a TFTP server. The `execute backup` keyword pair is the standard CLI mechanism for exporting device state, and `config tftp` specifies the destination protocol and remote host. The filename argument is the remote file name to create on the TFTP server, followed by the server's IP, and this command will save the active configuration without altering the running system.
Why this answer
The 'execute backup config tftp' command is the proper CLI syntax in FortiOS for backing up the current configuration to a remote TFTP server. This command triggers an immediate backup operation, and the filename and TFTP server IP are required parameters to specify the destination.
Exam trap
The trap here is that candidates familiar with Cisco IOS may mistakenly choose 'copy config tftp' (Option A) or 'backup configuration to tftp' (Option D), but FortiOS uses the 'execute' command structure and specific syntax 'backup config tftp' for this operation.
How to eliminate wrong answers
Option A is wrong because 'copy config tftp' is not a valid FortiOS command; Fortinet uses the 'execute' prefix for operational commands, and 'copy' is used in Cisco IOS, not FortiOS. Option B is wrong because 'execute restore config tftp' is used to restore a configuration from a TFTP server, not to back up; the keyword 'restore' indicates the opposite direction of data flow. Option D is wrong because 'backup configuration to tftp' is not a valid CLI command in FortiOS; the correct syntax requires the 'execute' keyword and the order 'backup config tftp'.
A FortiGate has two WAN interfaces (wan1, wan2) configured with ECMP routes to the same destination. The administrator notices that traffic for a single session is being load-balanced across both links, causing performance issues. What should be configured to ensure sessions stick to one link?
Changing the ECMP load balancing method to 'source-ip-based' or 'source-dst-ip-based' forces the FortiGate to compute a deterministic hash from either the source IP alone or the source-destination IP pair for each session. All packets in a session share the same hash value, so they are consistently forwarded out the same WAN interface, preventing out-of-order delivery and dropped sessions. This is the built-in, scalable mechanism for per-session stickiness across equal-cost routes.
Why this answer
Changing the ECMP load balancing method to 'source-ip-based' or 'source-dst-ip-based' ensures that all packets belonging to the same session (identified by source IP or source-destination IP pair) are hashed to the same egress interface. This prevents a single session from being split across multiple WAN links, which can cause out-of-order packets and performance degradation. FortiGate’s ECMP hash algorithm uses the configured method to compute a hash value that deterministically selects the outgoing interface for each flow.
Exam trap
The trap here is that candidates often confuse ECMP load balancing methods with SD-WAN stickiness features, assuming SD-WAN is required for session persistence, when in fact ECMP’s hash algorithm can be tuned directly to achieve per-session stickiness.
How to eliminate wrong answers
Option A is wrong because policy routing (PBR) is used to override the routing table based on criteria like source/destination IP or port, but it does not inherently provide per-session stickiness; without careful configuration, PBR can still lead to asymmetric routing or session splitting. Option C is wrong because SD-WAN rules can enforce stickiness via session-based load balancing (e.g., 'source-ip-based' or 'session-based'), but the question specifically asks about ECMP routes, and SD-WAN is a separate feature that requires additional configuration and is not the direct fix for ECMP load balancing. Option D is wrong because disabling ECMP and using a single default route eliminates load balancing entirely, which is an overreaction and does not address the requirement to keep sessions on one link while still allowing load balancing across different sessions.
A FortiGate administrator needs to ensure that all DNS queries from internal clients are forwarded to a specific DNS server for security filtering. Which configuration should be applied?
Enabling DNS forwarding under Network > DNS configures the FortiGate to accept DNS queries sent to its interface IP and then forward them to the system DNS servers, which you set to the desired server. This makes the FortiGate act as a DNS proxy or forwarder, ensuring that all clients that use the FortiGate as their DNS server have their queries resolved by the specified upstream server. It also provides the benefit of caching DNS responses. This is the correct and intended feature for this scenario because it directly addresses the need to centralize and control DNS resolution.
Why this answer
DNS forwarding on FortiGate allows the device to act as a DNS relay, intercepting DNS queries from internal clients and forwarding them to a specified DNS server for security filtering. This is configured under Network > DNS by setting the system DNS to the desired server, which ensures all DNS traffic is redirected without requiring policy routing or firewall rule changes.
How to eliminate wrong answers
Option A is wrong because policy routing is used to steer traffic based on routing criteria (e.g., source/destination IP), not to transparently forward DNS queries; it would require complex rules and does not inherently provide DNS-specific relay functionality. Option B is wrong because creating a firewall policy to allow DNS traffic to an external server only permits traffic but does not force all internal DNS queries to that server; clients could still use other DNS servers if configured. Option D is wrong because a DNS database on FortiGate is used for hosting local DNS records (e.g., for internal resolution or split DNS), not for forwarding queries to an external security filtering server.
A FortiGate administrator needs to allow remote management of a FortiGate from the internet. Which administrative access protocols should be enabled on the WAN interface? (Choose the best single answer.)
HTTPS (port 443) provides an encrypted web-based management interface, and SSH (port 22) offers an encrypted command-line session, both ensuring that all administrative traffic remains confidential and tamper-proof. These are the recommended protocols for remote management because they protect login credentials and configuration changes from eavesdropping. FortiGate also allows these protocols to be enabled selectively per interface and with trusted-host restrictions, which is a security best practice.
Why this answer
HTTPS (port 443) and SSH (port 22) are the only secure administrative access protocols that provide encrypted communication for remote management over the internet. HTTP and Telnet transmit credentials and data in plaintext, making them unsuitable for WAN-facing interfaces. FortiGate best practices mandate disabling all insecure protocols on external interfaces and enabling only HTTPS and SSH for administrative access.
How to eliminate wrong answers
Option A is wrong because Ping (ICMP) is not an administrative access protocol—it is used for connectivity testing, and SNMP is a monitoring protocol, not a management interface for CLI/GUI access. Option B is wrong because HTTP and Telnet both transmit data in plaintext, exposing credentials and configuration to interception, and are strongly discouraged on any internet-facing interface. Option C is wrong because FTP and TFTP are file transfer protocols, not administrative access protocols; they do not provide a command-line or web-based management interface for the FortiGate itself.
Which THREE statements about FortiGate's 'config system global' settings are true? (Choose three.)
This is correct because 'admin-login-retry-limit' is a global security setting under config system global. It defines the maximum number of consecutive failed administrator login attempts (default is 3) before the source IP is locked out for a period (admin-lockout-duration). This helps mitigate brute-force attacks on management interfaces and applies across all administrators and access methods.
Why this answer
The 'admin-login-retry-lockout' setting (often referred to as 'admin-login-retry-limit' in older firmware) defines the number of consecutive failed administrative login attempts before the administrator account is locked out for a specified duration. This is a security feature to prevent brute-force attacks against the management interface.
Exam trap
The trap here is confusing global system settings with interface-specific or admin-specific settings, leading candidates to select 'trusthost' or 'allowaccess' which are configured in different contexts (admin and interface respectively).
A FortiGate is configured in active-active HA mode. An administrator notices that session failover is not working properly during a failover event. Which THREE configurations should be checked?
In active-active HA, the cluster must use a load-balancing algorithm to distribute new sessions among all units. Setting the load-balance method to 'load-balance' or 'weighted-load-balance' ensures that session distribution occurs, rather than having one unit handle all traffic. This is a foundational requirement for true active-active operation and is separate from session synchronization.
Why this answer
In active-active HA mode, the load-balance method must be set to 'load-balance' or 'weighted-load-balance' to ensure that session ownership is properly distributed and that session failover can occur. If the method is set to 'hub' or 'spoke', session synchronization and failover may not function as expected, as these modes are designed for different topologies.
Exam trap
The trap here is that candidates may assume session failover is solely dependent on enabling session synchronization, overlooking the critical requirement that the load-balance method must be correctly set for active-active mode to distribute and synchronize sessions properly.
Which TWO configuration changes can reduce the risk of unauthorized administrative access to a FortiGate?
Restricting administrative access to trusted hosts limits which source IP addresses can initiate management sessions to the FortiGate. By configuring an allowlist of management station IPs on each admin user or the administrative interface, you drastically reduce the attack surface and block brute-force attempts from the internet. This is a fundamental, highly effective hardening measure.
Why this answer
Restricting administrative access to trusted hosts (Option B) is a fundamental security best practice that limits the source IP addresses allowed to connect to the FortiGate management interface. By configuring a trusted host list, the FortiGate will only accept administrative sessions (e.g., HTTPS, SSH, or Telnet) from specified IP addresses or subnets, effectively blocking all unauthorized sources. This reduces the attack surface and prevents brute-force or credential-stuffing attacks from untrusted networks.
Exam trap
The trap here is that candidates often think disabling HTTPS entirely is a valid security measure, but the NSE4 exam expects you to recognize that HTTPS must remain enabled for secure remote GUI access, and that disabling both HTTP and HTTPS would render the web interface inaccessible, which is not a recommended security practice.
An administrator is configuring SNMP on a FortiGate for monitoring. Which THREE items are required for SNMPv3 configuration?
SNMPv3 adds USM security levels. Choosing authPriv enforces both authentication and encryption, while authNoPriv enforces authentication only. The security level is mandatory because it determines which credential fields must be supplied for the SNMPv3 user.
Why this answer
For SNMPv3 on a FortiGate, the security level (Option A) must be specified because SNMPv3 defines whether messages are authenticated only (authNoPriv) or both authenticated and encrypted (authPriv), which directly determines the security mechanisms applied to the user. Option B is required because SNMPv3 authentication uses a hash protocol such as SHA (or MD5) and privacy uses an encryption protocol such as AES (or DES); these protocol selections must be configured alongside the passwords to build the user's security parameters. Option E is required because SNMPv3 is user-based rather than community-based, so an SNMP user must be created with a username and authentication password (and, when authPriv is used, a privacy password) before the FortiGate can respond to SNMPv3 queries.
Option C is not required for basic SNMPv3 configuration because views are optional MIB access restrictions, not mandatory parameters for creating an SNMPv3 user. Option D is incorrect because community strings apply to SNMPv1 and SNMPv2c, not to SNMPv3, which replaces communities with users and security levels.
Exam trap
The trap here is that candidates often confuse SNMPv3 with SNMPv2c and incorrectly select the community string option, forgetting that SNMPv3 eliminates community strings in favor of user-based authentication and encryption.
A FortiGate administrator configures policy-based routing (PBR) to direct traffic from subnet 192.168.1.0/24 to the internet via ISP1. However, traffic from that subnet is still using the default route via ISP2. What is the most likely cause?
PBR evaluates its rule set before the routing table, so traffic only diverts when a rule's match criteria are satisfied. If the source address in the rule does not correctly identify 192.168.1.0/24, the rule is skipped and the packet falls through to the default route via ISP2.
Why this answer
Policy-based routing (PBR) on FortiGate overrides the routing table only when the traffic matches all configured criteria, including the source address. If the source address in the PBR rule does not match 192.168.1.0/24 exactly (e.g., a typo, wrong subnet mask, or missing entry), the traffic falls through to the default route via ISP2. This is the most likely cause because PBR rules are evaluated before the routing table, but only for matching traffic.
Exam trap
The trap here is that candidates often confuse PBR with static routing and assume the default route's administrative distance or priority can override PBR, but PBR is evaluated before the routing table and is not subject to route metrics.
How to eliminate wrong answers
Option B is wrong because administrative distance is a property of routes in the routing table, not of PBR rules; PBR operates before the routing table lookup and is not compared to administrative distance. Option C is wrong because PBR is fully supported on FortiGate, including in NSE4 scope, and is commonly used for multi-WAN setups. Option D is wrong because a higher priority in PBR would make the rule more likely to match, not less; the issue is that the rule is not matching at all, not that it is being overridden by the default route.
A network administrator is configuring a new FortiGate and needs to ensure that all traffic from the internal network to the internet is source NATed to the public IP address on port1. The default route points to port1. Which configuration step is required to achieve this?
In FortiGate, source NAT is performed by enabling the NAT option on the firewall policy that matches the internal-to-internet traffic. This setting causes the FortiGate to masquerade the source IP of each packet with the IP address assigned to the egress interface, which is typically the public IP of the WAN port. This is the standard and correct method for allowing internal users to share a single public IP address when accessing the internet.
Why this answer
Source NAT (SNAT) on a FortiGate is configured at the firewall policy level, not on the interface or via a static route. By enabling NAT on the firewall policy from the internal network to the internet, the FortiGate automatically translates the source IP of traffic egressing port1 to the interface's primary IP address (the public IP). This is the standard method for implementing source NAT in FortiOS, as defined in the FortiGate Administration Guide.
How to eliminate wrong answers
Option A is wrong because static routes in FortiOS do not have a NAT toggle; NAT is not a property of a route but of a firewall policy. Option C is wrong because interfaces in FortiOS do not have a 'NAT mode' setting; NAT is applied per policy, not per interface. Option D is wrong because an IP pool is only required when you need to translate to a specific IP address that is not the interface IP (e.g., for load balancing or PAT with a pool), but the question states the public IP is on port1, so the default interface NAT (enabled in the policy) suffices without an IP pool.
An administrator needs to configure a FortiGate to send logs to a FortiAnalyzer. Which two configurations are required? (Choose two.)
The FortiAnalyzer IP address is specified under config system central-management, in the fortianalyzer sub-table. This is the mandatory server address that the FortiGate uses to register and connect to the FortiAnalyzer unit. Without this IP, the FortiGate cannot establish the log upload session, even if log settings are enabled.
Why this answer
The FortiGate must be configured to know the FortiAnalyzer's IP address under `config system central-management` to establish the logging connection. Option B is correct because the `set log-fortianalyzer enable` command under `config log setting` activates the log transmission to the configured FortiAnalyzer. Without both, the FortiGate will not send logs to the FortiAnalyzer.
Exam trap
The trap here is that candidates mistakenly think a firewall policy is required to allow log traffic out, but FortiGate's log transmission to FortiAnalyzer uses the management VDOM and bypasses regular firewall policies.
After upgrading FortiGate firmware from 6.0 to 7.2, an administrator notices that a static route pointing to a next-hop IP 10.0.0.1 is no longer working. The route is present in the configuration but the FortiGate shows it as 'not active'. What is the MOST likely cause?
FortiGate static routes require the next-hop IP (gateway) to be on a directly connected subnet of the outgoing interface. If the gateway is not directly connected to any FortiGate interface, the route cannot be resolved via ARP or neighbor discovery, so FortiGate marks the route as inactive and does not install it in the forwarding table. This is the most common and specific cause of an inactive static route after a configuration change or upgrade that alters interface IPs or subnet masks.
Why this answer
In FortiOS 7.2, a static route is considered 'active' only if the next-hop IP is reachable via a directly connected interface. If the next-hop IP 10.0.0.1 is not on a directly connected subnet, the route will be present in the configuration but marked as 'not active'. This is a fundamental routing principle: the next hop must be directly reachable (i.e., the router must have an ARP entry for it) for the route to be installed in the routing table.
Exam trap
The trap here is that candidates often assume a static route will be active as long as the configuration is present and the remote gateway is reachable, but FortiGate (and most routers) require the next-hop IP to be directly connected for the route to be installed in the routing table.
How to eliminate wrong answers
Option A is wrong because the default administrative distance for static routes in FortiOS remains 10 (unchanged from 6.0 to 7.2), and administrative distance does not affect whether a route is 'active'—it only influences route selection among multiple routes to the same destination. Option B is wrong because the route is still present in the configuration, so it was not deleted during the upgrade; the issue is that it is not active, not that it is missing. Option D is wrong because the remote gateway being down would cause the route to be present but possibly inactive only if the next hop is directly connected; if the next hop is not directly connected, the route would be inactive regardless of the remote gateway's state.
Which protocol does FortiGate use to synchronize sessions between HA cluster members?
FGCP (FortiGate Clustering Protocol) is FortiGate's proprietary protocol designed to synchronize firewall sessions, configuration, and state information across HA cluster members. It continuously replicates session tables, including NAT mappings, TCP state, and UDP flows, over a dedicated heartbeat or HA link, enabling transparent failover with no session interruption. FGCP supports both active-passive and active-active HA modes and is the correct answer because it directly fulfills the requirement of session synchronization.
Why this answer
FortiGate uses the FortiGate Cluster Protocol (FGCP) to synchronize session tables, configuration, and state information between HA cluster members. FGCP is a proprietary protocol that ensures seamless failover by replicating session data in real time, allowing the backup unit to take over active sessions without interruption.
How to eliminate wrong answers
Option A is wrong because HSRP (Hot Standby Router Protocol) is a Cisco-proprietary protocol for router redundancy, not used by FortiGate for session synchronization. Option B is wrong because OSPF (Open Shortest Path First) is a dynamic routing protocol for exchanging routing information, not for synchronizing sessions in an HA cluster. Option C is wrong because VRRP (Virtual Router Redundancy Protocol) is an open-standard protocol for default gateway redundancy, but FortiGate does not use it for session synchronization; FGCP is the dedicated HA protocol.
Ready to test yourself?
Try a timed practice session using only Nse4 System Network questions.