CCNA Nse7 Troubleshooting Questions — Page 2 of 2

MCQhard

An administrator is troubleshooting a scenario where IPSec VPN tunnels between two FortiGates are flapping. The logs show Phase 1 is up but Phase 2 fails with 'no proposal chosen'. The remote FortiGate has multiple Phase 2 selectors configured. What is the most likely cause?

A.Mismatched Phase 2 proxy IDs (local/remote subnets).

B.Mismatched pre-shared keys.

C.Dead Peer Detection (DPD) settings are too aggressive.

D.Certificate validation failure.

AnswerA

The error 'no proposal chosen' is often due to mismatched proxy IDs in Phase 2.

Why this answer

The 'no proposal chosen' error during Phase 2, despite Phase 1 being up, indicates a mismatch in the IPsec security association (SA) parameters. Since the remote FortiGate has multiple Phase 2 selectors configured, the most likely cause is that the local and remote proxy IDs (local and remote subnets) do not match any of the configured selectors. Phase 2 negotiation uses these proxy IDs to define which traffic should be encrypted; if they don't align, the IKE SA cannot be established.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 failures, assuming any 'no proposal chosen' error is due to Phase 1 misconfigurations like PSK or certificates, when in fact Phase 1 is already up, isolating the issue to Phase 2 proxy ID mismatches.

How to eliminate wrong answers

Option B is wrong because mismatched pre-shared keys would cause Phase 1 to fail, not Phase 2; Phase 1 is already up in this scenario. Option C is wrong because aggressive Dead Peer Detection (DPD) settings can cause tunnels to flap (go up and down), but they do not produce a 'no proposal chosen' error; that error is specific to Phase 2 proposal mismatches. Option D is wrong because certificate validation failure would also prevent Phase 1 from completing, as certificates are used during IKE authentication in Phase 1, not Phase 2.

Practice this question →

MCQmedium

A FortiGate administrator notices that after upgrading the firmware, some BGP sessions to a service provider are flapping. The administrator runs 'diagnose ip router bgp all' and sees that the BGP neighbor state is Active. What is the MOST likely cause of this issue?

A.A configuration checksum mismatch between the two peers

B.The BGP hold timer has expired

C.The BGP neighbor is not reachable due to a routing issue

D.The BGP password is incorrect

AnswerA

Firmware upgrades can introduce new defaults that change the update message, causing checksum mismatch and flapping.

Why this answer

After a firmware upgrade, a BGP session stuck in the Active state is most commonly caused by a configuration checksum mismatch between the two peers. FortiGate uses a BGP configuration checksum to ensure that both sides have identical BGP configurations; if the checksums do not match after an upgrade (e.g., due to a change in default parameters or a new feature), the session will not establish and will remain in Active. This is a known behavior in FortiOS where the checksum is compared during the BGP open message exchange, and a mismatch prevents the session from moving to Established.

Exam trap

The trap here is that candidates often associate the Active state with reachability issues (Option C) or authentication failures (Option D), but in FortiGate, the Active state specifically indicates that the TCP connection is up and the BGP open message is being exchanged, making a configuration mismatch the most likely cause after an upgrade.

How to eliminate wrong answers

Option B is wrong because a hold timer expiry would cause the session to transition to Idle, not Active, as the hold timer is reset upon receiving a keepalive or update; an expired hold timer indicates a failure to receive messages, leading to a teardown. Option C is wrong because if the BGP neighbor is not reachable due to a routing issue, the session would typically remain in Idle (not Active) because the TCP connection cannot be initiated; Active state implies the TCP connection is being attempted but the BGP open message negotiation is failing. Option D is wrong because an incorrect BGP password (MD5 authentication) would cause the TCP connection to fail entirely, resulting in the session staying in Idle, not Active, as the TCP three-way handshake would not complete.

Practice this question →

MCQmedium

A BGP session between FortiGate and a neighbor is in 'Active' state. The administrator has verified IP connectivity and that the neighbor IP is reachable. What is the MOST likely cause?

A.The firewall policy is blocking BGP port 179

B.The remote AS number is misconfigured on either side

C.The BGP hold timer is set too high

D.The BGP network statement is missing

AnswerB

A mismatch in the remote AS number prevents BGP from establishing the session, resulting in 'Active' state.

Why this answer

The BGP 'Active' state indicates that the router is actively trying to initiate a TCP connection to the neighbor but has not yet received a successful response. Since IP connectivity is verified, the most likely cause is a mismatch in the remote AS number configuration. BGP uses the AS number in the OPEN message to validate the peer; if the configured remote AS on one side does not match the local AS on the other, the neighbor will reject the connection, causing the session to remain in Active state.

Exam trap

The trap here is that candidates often confuse the BGP 'Active' state with a firewall or ACL blocking TCP port 179, but the question explicitly states IP connectivity is verified, and the Active state indicates the TCP handshake is at least partially progressing, shifting the focus to AS number mismatch as the primary cause of session failure.

How to eliminate wrong answers

Option A is wrong because if a firewall policy were blocking BGP port 179, the TCP connection would fail to establish, typically resulting in an 'Idle' or 'Connect' state, not 'Active', and the administrator has already verified IP connectivity. Option C is wrong because a hold timer set too high would not prevent the session from leaving the Active state; it only affects how long the router waits for keepalives after the session is established. Option D is wrong because the BGP network statement is used to advertise prefixes into BGP, not to establish the BGP peering session; missing network statements would not prevent the TCP connection or OPEN message exchange.

Practice this question →

MCQeasy

A FortiGate is experiencing high CPU usage. The administrator runs 'diagnose sys top' and sees that the process 'ipsengine' is using the most CPU. What is the most likely cause?

A.The firewall is experiencing a memory leak.

B.A large volume of traffic is being inspected by IPS, possibly due to a DoS attack.

C.The antivirus engine is scanning large files.

D.There is a routing loop causing packet bouncing.

AnswerB

IPS engine uses CPU for deep packet inspection; high volume or many signatures increases load.

Why this answer

The ipsengine process handles Intrusion Prevention System (IPS) inspection. High CPU usage by ipsengine typically indicates that the FortiGate is processing a large volume of traffic through IPS signatures, which is computationally intensive. This is often triggered by a DoS attack or a sudden surge in traffic that requires deep packet inspection, overwhelming the CPU.

Exam trap

The trap here is that candidates may confuse ipsengine with avengine or assume high CPU is always due to a memory leak, but the specific process name directly points to IPS inspection overload.

How to eliminate wrong answers

Option A is wrong because a memory leak would manifest as steadily increasing memory consumption over time, not as high CPU usage by ipsengine; the 'diagnose sys top' output shows CPU usage, not memory. Option C is wrong because antivirus scanning is handled by the 'avengine' process, not 'ipsengine'; the question explicitly states ipsengine is the culprit. Option D is wrong because a routing loop causes packet bouncing and high CPU due to routing table lookups (handled by the kernel or 'fwd' process), not by the IPS engine, which inspects application-layer traffic.

Practice this question →

MCQeasy

An administrator needs to monitor FortiGate session count and CPU usage over time using FortiAnalyzer. Which log type should be configured for this?

A.Security logs

B.Performance logs

C.Event logs

D.Traffic logs

AnswerB

Correct. Performance logs provide periodic CPU, memory, and session data.

Why this answer

Performance logs are specifically designed to capture system resource utilization metrics such as CPU usage, memory consumption, and session counts over time. FortiAnalyzer uses these logs to generate historical performance graphs and reports, enabling administrators to monitor trends and identify resource bottlenecks. Security logs, event logs, and traffic logs do not contain the periodic, time-series resource data required for this monitoring purpose.

Exam trap

The trap here is that candidates often confuse 'traffic logs' with performance monitoring because traffic logs show session details, but they do not provide the aggregated, time-series CPU and session count data that performance logs uniquely offer.

How to eliminate wrong answers

Option A is wrong because security logs record security-related events like intrusion prevention, antivirus, and web filtering actions, not system resource metrics like CPU usage or session counts. Option C is wrong because event logs capture system events such as administrative logins, configuration changes, and HA events, but they do not include periodic performance data for CPU or session monitoring. Option D is wrong because traffic logs contain details about individual network sessions (source/destination IP, ports, bytes transferred) and are not designed to report aggregate system resource utilization over time.

Practice this question →

MCQmedium

An HA cluster (active-passive) is configured. The administrator wants to perform a failover test without causing service disruption. Which command should be used?

A.diagnose ha reset-uptime

B.execute shutdown on the primary

C.execute ha synchronize

D.execute ha failover

AnswerD

This command triggers a graceful failover, making the primary become secondary.

Why this answer

The 'execute ha failover' command triggers a controlled failover in an active-passive HA cluster, forcing the standby unit to become active without physically shutting down or rebooting the primary unit. This allows the administrator to test failover behavior while minimizing service disruption, as the cluster transitions gracefully and sessions are synchronized if session-pickup is enabled.

Exam trap

The trap here is that candidates often confuse 'execute ha failover' with 'execute shutdown' or 'diagnose ha reset-uptime', mistakenly thinking that any HA-related command will trigger a failover, or that a physical shutdown is the only way to test failover behavior.

How to eliminate wrong answers

Option A is wrong because 'diagnose ha reset-uptime' resets the HA uptime statistics counters and does not initiate any failover or role change. Option B is wrong because 'execute shutdown on the primary' will power off the primary unit, causing an uncontrolled failover that may drop active sessions and disrupt services, which contradicts the goal of testing without service disruption. Option C is wrong because 'execute ha synchronize' forces a manual configuration and session synchronization from the primary to the standby, but it does not trigger a role switch or failover.

Practice this question →

MCQmedium

A FortiGate administrator runs 'diagnose debug application sslvpn -1' and sees repeated messages: 'SSL VPN tunnel error: no response from client'. What is the most likely cause?

A.The authentication server is unreachable

B.The tunnel mode is configured for web mode instead of tunnel mode

C.The client cannot reach the FortiGate's SSL VPN IP or port

D.The SSL VPN certificate has expired

AnswerC

No response from client suggests a connectivity problem between client and FortiGate.

Why this answer

The 'no response from client' error in the SSL VPN debug output indicates that the FortiGate sent a tunnel setup request to the client but did not receive the expected reply. This typically happens when the client cannot reach the FortiGate's SSL VPN IP or port (default 443), often due to network connectivity issues, firewall rules blocking the port, or NAT problems. The error is specific to the transport layer between client and FortiGate, not authentication or configuration mismatches.

Exam trap

The trap here is that candidates confuse client-side connectivity issues with authentication or certificate problems, but the debug message 'no response from client' specifically points to a network reachability problem after the SSL session is established, not before.

How to eliminate wrong answers

Option A is wrong because an unreachable authentication server would generate authentication failure or timeout messages (e.g., 'auth timeout' or 'radius no response'), not 'no response from client' which is a client-side connectivity issue. Option B is wrong because tunnel mode vs web mode is a configuration setting on the FortiGate; if tunnel mode were misconfigured, the client would either fail to connect entirely or show a different error like 'tunnel mode mismatch', not a lack of response from the client. Option D is wrong because an expired SSL VPN certificate would cause SSL handshake failures or certificate validation errors (e.g., 'certificate verify failed' or 'SSL error'), not a 'no response from client' message which occurs after the SSL session is established.

Practice this question →

MCQmedium

An administrator observes that traffic from a specific subnet is being dropped by the FortiGate. The session table shows the sessions with 'proto_state=01' and 'expire=0'. What does this indicate?

A.The sessions have expired and are being cleaned up

B.The antivirus scanning is causing a delay

C.The sessions are being offloaded to the NPU

D.The firewall policy is blocking the traffic

AnswerA

Expire=0 means the session has timed out.

Why this answer

In FortiGate session tables, 'proto_state=01' indicates a TCP session in the SYN-SENT state (the first step of the three-way handshake), and 'expire=0' means the session has no remaining time-to-live. This combination typically occurs when the session timed out or was reset before completing the handshake, and the entry is now being cleaned up by the session table garbage collector. Option A is correct because these are stale sessions that have expired and are in the process of removal.

Exam trap

The trap here is that candidates may misinterpret 'proto_state=01' as a normal established session or assume 'expire=0' means the session is actively being blocked, rather than recognizing it as a timed-out SYN-SENT session being cleaned up.

How to eliminate wrong answers

Option B is wrong because antivirus scanning delays would not cause 'expire=0' or 'proto_state=01'; AV scanning affects data processing but does not directly set session expiration to zero or alter the TCP state to SYN-SENT. Option C is wrong because NPU offloading is indicated by flags like 'offload' or 'npu' in the session table, not by 'proto_state=01' and 'expire=0'; offloaded sessions maintain normal state and expiration values. Option D is wrong because a firewall policy blocking traffic would result in denied sessions that may not appear in the session table at all, or would show a different state (e.g., 'proto_state=00' or 'deny'), not a SYN-SENT state with zero expiration.

Practice this question →

MCQmedium

A customer reports intermittent connectivity issues between two internal subnets separated by a FortiGate firewall. The traffic is allowed by the policy, but users experience timeouts during peak hours. Which troubleshooting step should you take first?

A.Run a packet sniffer on the FortiGate to capture traffic between the subnets.

B.Check the session table for session limits and session congestion.

C.Disable hardware acceleration on the FortiGate.

D.Configure SNAT on the policy to translate the source IP.

AnswerB

Peak hour timeouts often indicate session table exhaustion; checking this is the quickest diagnostic step.

Why this answer

Intermittent connectivity during peak hours strongly suggests session table exhaustion or session congestion. The FortiGate's session table has a finite capacity, and when it fills up, new sessions are dropped, causing timeouts. Checking the session table for limits and congestion is the fastest, least intrusive first step to confirm whether the firewall is running out of session resources before performing more complex diagnostics.

Exam trap

The trap here is that candidates often jump to packet capture or hardware acceleration as the first step, overlooking the session table as the most common cause of intermittent peak-hour connectivity issues.

How to eliminate wrong answers

Option A is wrong because running a packet sniffer is a reactive, resource-intensive step that should be taken only after ruling out session table issues; it does not directly reveal session limits or congestion. Option C is wrong because disabling hardware acceleration is a drastic step that can degrade performance and is only warranted if a specific hardware offload bug is suspected, not as a first troubleshooting step for peak-hour timeouts. Option D is wrong because configuring SNAT does not resolve session table exhaustion; it changes the source IP but does not increase the session table capacity or address congestion.

Practice this question →

Multi-Selectmedium

An administrator notices that some traffic through the FortiGate is not being inspected by the application control profile. Which TWO reasons could explain this? (Choose two.)

Select 2 answers

A.The inspection mode is set to proxy-based

B.The application control signatures are outdated

C.The FortiGate has high memory usage

D.The application control profile is disabled

E.Traffic matches a different policy without the application control profile

AnswersD, E

Incorrect. If the profile is disabled globally, no traffic would be inspected; but the question specifies 'some traffic' not being inspected, which points to a per-policy issue.

Why this answer

The two valid reasons are that traffic may match a different policy without the application control profile (E), and that the application control profile may be disabled on the policy the traffic hits (D). Option A is incorrect because proxy-based inspection is required for application control; setting it to proxy-based enables inspection. Option B is incorrect because outdated signatures still allow inspection, albeit with reduced effectiveness.

Option C is incorrect because high memory usage may impact performance but does not entirely prevent inspection.

Exam trap

Candidates often confuse proxy-based inspection with disabling application control. In reality, proxy-based mode is necessary for deep application control inspection. The real reason for missed inspection is typically policy misconfiguration—traffic hitting a policy without the profile applied.

Practice this question →

MCQhard

An administrator configures an HA cluster with two FortiGates using an FGCP active-passive configuration. After a failover, the new primary FortiGate shows all sessions are lost. The administrator has 'sync session' enabled in the HA configuration. What is the MOST likely reason sessions were not synchronized?

A.The HA heartbeat interface is overloaded, causing session synchronization packets to be dropped

B.The passive unit's 'session-pickup' setting is disabled

C.The 'failover-monitor' interface is down on the active unit, preventing session sync

D.The 'session-ttl' setting is set to zero on the active unit

AnswerA

Session synchronization uses the heartbeat link; if it is overloaded or has high latency, session sync packets can be lost, leading to session loss after failover.

Why this answer

In an FGCP active-passive cluster, session synchronization relies on the heartbeat interface to transmit session-pickup packets from the active unit to the passive unit. If the heartbeat interface is overloaded (e.g., due to excessive traffic or misconfigured bandwidth), these packets can be dropped, causing the passive unit to lack the session table after a failover. The fact that 'sync session' is enabled but sessions are still lost points directly to a transport issue on the heartbeat link, not a configuration or policy problem.

Exam trap

The trap here is that candidates often assume 'sync session' alone guarantees session pickup, overlooking that the heartbeat interface must have sufficient capacity to carry the synchronization traffic without drops.

How to eliminate wrong answers

Option B is wrong because 'session-pickup' is a global setting that must be enabled on both units for session synchronization to work; if it were disabled, sessions would never sync, but the question states 'sync session' is enabled, implying the feature is active. Option C is wrong because the 'failover-monitor' interface monitors link status for triggering failover, not for session synchronization; a down failover-monitor interface would cause a failover event, not prevent session sync packets from being sent. Option D is wrong because 'session-ttl' controls the timeout for idle sessions, not the synchronization process; setting it to zero would cause sessions to expire immediately, but the symptom here is that sessions are lost after failover, not that they expire prematurely.

Practice this question →

Multi-Selecthard

An organization uses FortiGate with OSPF and BGP. Recently, routes from BGP are not being preferred over OSPF routes, causing suboptimal routing. The administrator wants to ensure BGP routes are preferred. Which two actions can achieve this? (Choose two.)

Select 2 answers

A.Decrease the administrative distance of BGP routes to 5.

B.Configure route-map to set metric to 1 on BGP routes.

C.Increase the administrative distance of OSPF routes to 120.

D.Set a higher weight on BGP routes for the prefixes.

AnswersA, C

Decreasing BGP AD to 5 makes it more preferred over OSPF AD 110.

Why this answer

Decreasing the administrative distance (AD) of BGP routes to 5 makes them more trustworthy than OSPF routes (default AD 110). Since a lower AD is preferred, BGP routes will be installed in the routing table over OSPF routes, ensuring BGP is preferred for forwarding decisions.

Exam trap

The trap here is that candidates confuse inter-protocol route selection (governed by administrative distance) with intra-protocol BGP path selection attributes (like weight, local preference, or metric), leading them to incorrectly choose options that modify BGP-specific attributes that have no effect on OSPF vs. BGP preference.

Practice this question →

MCQhard

An SD-WAN rule has two members: port1 (SLA target latency < 10ms) and port2 (SLA target latency < 20ms). The administrator runs 'diagnose sys sdwan sla-check' and sees that both members meet SLA. However, all traffic is going through port2. What is the MOST likely reason?

A.The SD-WAN strategy is set to 'load balancing' and the load balancing algorithm is 'spillover'

B.The SD-WAN strategy is set to 'manual'

C.The SD-WAN rule is configured with 'set service' that does not match the traffic

D.The 'update-static-route' is disabled on the SD-WAN

AnswerC

If the rule's service (application) does not match the traffic, the rule is not applied, and traffic uses the default route or another rule.

Why this answer

If the SD-WAN rule has a 'set service' filter that does not match the traffic being tested (e.g., it only applies to HTTP traffic while the test traffic is ICMP or UDP), the rule will not be used for that traffic, causing the traffic to fall through to a default route or another rule that uses port2. Even though both members meet SLA, the traffic is not matched by the rule, so the SD-WAN load-balancing or strategy logic never applies.

Exam trap

The trap here is that candidates assume SLA compliance alone determines traffic distribution, overlooking that the SD-WAN rule must first match the traffic via service filters before any strategy or load-balancing logic applies.

How to eliminate wrong answers

Option A is wrong because 'spillover' algorithm would send traffic to port1 until its bandwidth threshold is exceeded, then spill to port2; with both members meeting SLA, traffic would initially go to port1, not exclusively port2. Option B is wrong because 'manual' strategy requires explicit interface selection per session or policy, and if both members meet SLA, the administrator would have to manually force port2; the question states all traffic goes through port2 without manual intervention, which contradicts manual mode. Option D is wrong because 'update-static-route' being disabled only prevents the SD-WAN from dynamically updating static routes based on SLA status; it does not cause traffic to bypass a rule or force all traffic to a specific member.

Practice this question →

Multi-Selectmedium

An administrator is troubleshooting an IPsec VPN tunnel that fails to establish Phase 1. The debug output shows 'no acceptable proposal'. Which TWO configuration parameters should be checked to resolve this issue?

Select 2 answers

A.Encryption algorithm

B.Diffie-Hellman group

C.IKE version

D.Pre-shared key

E.Local and remote subnets

AnswersA, B

Mismatched encryption algorithms cause proposal failure.

Why this answer

The 'no acceptable proposal' error indicates that the two IPsec peers cannot agree on a Phase 1 proposal. The encryption algorithm and Diffie-Hellman group are both mandatory parameters in the IKE proposal that must match exactly between peers. If either parameter differs, the negotiation fails with this error.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 parameters, incorrectly selecting local/remote subnets (a Phase 2 setting) when the error occurs during Phase 1 negotiation.

Practice this question →

MCQhard

A company runs a FortiGate 600E in NAT/Route mode. They have a site-to-site VPN to a partner using route-based VPN with BGP. Recently, they added a new subnet 192.168.50.0/24 behind the FortiGate. The BGP session is up, and the route is being advertised to the partner. However, traffic from the partner to the new subnet fails. The FortiGate's routing table shows the route to 192.168.50.0/24 is present via the VPN interface. Firewall policies allow the traffic. A packet capture on the FortiGate's internal interface shows the partner's traffic arriving but no SYN-ACK being sent back. The FortiGate's session table shows sessions in 'SYN_RECV' state for the new subnet. What is the most likely cause?

A.The reverse path forwarding (RPF) check is dropping the incoming SYN.

B.The firewall policy is not configured with the correct source interface.

C.The BGP route advertisement is being filtered by a route map on the partner side.

D.The Phase 2 selector for the VPN does not include the new subnet, so the FortiGate does not encrypt the reply traffic.

AnswerD

The SYN is received but the return traffic cannot be encrypted because the Phase 2 selector does not match the new subnet, causing asymmetric routing.

Why this answer

In a route-based VPN, the Phase 2 selectors define which traffic is allowed to be encrypted and decrypted. Even though BGP advertises the new subnet 192.168.50.0/24, if the Phase 2 selector on either side does not include this subnet, the FortiGate will not encrypt the reply traffic. The packet capture shows the SYN arriving, but no SYN-ACK is sent because the FortiGate cannot find a matching Phase 2 proposal to encrypt the response, causing the session to remain in SYN_RECV state.

Exam trap

The trap here is that candidates assume BGP route advertisement alone ensures traffic flow, overlooking that IPsec Phase 2 selectors must explicitly match the new subnet for encryption to occur.

How to eliminate wrong answers

Option A is wrong because the RPF check would drop the incoming SYN packet itself, but the packet capture shows the SYN arriving successfully, and the session table shows SYN_RECV, indicating the SYN was accepted and a SYN-ACK should be generated. Option B is wrong because the firewall policy is already allowing the traffic (as stated), and the source interface is correctly set to the VPN interface; otherwise, the SYN would not have been processed and the session would not be in SYN_RECV. Option C is wrong because the BGP route is being advertised and the BGP session is up; if a route map were filtering the advertisement, the partner would not have the route to 192.168.50.0/24, but the FortiGate's routing table shows the route is present, and the partner's traffic is reaching the FortiGate.

Practice this question →

MCQmedium

An administrator runs 'diagnose debug application ssl-helper -1' and sees that sessions to certain HTTPS sites are being terminated by the FortiGate. What is the MOST likely cause?

A.The FortiGate's certificate authority (CA) certificate has expired, causing SSL inspection to fail

B.The antivirus profile is blocking the HTTPS connections due to a virus signature match

C.The FortiGate is performing TCP RST injection due to a mismatch in the SSL/TLS handshake as part of deep inspection

D.The SSL deep inspection policy is set to 'certificate-inspection' which blocks sessions with mismatched certificates

AnswerC

The ssl-helper process performs deep inspection by injecting RST packets when the handshake is invalid or certificate errors occur, causing session termination.

Why this answer

The 'diagnose debug application ssl-helper -1' command shows SSL helper events, including TCP RST injection. When deep inspection is enabled and the FortiGate cannot complete the SSL/TLS handshake with the server (e.g., due to cipher mismatch, certificate validation failure, or unsupported protocol version), it sends a TCP RST to both the client and server to terminate the session. This is the most direct cause of sessions being terminated as observed in the debug output.

Exam trap

The trap here is that candidates confuse 'certificate-inspection' with 'deep inspection' and assume certificate mismatches cause TCP RSTs, but in certificate-inspection mode the FortiGate does not terminate the SSL handshake—it only inspects the certificate without decrypting, so no RST injection occurs.

How to eliminate wrong answers

Option A is wrong because an expired CA certificate on the FortiGate would cause SSL inspection to fail with a certificate validation error, but the FortiGate would typically block the session with a replacement page or drop it, not perform TCP RST injection as seen in ssl-helper debug. Option B is wrong because antivirus blocking would be logged in antivirus or proxy logs, not in ssl-helper debug, and would result in a block page or session drop, not a TCP RST from the SSL helper. Option D is wrong because 'certificate-inspection' mode does not perform deep inspection; it only checks the server certificate without decrypting traffic, so it would not cause TCP RST injection due to handshake mismatches—that behavior is specific to deep inspection (full SSL inspection).

Practice this question →

MCQeasy

A FortiGate administrator sees the following kernel log: 'kernel: [pid 1234] received packet with unknown or unsupported protocol 0x0800 on interface port1, drop'. What does this log indicate?

A.The packet is an ARP request that failed.

B.The packet has an invalid MAC address.

C.The interface is not configured with an IP address or is in the wrong VDOM.

D.The packet has IP options set that are not supported.

AnswerC

The kernel drops packets when the interface is not configured to handle that protocol.

Why this answer

The kernel log indicates that the interface port1 received an Ethernet frame with EtherType 0x0800 (IPv4) but the FortiGate dropped it because the interface is either not configured with an IP address or is bound to the wrong VDOM. Without an IP address or proper VDOM assignment, the kernel cannot process the packet at Layer 3, so it logs the packet as having an 'unknown or unsupported protocol' even though 0x0800 is standard IPv4.

Exam trap

The trap here is that candidates see 'unknown or unsupported protocol 0x0800' and assume it refers to an exotic or malformed protocol, when in fact 0x0800 is standard IPv4 and the issue is a missing IP address or VDOM assignment on the interface.

How to eliminate wrong answers

Option A is wrong because ARP requests use EtherType 0x0806, not 0x0800, and the log specifically mentions protocol 0x0800 (IPv4). Option B is wrong because invalid MAC addresses would generate a different log entry related to MAC filtering or source address validation, not a protocol drop. Option D is wrong because IP options are handled at a higher layer within the IP stack, and the kernel drop occurs before any IP header parsing; the log indicates the interface itself does not recognize the protocol, not that options are unsupported.

Practice this question →

MCQhard

A BGP peering between two FortiGates is not establishing. The administrator runs 'get router info bgp neighbor' and sees that the neighbor state is 'Idle' and the BGP configuration appears correct. What should the administrator check next?

A.Run 'diagnose ip router bgp all enable' to enable debug

B.Check the BGP AS number configuration

C.Verify that the BGP neighbor IP is reachable via the routing table

D.Increase the BGP timers

AnswerC

If the neighbor is unreachable, BGP stays in Idle state.

Why this answer

When a BGP neighbor is stuck in the 'Idle' state, it typically indicates that BGP cannot initiate the TCP connection to the neighbor. The most common cause is that the neighbor IP address is not reachable via the routing table. Even if the BGP configuration (AS number, neighbor IP) is correct, BGP will remain Idle until it can successfully open a TCP session on port 179.

Therefore, verifying IP reachability (e.g., with 'ping' or checking the routing table) is the logical next step.

Exam trap

The trap here is that candidates often jump to debugging or assume a configuration error (like AS number mismatch) when the neighbor state is Idle, but the most fundamental cause—IP reachability—is frequently overlooked.

How to eliminate wrong answers

Option A is wrong because enabling BGP debug ('diagnose ip router bgp all enable') is a troubleshooting step that should be taken after verifying basic connectivity; it generates excessive output and is not the first check for an Idle state. Option B is wrong because the question states that the BGP configuration appears correct, so checking the AS number again is redundant and unlikely to resolve the issue. Option D is wrong because increasing BGP timers (keepalive/hold) only affects established sessions or session stability, not the initial TCP connection establishment; it will not move a session out of Idle.

Practice this question →

MCQmedium

During a failover test in an HA cluster, the primary FortiGate fails over to the secondary. After failover, some existing TCP sessions are dropped. What is the MOST likely reason?

A.The failover caused a routing change

B.The session TTL expired during failover

C.The HA mode is active-passive

D.Session pickup is not enabled on the HA cluster

AnswerD

Without session pickup, TCP sessions are lost on failover.

Why this answer

In an HA cluster, session pickup (also known as session synchronization) is responsible for replicating session tables from the primary FortiGate to the secondary. When failover occurs, if session pickup is not enabled, the secondary FortiGate has no knowledge of existing TCP sessions, causing them to be dropped. This is the most likely reason because the secondary device cannot forward traffic for sessions it does not recognize, even if the network topology remains unchanged.

Exam trap

The trap here is that candidates often assume active-passive HA always drops sessions or that routing changes are the default cause, but Fortinet specifically tests that session pickup must be explicitly enabled to preserve TCP sessions during failover.

How to eliminate wrong answers

Option A is wrong because a routing change during failover is not inherent to HA failover itself; FortiGate HA typically uses virtual MAC addresses and floating IPs to maintain consistent routing, so sessions are not dropped due to routing changes unless the network is misconfigured. Option B is wrong because session TTL (time-to-live) expiration is not a typical cause during a controlled failover; session TTLs are usually long enough to survive the brief failover transition, and the issue is specifically about session state not being transferred. Option C is wrong because active-passive HA mode does not inherently cause session drops; in fact, active-passive HA with session pickup enabled can maintain sessions, and the mode alone is not the reason for dropped sessions—the missing feature is session synchronization.

Practice this question →

MCQmedium

An administrator is troubleshooting an IPsec VPN tunnel that fails to establish. The administrator runs 'diagnose vpn ike log' and sees the message 'no matching proposal found'. What is the MOST likely cause?

A.The remote gateway's IP address is unreachable

B.The Phase 1 parameters (encryption, authentication, DH group) do not match between peers

C.The firewall policy allowing the VPN traffic is missing or has the wrong interface

D.The pre-shared key is incorrect on one side

AnswerB

'No matching proposal found' indicates that during IKE negotiation, the two peers could not agree on a common set of Phase 1 parameters.

Why this answer

The 'no matching proposal found' message in the IKE log indicates that the FortiGate received a proposal from the remote peer during Phase 1 negotiation, but none of the offered combinations of encryption, authentication, and Diffie-Hellman group matched its own configured Phase 1 parameters. Since IKE uses a proposal/response exchange, a mismatch in any of these attributes causes the negotiation to fail before any further steps, such as authentication or policy lookup, can occur.

Exam trap

The trap here is that candidates often confuse Phase 1 proposal mismatches with pre-shared key errors or firewall policy issues, but the IKE log message 'no matching proposal found' is a specific RFC 2409 notification that occurs before authentication, so only mismatched encryption, hash, or DH group parameters can cause it.

How to eliminate wrong answers

Option A is wrong because an unreachable remote gateway would generate a timeout or 'no response' error, not a proposal mismatch message. Option C is wrong because firewall policies are evaluated only after Phase 1 and Phase 2 are successfully established; a missing or misconfigured policy would cause traffic to be dropped after the tunnel is up, not prevent IKE negotiation. Option D is wrong because an incorrect pre-shared key would cause an authentication failure during Phase 1 after the proposal is accepted, resulting in a message like 'authentication failed' or 'invalid payload', not 'no matching proposal found'.

Practice this question →

Multi-Selecthard

A FortiGate administrator is investigating a slow network issue. The 'diagnose sys session stat' shows a high number of sessions. Which THREE commands can help identify the source of the high session count?

Select 3 answers

A.diagnose sys session list | grep <policy_id>

B.diagnose sys session filter src <IP>

C.diagnose sys session top-talkers

D.diagnose sys session stat

E.diagnose netlink interface list

AnswersA, B, C

Counts sessions per policy to see which policy is most used.

Why this answer

'diagnose sys session list | grep <policy_id>' filters the session list to show only sessions matching a specific firewall policy ID. This allows the administrator to identify which policy is handling the most sessions, helping to pinpoint the source of high session counts by correlating traffic patterns with policy usage.

Exam trap

The trap here is that candidates may think 'diagnose sys session stat' (Option D) provides source-level detail, but it only shows aggregate counters, not per-source or per-policy breakdowns, making it useless for identifying the specific source of high session counts.

Practice this question →

MCQmedium

When testing HA failover, you manually switch the primary unit to standby. The secondary unit becomes primary but does not take over the IP address of the virtual cluster. What is the MOST likely cause?

A.Session pickup is not enabled

B.The HA interface monitoring is disabled

C.The HA mode is set to 'load-balance' without a virtual cluster IP

D.The HA cluster is in split-brain

AnswerC

In load-balance mode, the virtual IP is not automatically taken over; it must be configured.

Why this answer

In an HA cluster configured in load-balance mode, the virtual cluster IP address is not automatically transferred during failover unless a virtual cluster IP is explicitly configured. When the primary unit is manually switched to standby, the secondary unit becomes primary but lacks the virtual cluster IP assignment, so it cannot take over that address. This is the most likely cause because the virtual cluster IP is essential for client traffic to reach the active unit in load-balance mode.

Exam trap

The trap here is that candidates often assume all HA modes automatically transfer a virtual IP during failover, but Fortinet's load-balance mode explicitly requires a virtual cluster IP configuration for that behavior, and without it, the IP remains static on the original primary unit.

How to eliminate wrong answers

Option A is wrong because session pickup is unrelated to IP address takeover; it synchronizes existing sessions between HA members, not the virtual IP assignment. Option B is wrong because HA interface monitoring detects link failures to trigger failover, but it does not control whether the virtual cluster IP is transferred; the issue here is about IP address takeover, not failover triggering. Option D is wrong because a split-brain scenario occurs when both units become primary simultaneously, typically due to communication loss, but the described behavior (secondary becomes primary but does not take over the IP) does not match split-brain, where both would claim the virtual IP.

Practice this question →

MCQhard

An SD-WAN rule uses a performance SLA to steer traffic to the best-quality link. Traffic is consistently using the backup link even though the primary link meets SLA thresholds. The admin runs 'diagnose sys sdwan sla-check' and sees the primary link SLA status is 'pass'. What is the MOST likely cause?

A.The primary link's interface is administratively down

B.The primary link's cost is set higher than the backup

C.The SD-WAN rule's strategy is not set to 'Best Quality' or 'SLA'

D.The backup link has a higher bandwidth

AnswerC

The rule must use SLA-based strategy; otherwise, it may ignore SLA results.

Why this answer

The SD-WAN rule's strategy determines how traffic is steered. If the strategy is not set to 'Best Quality' or 'SLA', the rule will not use the performance SLA results to select the best link, even if the SLA status shows 'pass'. The primary link may be passing SLA thresholds, but without the correct strategy, the rule will ignore SLA status and may use a different selection method (e.g., lowest cost or load balancing), causing traffic to use the backup link.

Exam trap

The trap here is that candidates assume a 'pass' SLA status automatically means traffic will use that link, but they forget that the SD-WAN rule's strategy must explicitly be set to 'Best Quality' or 'SLA' to enforce SLA-based steering.

How to eliminate wrong answers

Option A is wrong because if the primary link's interface were administratively down, the SLA check would show 'down' or 'inactive', not 'pass'. Option B is wrong because cost is used for route selection in routing tables, not for SD-WAN rule traffic steering; SD-WAN rules use SLA and strategy, not interface cost. Option D is wrong because higher bandwidth on the backup link does not override SLA-based steering; the SD-WAN rule's strategy and SLA status are the primary determinants, not raw bandwidth.

Practice this question →

MCQmedium

A FortiGate admin notices that sessions to a particular server are not being logged in FortiAnalyzer. The firewall policy has logging enabled. What is the MOST likely reason?

A.The FortiAnalyzer's device registration is incorrect

B.The log queue on FortiGate is full

C.The FortiGate is not configured to send logs to FortiAnalyzer

D.The FortiAnalyzer is out of disk space

AnswerC

If the log forwarding is not set up, logs are stored locally but not sent to FortiAnalyzer.

Why this answer

The most likely reason is that the FortiGate is not configured to send logs to FortiAnalyzer. Even if the firewall policy has logging enabled, logs are only generated locally on the FortiGate; they must be explicitly forwarded to FortiAnalyzer via the 'config log fortianalyzer setting' CLI or GUI configuration. Without this configuration, no logs reach FortiAnalyzer regardless of policy settings.

Exam trap

The trap here is that candidates assume enabling logging on a firewall policy automatically sends logs to FortiAnalyzer, but FortiGate requires an explicit log forwarding configuration to direct logs to an external analyzer.

How to eliminate wrong answers

Option A is wrong because incorrect device registration on FortiAnalyzer would prevent log reception or cause authentication failures, but the question states sessions are not being logged at all, which points to a missing log forwarding configuration rather than a registration mismatch. Option B is wrong because a full log queue on FortiGate would cause log loss or backpressure, but it would not prevent all sessions from being logged; some logs would still be sent until the queue is exhausted, and the admin would typically see queue warnings. Option D is wrong because if FortiAnalyzer is out of disk space, it would stop accepting new logs and generate disk-full alerts, but the FortiGate would still attempt to send logs and the issue would be on the analyzer side, not a complete absence of logging.

Practice this question →

100

MCQeasy

An administrator wants to see the current sessions for a specific source IP address 192.168.1.10. Which CLI command should be used?

A.diagnose sys session filter src 192.168.1.10; diagnose sys session list

B.get system session list src 192.168.1.10

C.diagnose debug flow src-addr 192.168.1.10

D.execute session list source 192.168.1.10

AnswerA

This is the correct way to filter and list sessions for a source IP.

Why this answer

The `diagnose sys session filter src` command sets a filter for the source IP address, and `diagnose sys session list` then displays only the sessions matching that filter. This two-step process is the standard FortiGate CLI method for viewing active sessions for a specific source IP, as it leverages the session table directly without triggering debug overhead.

Exam trap

The trap here is that candidates confuse the `diagnose` command category (used for diagnostics and session inspection) with `get` or `execute` commands, or mistakenly think `diagnose debug flow` is appropriate for listing sessions when it is actually a real-time debug tool that can disrupt production traffic.

How to eliminate wrong answers

Option B is wrong because `get system session list` is not a valid FortiGate command; the correct command for listing sessions is `diagnose sys session list`, and `get` commands are used for configuration objects, not session diagnostics. Option C is wrong because `diagnose debug flow` is used for real-time packet flow debugging with detailed logging, not for listing existing sessions; it would generate excessive output and is not designed to show the current session table. Option D is wrong because `execute session list` is not a valid FortiGate command; the `execute` command category is for administrative actions like backups or reboots, not for session inspection.

Practice this question →

101

MCQmedium

A FortiGate administrator is troubleshooting a VPN tunnel that is up but no traffic passes through. The Phase 2 selectors match. The administrator runs 'diagnose vpn tunnel list' and sees that the tunnel has '0 bytes' in both directions. What is the MOST likely cause?

A.The firewall policy is not configured to allow traffic through the tunnel

B.The static route for the remote subnet does not point to the VPN tunnel interface

C.The IPsec SA rekey interval is too short

D.The NAT traversal is not enabled

AnswerB

Without proper routing, traffic is not sent to the tunnel.

Why this answer

When a VPN tunnel is up but shows 0 bytes in both directions, it indicates that the control plane (IKE/IPsec SA negotiation) succeeded, but the data plane has no traffic. The most likely cause is that the static route for the remote subnet does not point to the VPN tunnel interface (e.g., 'tunnel.1'), so the FortiGate does not know to send traffic into the tunnel. Without a correct route, packets destined for the remote subnet are dropped or sent out the wrong interface, resulting in zero bytes on the tunnel.

Exam trap

The trap here is that candidates assume a 'tunnel is up' means traffic should flow, but FortiGate separates control plane (IKE/SA negotiation) from data plane (routing/policy); the tunnel being up only confirms Phase 1 and Phase 2 SAs exist, not that traffic is routed into the tunnel.

How to eliminate wrong answers

Option A is wrong because if the firewall policy were missing, the tunnel would still show bytes for encapsulated traffic (e.g., ESP packets) that are dropped by the policy; 0 bytes indicates no traffic even reached the tunnel interface. Option C is wrong because a short IPsec SA rekey interval would cause frequent renegotiations and potential brief interruptions, but it would not prevent all traffic from passing; bytes would still accumulate between rekeys. Option D is wrong because NAT traversal (NAT-T) is only needed when a NAT device exists between the VPN peers; if NAT-T were missing and a NAT device were present, the tunnel would not come up at all (Phase 1 would fail), not show 0 bytes with the tunnel up.

Practice this question →

102

MCQhard

An administrator is troubleshooting an IPsec VPN tunnel that fails to establish. The Phase 1 status shows 'init' and the debug output indicates 'no suitable proposal found'. The remote peer is a third-party VPN device. Which of the following is the MOST likely cause?

A.The pre-shared key is incorrect on one side

B.The remote peer's IP address is not reachable

C.The IKE version or encryption algorithm does not match between the peers

D.The firewall policy allowing the VPN traffic is missing

AnswerC

Proposal mismatch is caused by incompatible IKE parameters like encryption, hash, or DH group.

Why this answer

The 'no suitable proposal found' error in Phase 1 indicates that the IKE proposal parameters (such as encryption algorithm, hash algorithm, Diffie-Hellman group, or IKE version) do not match between the FortiGate and the third-party peer. Since the status is 'init', the peers have exchanged initial packets but cannot agree on a common proposal, which is a classic proposal mismatch issue. A pre-shared key mismatch would typically cause an authentication failure later in Phase 1, not a 'no suitable proposal' error.

Exam trap

The trap here is that candidates often confuse 'no suitable proposal' with a pre-shared key mismatch, but the error occurs earlier in the IKE exchange before authentication begins, so it must be a proposal parameter mismatch.

How to eliminate wrong answers

Option A is wrong because a pre-shared key mismatch would result in an authentication failure (e.g., 'invalid cookie' or 'authentication failed') after the proposal is accepted, not a 'no suitable proposal found' error. Option B is wrong because if the remote peer's IP address were unreachable, the Phase 1 status would show 'down' or the debug would show 'no response' or 'timeout', not an active exchange with a proposal rejection. Option D is wrong because a missing firewall policy allowing VPN traffic would prevent the IKE packets from being forwarded, resulting in no response or a timeout, not a proposal negotiation failure.

Practice this question →

103

MCQhard

An administrator is investigating a security incident and needs to determine which firewall policy allowed a specific malicious traffic flow. The traffic is no longer active. Which FortiAnalyzer log type should the admin query?

A.Event logs

B.Security logs

C.Traffic logs

D.Audit logs

AnswerC

Traffic logs contain policy ID and action for each session, perfect for this investigation.

Why this answer

Traffic logs record every session that passes through the FortiGate, including the source/destination IPs, ports, policy ID, and action taken. Since the traffic is no longer active, the administrator must query historical traffic logs in FortiAnalyzer to identify which firewall policy permitted the malicious flow. Event logs, security logs, and audit logs do not contain the per-session policy mapping needed for this forensic analysis.

Exam trap

The trap here is that candidates confuse 'security logs' (which log threat detections) with 'traffic logs' (which log all permitted sessions), mistakenly thinking that a security event log would contain the policy ID that allowed the malicious flow, when in fact traffic logs are the only source for historical policy-to-session mapping.

How to eliminate wrong answers

Option A is wrong because event logs capture system events (e.g., HA state changes, interface up/down, admin logins) and do not record per-session firewall policy decisions. Option B is wrong because security logs (e.g., IPS, antivirus, web filter) record threat detections but not the specific firewall policy that allowed the traffic; they reference a policy ID only if the traffic was already permitted. Option D is wrong because audit logs track administrative actions (e.g., config changes, CLI commands) and contain no information about individual traffic flows or firewall policy matches.

Practice this question →

104

MCQeasy

An administrator wants to view the current number of active sessions on a FortiGate. Which CLI command should be used?

A.exec system session count

B.show system session count

C.diagnose sys session list

D.get system performance status

AnswerD

Correct. This command displays session count, CPU, and memory usage.

Why this answer

The command 'get system performance status' displays real-time system performance metrics, including the current number of active sessions (sessions in the session table). This is the correct CLI command for an administrator to view the active session count on a FortiGate.

Exam trap

The trap here is that candidates often confuse 'diagnose sys session list' (which shows detailed session information) with the simpler command needed to just view the session count, or they incorrectly assume 'exec' or 'show' are valid FortiGate command prefixes for this purpose.

How to eliminate wrong answers

Option A is wrong because 'exec system session count' is not a valid FortiGate CLI command; the correct syntax for counting sessions is 'diagnose sys session count'. Option B is wrong because 'show system session count' uses 'show', which is not a valid FortiGate command prefix; FortiGate uses 'get' for configuration and status, and 'diagnose' for diagnostic commands. Option C is wrong because 'diagnose sys session list' lists all sessions in detail, not just the count; it is used for deep inspection, not for quickly viewing the current number of active sessions.

Practice this question →

105

Multi-Selectmedium

An administrator is configuring SD-WAN and wants to ensure that traffic matching a specific SLA rule uses the best-performing member. Which TWO commands can be used to verify the SLA performance and route selection? (Choose two.)

Select 2 answers

A.diagnose sys session list

B.diagnose sys sdwan health-check

C.get router info routing-table

D.diagnose sys sdwan info

E.show system sdwan

AnswersB, D

Shows health-check results per member.

Why this answer

The 'diagnose sys sdwan health-check' command displays real-time SLA performance metrics for each SD-WAN member, including latency, jitter, and packet loss. Option D is correct because 'diagnose sys sdwan info' provides detailed information about SD-WAN zones, rules, and the current best-performing member selected for each SLA rule. Both commands are essential for verifying SLA compliance and route selection in FortiGate SD-WAN.

Exam trap

The trap here is that candidates confuse 'diagnose sys sdwan info' with 'get router info routing-table', assuming the routing table reflects SD-WAN decisions, but SD-WAN uses a separate policy-based routing mechanism that does not always update the kernel routing table for per-session steering.

Practice this question →

106

MCQeasy

An administrator wants to monitor CPU usage of specific processes on a FortiGate. Which command should be used?

A.get system performance status

B.diagnose sys top

C.get system performance

D.top

AnswerB

This shows process-level CPU and memory usage.

Why this answer

The 'diagnose sys top' command is the correct tool for monitoring CPU usage of specific processes on a FortiGate because it provides a real-time, interactive view of process-level CPU and memory utilization, allowing the administrator to identify which processes are consuming resources. Unlike the other options, this diagnostic command is specifically designed for granular process monitoring in FortiOS.

Exam trap

The trap here is that candidates may confuse the generic Linux 'top' command with FortiOS's 'diagnose sys top', or assume that 'get system performance status' provides process-level detail when it only shows aggregate system metrics.

How to eliminate wrong answers

Option A is wrong because 'get system performance status' displays overall system performance statistics (e.g., CPU, memory, sessions) but does not show per-process CPU usage. Option C is wrong because 'get system performance' is not a valid FortiGate command; the correct command for overall performance is 'get system performance status'. Option D is wrong because 'top' is a standard Linux command that is not available in the FortiGate CLI; FortiOS uses 'diagnose sys top' as its equivalent for process-level monitoring.

Practice this question →

107

MCQeasy

A BGP peering between two FortiGates is not establishing. The admin runs 'get router info bgp summary' and sees the neighbor state as 'Idle'. What is the most common cause of a BGP session stuck in Idle?

A.The BGP update timer is set too high

B.The remote AS number is misconfigured

C.The neighbor IP is not reachable or the TCP port 179 is blocked

D.The route advertisement is disabled

AnswerC

BGP uses TCP port 179; if the neighbor is unreachable or port is blocked, the session cannot start, staying in Idle.

Why this answer

The Idle state in BGP indicates that the session has not started or has been reset, often because the underlying TCP connection cannot be established. The most common cause is that the neighbor IP is unreachable or TCP port 179 is blocked by a firewall or ACL, preventing the three-way handshake. Without TCP connectivity, BGP cannot transition out of Idle, regardless of other configurations.

Exam trap

The trap here is that candidates often confuse the Idle state with the Active state, assuming any misconfiguration (like wrong AS number) causes Idle, but in BGP FSM, an AS mismatch typically results in the Active state or a notification error, not Idle.

How to eliminate wrong answers

Option A is wrong because the BGP update timer (which controls the interval for sending route updates) does not affect the session establishment state; it only influences how often updates are sent after the session is up. Option B is wrong because a misconfigured remote AS number typically causes the session to go to Active state (not Idle) as the router attempts to connect but receives an incorrect OPEN message. Option D is wrong because disabling route advertisement does not prevent the BGP session from establishing; it only stops the advertisement of routes once the session is up.

Practice this question →

108

MCQmedium

An administrator runs 'diagnose debug application ipsmonitor -1' and sees repeated messages: 'IPS engine restarting'. What is the MOST likely cause of this behavior?

A.The FortiGate is overloaded with too many concurrent sessions

B.The IPS engine is running out of memory

C.The firewall policy is configured for flow-based inspection

D.The IPS signatures are outdated and need updating

AnswerB

Memory exhaustion causes the IPS engine to restart to free resources.

Why this answer

The 'IPS engine restarting' message in the output of 'diagnose debug application ipsmonitor -1' indicates that the IPS engine process is crashing and being automatically restarted by the FortiGate's watchdog. The most common cause of IPS engine crashes is memory exhaustion, as the engine requires a dedicated memory heap to process signatures and sessions; when this heap is depleted, the engine terminates to prevent system instability.

Exam trap

The trap here is that candidates often confuse 'IPS engine restarting' with general system overload or policy misconfiguration, but the specific debug output points directly to a process crash, which is almost always caused by memory exhaustion in the IPS engine heap.

How to eliminate wrong answers

Option A is wrong because an overload of concurrent sessions would typically cause high CPU usage or session table exhaustion, not a specific IPS engine restart; the IPS engine can handle high session counts if memory is sufficient. Option C is wrong because flow-based inspection is a valid inspection mode that uses the IPS engine, but it does not inherently cause engine restarts; the engine restart issue is related to resource exhaustion, not the inspection mode itself. Option D is wrong because outdated IPS signatures do not cause the engine to restart; they may result in missed detections or false positives, but the engine process remains stable unless memory or other critical resources are exhausted.

Practice this question →

109

Multi-Selectmedium

A FortiGate administrator is investigating a security incident and needs to identify which user initiated a specific outbound connection to a malicious IP address. The company uses FSSO for authentication. Which THREE pieces of information from FortiAnalyzer logs would be MOST useful? (Choose three.)

Select 3 answers

A.Username from the FortiGate authentication log

B.Destination IP address

C.Event type (e.g., traffic, event, attack)

D.Source IP address of the session

E.Timestamp of the session

AnswersA, D, E

Links the session to the authenticated user.

Why this answer

FSSO (Fortinet Single Sign-On) maps network sessions to Active Directory usernames via the FortiGate authentication log. When investigating which user initiated an outbound connection to a malicious IP, the username from this log directly ties the session to a specific identity, enabling attribution beyond just IP addresses.

Exam trap

The trap here is that candidates often select 'Destination IP address' thinking it helps identify the user, but it only identifies the target of the attack, not the initiator, and fails to leverage the FSSO authentication mapping required for user attribution.

Practice this question →

110

MCQeasy

An administrator runs 'diagnose sys top' and sees process 'httpsd' consuming 95% CPU. What is the best immediate action to alleviate the issue?

A.Change the administration HTTPS port and restrict access to trusted hosts

B.Kill the httpsd process

C.Disable HTTPS administration access

D.Reboot the FortiGate

AnswerA

Correct. Changing the port and restricting source IPs can mitigate the attack without losing access.

Why this answer

The 'httpsd' process handles HTTPS administration traffic. A CPU spike to 95% indicates a possible DoS attack or excessive management connections. Changing the HTTPS port and restricting access to trusted hosts immediately mitigates the attack surface without disrupting other services, as it limits the source of the malicious traffic.

Exam trap

The trap here is that candidates often choose to kill the process or disable HTTPS entirely, thinking it will stop the CPU usage, but they overlook that the root cause is likely an external attack or misconfiguration that requires access control, not process termination.

How to eliminate wrong answers

Option B is wrong because killing the httpsd process would terminate all HTTPS management sessions, potentially locking out the administrator and requiring console access to restart the process, without addressing the root cause. Option C is wrong because disabling HTTPS administration access entirely would prevent any future secure management, which is an overreaction and may violate security policies; it also does not stop the current attack if the process is already overwhelmed. Option D is wrong because rebooting the FortiGate is a temporary fix that does not prevent the attack from recurring immediately after the system comes back up, and it causes unnecessary downtime.

Practice this question →

111

Multi-Selecthard

During a BGP troubleshooting session, an administrator sees that the BGP neighbor state is 'Active'. Which three conditions could cause this state? (Choose THREE.)

Select 3 answers

A.The remote AS number is misconfigured

B.The BGP update timer is too short

C.The neighbor IP address is incorrectly configured

D.The maximum-prefix limit has been exceeded

E.A firewall is blocking TCP port 179

AnswersA, C, E

ASN mismatch causes the remote end to reject the open message, leading to Active state.

Why this answer

A misconfigured remote AS number causes the BGP neighbor to remain in the 'Active' state. BGP uses the remote AS number to validate the OPEN message; if the AS number in the OPEN message does not match the configured remote AS, the session is rejected, and the neighbor stays in Active, repeatedly attempting to establish a TCP connection.

Exam trap

The trap here is that candidates often confuse 'Active' with 'Idle' or 'Connect' states, mistakenly thinking that a firewall block or misconfiguration would cause 'Idle' instead of 'Active', but 'Active' specifically indicates the router is retrying TCP connection attempts after a failure.

Practice this question →

112

MCQeasy

A FortiGate administrator wants to verify whether a specific session is being offloaded to the NP6 processor. Which CLI command should the administrator use?

A.diagnose sys session filter src 10.0.0.1 ; diagnose sys session list

B.get system performance status

C.diagnose hardware sysinfo memory

D.diagnose npu np6 session list

AnswerA

This shows session details and offload status.

Why this answer

The 'diagnose sys session filter src 10.0.0.1' command sets a filter to isolate sessions from a specific source IP, and 'diagnose sys session list' then displays the session details, including the 'offload' field. This field explicitly indicates whether the session is offloaded to the NP6 processor (e.g., 'offload yes' or 'np6 offload'). This is the standard method to verify NP6 offloading for a specific session.

Exam trap

The trap here is that candidates may confuse the generic 'diagnose sys session list' command with the NP6-specific 'diagnose npu np6 session-list' command, but the latter lacks filtering capabilities and is not the correct way to verify offload for a specific session; the exam tests the ability to combine session filtering with the session list output to check the offload flag.

How to eliminate wrong answers

Option B is wrong because 'get system performance status' provides a high-level overview of system resource usage (CPU, memory, sessions) but does not show per-session offload status or NP6-specific details. Option C is wrong because 'diagnose hardware sysinfo memory' reports memory hardware information and usage statistics, not session offloading to NP6 processors. Option D is wrong because 'diagnose npu np6 session list' is not a valid FortiGate CLI command; the correct command to list NP6 offloaded sessions is 'diagnose npu np6 session-list' (with a hyphen), and even then it lists all offloaded sessions without filtering, making it impractical for verifying a specific session without additional filters.

Practice this question →

113

MCQmedium

A FortiGate is receiving BGP routes from a neighbor but not advertising them to other peers. The administrator runs 'get router info bgp network' and sees the routes are in the BGP table but not advertised. What is the most likely cause?

A.BGP synchronization is enabled and the routes are not in the IGP

B.An outbound route map is applied that filters these routes

C.The next hop is unreachable

D.The router-id is the same as the peer

AnswerB

Correct. A route map can selectively permit or deny routes from being advertised.

Why this answer

An outbound route map can explicitly filter which routes are advertised to BGP peers. Even though routes are present in the BGP table (as shown by 'get router info bgp network'), an outbound route map applied to the neighbor configuration can deny or modify those routes before they are sent, preventing their advertisement.

Exam trap

The trap here is that candidates often assume BGP synchronization (Option A) is the cause, but synchronization only affects IBGP-learned routes and is disabled by default in modern implementations, whereas an outbound route map is the direct mechanism controlling advertisement to peers.

How to eliminate wrong answers

Option A is wrong because BGP synchronization (RFC 1771, deprecated in RFC 4271) is disabled by default on FortiGate and, even if enabled, would only affect routes learned from an IBGP peer—not routes being advertised to other peers; the issue here is about outbound advertisement, not IGP reachability. Option C is wrong because if the next hop were unreachable, the routes would not appear in the BGP table as valid; they would be marked as invalid or not installed, but the question states the routes are in the BGP table, implying the next hop is reachable. Option D is wrong because having the same router-id as a peer would cause BGP session establishment to fail (due to duplicate router-id detection), preventing any routes from being received or advertised at all, which contradicts the scenario where routes are already in the BGP table.

Practice this question →

114

MCQmedium

After upgrading FortiGate firmware, an admin notices that several sessions using SIP are failing. The SIP ALG was enabled before the upgrade. What is the MOST likely cause?

A.The SIP session helper is now deprecated

B.The SIP service port changed

C.The SIP ALG configuration was reset to default, affecting session handling

D.The FortiGate's SIP inspection profile was removed

AnswerC

Upgrades can reset ALG settings, causing SIP sessions to fail.

Why this answer

Upgrading FortiGate firmware can reset the SIP ALG configuration to its default settings, which may alter session handling parameters such as timeouts, port ranges, or application-layer gateway (ALG) behavior. This default reset often causes previously working SIP sessions to fail, especially if custom SIP ALG settings were used to accommodate specific VoIP environments. The SIP ALG remains enabled after the upgrade, but its default configuration may not match the pre-upgrade customizations, leading to session failures.

Exam trap

The trap here is that candidates may assume the SIP ALG is disabled or removed after an upgrade, but the actual issue is that its configuration is reset to default, altering session handling behavior without disabling the feature itself.

How to eliminate wrong answers

Option A is wrong because the SIP session helper is not deprecated; it is a separate mechanism from the SIP ALG and remains available in FortiOS for SIP traffic handling. Option B is wrong because the SIP service port (typically UDP/TCP 5060) does not change during a firmware upgrade; SIP ALG configuration changes, not port changes, cause session failures. Option D is wrong because the SIP inspection profile is not removed during a firmware upgrade; it may be reset to default, but the profile itself persists in the configuration.

Practice this question →

115

MCQeasy

You receive an alert that FortiAnalyzer log disk usage is at 95%. Which action should you take to immediately free up space without losing important logs?

A.Delete all logs older than 30 days

B.Enable log compression

C.Configure log archiving to an external storage

D.Increase log disk quota

AnswerC

Archiving moves old logs off the device.

Why this answer

Configuring log archiving to an external storage immediately offloads logs from the FortiAnalyzer local disk to a remote location (e.g., NFS, FTP, or SCP), freeing up disk space without deleting any logs. This preserves all historical log data for compliance and forensic analysis while resolving the high disk usage alert.

Exam trap

The trap here is that candidates often choose to delete logs or increase the quota, mistakenly thinking these are safe or immediate fixes, but the exam tests the understanding that archiving preserves data while freeing space, and that compression or quota changes do not provide instant relief.

How to eliminate wrong answers

Option A is wrong because deleting all logs older than 30 days permanently removes historical data, which may violate compliance requirements and loses important logs that could be needed for incident response or auditing. Option B is wrong because enabling log compression reduces the size of logs on disk but does not immediately free up space—it only affects newly stored logs and requires existing logs to be recompressed, which is not an instant fix. Option D is wrong because increasing the log disk quota does not free up existing space; it merely raises the threshold for disk usage, allowing more logs to be stored until the disk eventually fills again, which does not resolve the immediate 95% usage issue.

Practice this question →

116

MCQeasy

An administrator wants to verify that a BGP route is being advertised to a neighbor. Which command displays the routes that FortiGate is advertising to a specific BGP neighbor?

A.get router info bgp network

B.get router info bgp neighbor <ip> advertised-routes

C.diagnose ip router bgp routes

D.show ip bgp summary

AnswerB

Correct command.

Why this answer

The command 'get router info bgp neighbor <ip> advertised-routes' is the specific FortiOS CLI command that displays the BGP routes that the FortiGate has advertised to a particular BGP neighbor. This command queries the BGP table for routes that have been sent to the neighbor and are in the Adj-RIB-Out, which is exactly what the administrator needs to verify outbound route advertisement.

Exam trap

The trap here is that candidates often confuse the FortiOS 'get router info bgp neighbor <ip> advertised-routes' command with Cisco's 'show ip bgp neighbors <ip> advertised-routes' or mistakenly use a generic 'show ip bgp summary' command, which only shows neighbor state and not the actual advertised routes.

How to eliminate wrong answers

Option A is wrong because 'get router info bgp network' is not a valid FortiOS command; the correct command to view BGP network statements is 'get router info bgp network' but it shows locally originated networks configured under BGP, not routes advertised to a specific neighbor. Option C is wrong because 'diagnose ip router bgp routes' is not a valid FortiOS command; the 'diagnose' commands are used for debugging and diagnostics, not for displaying BGP advertised routes. Option D is wrong because 'show ip bgp summary' is a Cisco IOS command, not a FortiOS command; the FortiOS equivalent is 'get router info bgp summary', which shows BGP neighbor states and statistics but not advertised routes.

Practice this question →

117

MCQhard

Two FortiGate units in an HA cluster are experiencing synchronization issues. The administrator runs 'diagnose sys ha checksum cluster' and sees different checksum values for the 'system' and 'router' objects. What is the FIRST step to resolve the mismatch?

A.Execute 'execute ha synchronize start' from the primary unit

B.Upgrade the firmware on both units to the same version

C.Reboot both units to force a full sync

D.Disable and re-enable HA on both units

AnswerA

This command forces configuration synchronization from primary to secondary.

Why this answer

The 'diagnose sys ha checksum cluster' command reveals checksum mismatches for 'system' and 'router' objects, indicating that the HA cluster's configuration synchronization is incomplete or out of sync. The first step is to initiate a manual synchronization using 'execute ha synchronize start' from the primary unit, which forces the primary to push its full configuration database to the secondary unit, resolving the mismatch without disrupting services. This command is designed to trigger a full sync of all configuration objects, including system and router settings, without requiring a reboot or HA restart.

Exam trap

The trap here is that candidates often assume a checksum mismatch requires a disruptive action like a reboot or HA restart, when in fact FortiGate provides a non-disruptive manual sync command that is the correct first step in the troubleshooting process.

How to eliminate wrong answers

Option B is wrong because upgrading firmware to the same version is a prerequisite for HA formation, not a troubleshooting step for a checksum mismatch that occurs after HA is already established; the units must already be on the same firmware version to form the cluster. Option C is wrong because rebooting both units would cause a service outage and does not directly address the synchronization issue; while a reboot might trigger a sync, it is an unnecessarily disruptive first step compared to the targeted sync command. Option D is wrong because disabling and re-enabling HA on both units would tear down and rebuild the cluster, causing a full HA election and potential traffic disruption, which is excessive when a simple manual sync can resolve the checksum mismatch.

Practice this question →

118

MCQmedium

A FortiGate administrator uses FortiAnalyzer for log analysis and wants to identify all sessions that were blocked by a specific firewall policy ID 10. Which log filter should be applied?

A.Filter by 'action eq block' and then manually look for policy 10

B.Filter by 'policyid == 10'

C.Filter by 'policyid eq 10'

D.Filter by 'devid contains 10'

AnswerC

Correct. Using 'policy_id = 10' directly filters for all sessions handled by policy ID 10, including those blocked, using the accepted '=' operator.

Why this answer

The correct filter to identify sessions from a specific policy in FortiAnalyzer is 'policyid eq 10'. This uses the proper field name 'policyid' and the 'eq' operator. Option B uses '==' which is invalid, and option C uses the incorrect field name 'policy_id'.

Practice this question →

119

Multi-Selecthard

You are troubleshooting BGP route advertisement issues. Which THREE debug commands would be useful to identify why a route is not being advertised to a neighbor? (Choose three.)

Select 3 answers

A.diagnose debug router bgp <neighbor>

B.get router info bgp neighbors <neighbor> received-routes

C.get router info bgp summary

D.get router info bgp neighbors <neighbor> advertised-routes

E.get router info routing-table bgp

AnswersA, D, E

Shows BGP debug messages including updates.

Why this answer

The 'diagnose debug router bgp <neighbor>' command enables real-time debugging of BGP events for a specific neighbor, allowing you to see why a route is being filtered or not advertised (e.g., due to prefix-list, AS-path, or next-hop unreachable issues). This is a Fortinet-specific debug command that provides granular insight into the BGP decision process for that neighbor.

Exam trap

The trap here is that candidates often confuse 'received-routes' (inbound) with 'advertised-routes' (outbound) and think a summary command provides enough detail to diagnose per-neighbor advertisement issues.

Practice this question →

120

MCQmedium

You run 'diagnose sys session filter dport 443' and see sessions with a duration of 7200 seconds and expire time of 3600 seconds. What does this indicate?

A.The session has been idle for 7200 seconds

B.The session helper is interfering with the session

C.The session has been alive for 7200 seconds and will expire in 3600 seconds

D.The session has already expired

AnswerC

Duration is time alive; expire is remaining lifetime.

Why this answer

The 'duration' field in the 'diagnose sys session filter' output shows how long the session has been active (7200 seconds), while the 'expire' field indicates the remaining time before the session times out (3600 seconds). Option C correctly interprets both values. This is standard FortiGate session table behavior, where each session has a configurable timeout (e.g., default TCP timeout is 3600 seconds for established sessions).

Exam trap

The trap here is confusing 'duration' with 'idle time' — candidates often assume duration measures inactivity, but FortiGate's session table uses separate fields for idle time and total session age.

How to eliminate wrong answers

Option A is wrong because 'duration' measures total session lifetime, not idle time; idle time is tracked separately via the 'idle' field in the session output. Option B is wrong because session helpers (e.g., ALG for SIP or FTP) do not cause a discrepancy between duration and expire time; they modify session behavior but are not indicated by these two fields alone. Option D is wrong because an expired session would not appear in the session list; the expire time of 3600 seconds means the session is still active and will expire in one hour.

Practice this question →

121

MCQmedium

A user reports that they cannot connect to a remote office via IPsec VPN. Phase 1 is up, but Phase 2 fails to establish. The administrator runs 'diagnose vpn ike log' and sees 'no matching phase2 proposal'. What should be checked?

A.The firewall policies allow IKE traffic

B.The local and remote subnet definitions are correct

C.The pre-shared key is correct

D.The Phase 2 proposal settings (encryption, authentication, PFS) match on both peers

AnswerD

Mismatched Phase 2 proposals prevent the tunnel from establishing.

Why this answer

The error 'no matching phase2 proposal' indicates that the IPsec peers cannot agree on the Phase 2 parameters (encryption, authentication, PFS group, lifetime). Since Phase 1 is up, IKE negotiation for the secure channel succeeded, but the subsequent IPsec SA negotiation fails because the proposed transforms do not match. Option D directly addresses this mismatch by requiring verification of the Phase 2 proposal settings on both peers.

Exam trap

The trap here is that candidates confuse Phase 1 and Phase 2 failures, assuming any 'no matching proposal' error relates to IKE parameters, when in fact Phase 1 being up isolates the issue to the IPsec SA negotiation in Phase 2.

How to eliminate wrong answers

Option A is wrong because IKE traffic (UDP 500/4500) is already allowed for Phase 1 to be up; a firewall policy blocking IKE would prevent Phase 1 entirely. Option B is wrong because incorrect local/remote subnet definitions would cause a different error, such as 'no matching selector' or traffic not matching the proxy ID, not a proposal mismatch. Option C is wrong because the pre-shared key is used only in Phase 1 authentication; if it were incorrect, Phase 1 would fail to establish, not Phase 2.

Practice this question →

122

Matchingmedium

Match each high availability (HA) mode to its characteristic.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

One unit handles traffic; standby takes over on failure

Both units handle traffic simultaneously

FortiGate Clustering Protocol

Synchronizes sessions between HA members

Link used for HA communication and synchronization

Why these pairings

The correct matches are A and B. Common confusions involve swapping the characteristics: Active-Passive uses a single active unit with standby, while Active-Active uses all units to handle traffic.

Practice this question →

123

MCQmedium

A FortiGate is configured with SD-WAN and multiple members. The administrator notices that traffic to a critical application is consistently routed over a low-quality link, even though a better link is available. The SD-WAN rule uses the 'Best Quality' strategy with a performance SLA. What is the most likely reason?

A.The better link is failing its SLA probes

B.The better link is in 'standby' mode

C.The SD-WAN rule is using source-based routing

D.The application traffic is not matching the SD-WAN rule

AnswerA

Correct. If a link fails SLA, it is considered out of compliance and not selected by 'Best Quality'.

Why this answer

When an SD-WAN rule uses the 'Best Quality' strategy with a performance SLA, the FortiGate selects the member link that best meets the SLA targets (e.g., jitter, latency, packet loss). If the better link is failing its SLA probes, it is considered out of compliance and will not be selected, even if it is physically available and has higher bandwidth. This causes traffic to be routed over the lower-quality link that still passes the SLA.

Exam trap

The trap here is that candidates assume 'Best Quality' always picks the link with the highest bandwidth or lowest cost, when in fact it strictly selects based on SLA compliance, not raw capacity or administrative preference.

How to eliminate wrong answers

Option B is wrong because a link in 'standby' mode is only used for failover when all active links fail; it would not be considered a 'better link' that is available for selection under normal SD-WAN rules. Option C is wrong because source-based routing is a different strategy that ignores SLA performance; the question explicitly states the rule uses 'Best Quality' with a performance SLA, so source-based routing is not in effect. Option D is wrong because if the application traffic were not matching the SD-WAN rule, it would be handled by the regular routing table or policy-based routing, not consistently routed over a low-quality link via the SD-WAN rule.

Practice this question →

124

MCQmedium

A network admin runs 'diagnose sys top' on a FortiGate and sees that the process 'httpsd' is consistently using 95% CPU. Which of the following actions is MOST appropriate to troubleshoot this issue?

A.Restart the FortiGate firewall engine with 'diagnose test application fgwbd 255'

B.Disable the antivirus profile on all policies to reduce processing load

C.Increase the log rate to capture more details about the httpsd process

D.Check the number of active admin sessions and consider stopping the web GUI service temporarily

AnswerD

httpsd handles web management; high CPU may be due to many admin sessions or a stuck process.

Why this answer

The httpsd process handles the FortiGate web GUI (HTTPS) and API requests. High CPU usage by httpsd typically indicates excessive admin sessions or web GUI activity. Option D is correct because checking active admin sessions and temporarily stopping the web GUI service (e.g., via 'config system global set admin-https-redirect disable' or stopping the service) directly addresses the likely cause without disrupting firewall processing or requiring policy changes.

Exam trap

The trap here is that candidates may confuse the httpsd process with the firewall engine (fgwbd) and attempt to restart the firewall engine, or assume high CPU is always due to security profiles, when in fact httpsd is a management-plane process that requires a different troubleshooting approach.

How to eliminate wrong answers

Option A is wrong because 'diagnose test application fgwbd 255' restarts the firewall engine (fgwbd), which handles firewall processing, not the httpsd process; this would disrupt traffic without addressing the root cause. Option B is wrong because disabling antivirus profiles on all policies reduces security and does not affect the httpsd process, which is a web server process unrelated to AV scanning. Option C is wrong because increasing the log rate adds overhead to the system and does not provide diagnostic details specific to httpsd; logs for httpsd are already captured in the event log and increasing rate would worsen CPU usage.

Practice this question →

125

MCQeasy

An administrator wants to monitor real-time CPU usage per process on a FortiGate. Which command should be used?

A.diagnose hardware sysinfo cpu

B.get system performance status

C.diagnose sys top

D.show system performance monitor

AnswerC

This command displays a real-time list of processes and their resource usage.

Why this answer

The 'diagnose sys top' command on FortiGate displays real-time CPU usage per process, similar to the Linux 'top' command. This is the standard diagnostic tool for monitoring per-process CPU and memory consumption in real time, which directly meets the administrator's requirement.

Exam trap

The trap here is that candidates may confuse 'diagnose sys top' with 'get system performance status' or 'diagnose hardware sysinfo cpu', which provide aggregate CPU data but not per-process granularity, leading to an incorrect choice when the question explicitly asks for per-process monitoring.

How to eliminate wrong answers

Option A is wrong because 'diagnose hardware sysinfo cpu' shows overall CPU utilization and hardware information, not per-process breakdown. Option B is wrong because 'get system performance status' provides a summary of system performance metrics (e.g., CPU, memory, sessions) but does not list individual processes. Option D is wrong because 'show system performance monitor' is not a valid FortiGate CLI command; the correct command for a performance monitor view is 'diagnose sys perf' or 'diagnose sys top'.

Practice this question →

126

MCQmedium

When troubleshooting a FortiGate that is not synchronizing configuration to its HA peer, which command should be used to check the HA synchronization status?

A.diagnose sys ha sync-status

B.get system ha status

C.diagnose sys ha status

D.show system ha

AnswerB

This command displays HA cluster status, sync state, and last sync error.

Why this answer

'get system ha status' is the standard operational command on FortiGate to display the current HA synchronization status, including whether the configuration is synchronized, the HA mode, and the peer status. This command provides a clear, human-readable output that directly indicates if the configuration is in sync or out of sync, which is essential for troubleshooting synchronization issues.

Exam trap

The trap here is that candidates confuse the diagnostic command 'diagnose sys ha status' (which shows raw internal HA data) with the operational command 'get system ha status' (which shows the synchronization status in a clear format), leading them to choose option C instead of the correct B.

How to eliminate wrong answers

Option A is wrong because 'diagnose sys ha sync-status' is not a valid FortiGate command; the correct diagnostic command for detailed HA synchronization debugging is 'diagnose sys ha dump sync-status' or similar, but this option is a distractor that does not exist. Option C is wrong because 'diagnose sys ha status' is a valid diagnostic command but it shows raw internal HA state information, not the user-friendly synchronization status; it is used for deep debugging, not for quickly checking sync status. Option D is wrong because 'show system ha' is a Cisco-style command, not a FortiGate command; FortiGate uses 'get' for operational status and 'show' is not used in the FortiOS CLI.

Practice this question →

127

Multi-Selectmedium

An administrator is configuring SD-WAN and wants to ensure that voice traffic uses the lowest latency link. Which two configurations are required to achieve this? (Choose TWO.)

Select 2 answers

A.Configure a static route for the voice subnet

B.Configure a performance SLA with latency threshold

C.Set the SD-WAN rule to use 'manual' strategy

D.Create an SD-WAN rule that matches voice traffic and uses 'best quality' strategy

E.Enable NAT on the SD-WAN interface

AnswersB, D

The SLA measures latency and marks link quality.

Why this answer

A performance SLA with a latency threshold allows FortiGate to measure real-time latency to a target server and mark the link quality. Option D is correct because an SD-WAN rule using the 'best quality' strategy will dynamically select the link with the lowest latency (as determined by the SLA) for voice traffic, ensuring optimal voice quality.

Exam trap

The trap here is that candidates often confuse 'manual' strategy with 'best quality', assuming manual allows manual selection of the best link, but manual actually forces a fixed interface without dynamic SLA feedback.

Practice this question →

128

Multi-Selecthard

An administrator is troubleshooting an IPsec VPN tunnel that fails to establish. Phase 1 seems to complete, but Phase 2 fails with 'no proposal chosen'. The administrator checks the Phase 2 configuration and sees the following settings: 'Local address: 10.0.0.0/24, Remote address: 192.168.0.0/24, Proposal: aes256-sha1, Enable Perfect Forward Secrecy (PFS): Disabled'. Which TWO changes would most likely resolve the issue? (Choose two.)

Select 2 answers

A.Enable PFS on FortiGate

B.Verify that the Phase 2 selectors match exactly on both sides

C.Change the local address to 10.0.0.0/8

D.Add aes256-sha256 to the Phase 2 proposal

E.Increase the Phase 2 lifetime

AnswersA, B

If the remote side requires PFS, FortiGate must enable it to match.

Why this answer

When PFS is enabled on one side but disabled on the other, Phase 2 will fail with 'no proposal chosen'. PFS requires both peers to agree on the Diffie-Hellman (DH) group used for generating new keying material. If the remote peer requires PFS and the FortiGate has it disabled, the proposal mismatch causes the failure.

Exam trap

The trap here is that candidates often focus on encryption algorithms or lifetimes when 'no proposal chosen' appears, but the most common root causes are PFS mismatch and selector mismatch, not the cipher suite itself.

Practice this question →

129

MCQeasy

An administrator observes that after a failover in an HA cluster, some established sessions are dropped. The cluster is configured with session pickup enabled. What is the most likely reason for the dropped sessions?

A.The failover occurred during a configuration synchronization

B.The HA uptime is less than the session TTL

C.Session pickup only synchronizes TCP sessions, and the dropped sessions are UDP

D.The session helper for the protocol is not enabled

AnswerC

Session pickup by default only synchronizes TCP sessions. UDP and other protocols are not preserved during failover.

Why this answer

Session pickup in FortiGate HA synchronizes state information for TCP sessions by default, but UDP sessions are not synchronized because they are connectionless and do not have a stateful handshake. When a failover occurs, the new primary unit does not have the UDP session state, causing those sessions to be dropped. This is a known limitation of session pickup, which only covers TCP sessions unless specifically configured for UDP via session-ttl or other mechanisms.

Exam trap

The trap here is that candidates assume session pickup covers all session types equally, but Fortinet specifically limits default synchronization to TCP sessions, and the question tests awareness of this protocol-specific behavior.

How to eliminate wrong answers

Option A is wrong because configuration synchronization occurs independently of session pickup and does not cause established sessions to drop during failover; it ensures configuration consistency, not session state. Option B is wrong because HA uptime being less than session TTL would affect session persistence only if session pickup were disabled or incomplete, but with session pickup enabled, sessions are synchronized regardless of TTL. Option D is wrong because session helpers are used for application-layer protocol inspection (e.g., FTP, SIP) and are not required for basic UDP session pickup; the issue is that UDP sessions are not synchronized by default, not that a helper is missing.

Practice this question →

130

MCQmedium

A FortiGate administrator observes that traffic from an internal user to the internet is being blocked. The firewall policy allows the traffic, and the user can ping external hosts. The administrator runs 'diagnose debug flow' for the user's IP and sees 'session denied by forward policy check'. What is the MOST likely cause?

A.There is an implicit deny policy blocking the traffic

B.The antivirus profile has detected a threat and is blocking the session

C.The user's traffic is being rate-limited by a traffic shaper

D.The user's source IP is in a local-in policy that denies the traffic

AnswerA

The forward policy check indicates that no explicit policy matches the traffic, so it is denied by the implicit deny.

Why this answer

The 'session denied by forward policy check' message in a debug flow output indicates that the session was explicitly denied by a firewall policy check, not by a security profile or rate-limiting mechanism. Since the firewall policy allows the traffic, the most likely cause is the implicit deny policy at the end of the policy list, which blocks any traffic that does not match an explicit allow policy. The ability to ping external hosts suggests ICMP is allowed by a separate policy, while TCP/UDP traffic for other services is hitting the implicit deny.

Exam trap

The trap here is that candidates often confuse 'forward policy check' with local-in policies or security profiles, but the debug flow message specifically points to the firewall policy lookup stage, where the implicit deny is the default action when no explicit allow policy matches.

How to eliminate wrong answers

Option B is wrong because an antivirus profile blocking a threat would generate a 'denied by AV profile' or 'virus detected' message in the debug flow, not 'session denied by forward policy check'. Option C is wrong because rate-limiting by a traffic shaper would not deny the session; it would allow the session but shape the traffic, and the debug flow would show 'traffic shaped' or 'rate limited' messages, not a denial. Option D is wrong because a local-in policy controls traffic destined to the FortiGate itself (e.g., management traffic), not traffic passing through the FortiGate (forward traffic), and the debug flow for forward traffic would not reference local-in policies.

Practice this question →

131

MCQhard

A FortiGate cluster (A-P) has a session that is not synchronizing to the secondary unit. The administrator runs 'diagnose sys ha session-sync status' and sees that the session count is different between primary and secondary. Which is the most likely cause?

A.The session is using a custom application control profile that prevents synchronization.

B.The HA heartbeat interface is down.

C.The secondary unit has insufficient memory to accept new sessions.

D.The session was created by a local-in traffic (e.g., management traffic) which is not synchronized.

AnswerD

Local-in sessions are typically not synced across HA members.

Why this answer

FortiGate A-P clusters synchronize sessions via the HA heartbeat interface, but local-in traffic (e.g., management sessions like HTTPS, SSH, or SNMP) is never synchronized because it is destined to the cluster IP itself and is inherently unit-specific. The 'diagnose sys ha session-sync status' command shows a session count mismatch because the primary unit has local-in sessions that the secondary does not replicate, making D the correct answer.

Exam trap

The trap here is that candidates assume all sessions are synchronized by default, but FortiGate explicitly excludes local-in traffic (management sessions) from HA synchronization, so a session count difference is normal and expected for those sessions.

How to eliminate wrong answers

Option A is wrong because application control profiles do not affect session synchronization; they are inspection profiles applied to traffic policies, and session synchronization is controlled by HA settings and session type, not by security profiles. Option B is wrong because if the HA heartbeat interface were down, the cluster would not be able to maintain a synchronized state at all, and the secondary would likely be isolated or the cluster would split-brain; the question states the cluster is operational with a session count difference, not a total sync failure. Option C is wrong because insufficient memory on the secondary would cause it to reject new sessions or fail to synchronize, but the symptom would be a growing session count mismatch over time, not a persistent difference for a specific session; moreover, the secondary would still attempt synchronization and log memory pressure, not simply skip a session silently.

Practice this question →

132

MCQeasy

A FortiGate administrator wants to quickly identify which process is consuming the most CPU on the device. Which CLI command should be used?

A.diagnose hardware sysinfo memory

B.diagnose sys top

C.diagnose debug application crashlog read

D.get system performance status

AnswerB

This command shows real-time process CPU and memory usage, allowing identification of high CPU consumers.

Why this answer

'diagnose sys top' displays a real-time list of running processes sorted by CPU usage, allowing the administrator to quickly identify the most CPU-intensive process. This command is the standard FortiGate CLI tool for live process-level CPU monitoring, similar to the Linux 'top' command.

Exam trap

The trap here is that candidates often confuse 'get system performance status' (which shows aggregate CPU percentage) with the process-level detail needed, leading them to choose option D instead of the correct process-specific command.

How to eliminate wrong answers

Option A is wrong because 'diagnose hardware sysinfo memory' shows memory usage statistics, not CPU consumption by process. Option C is wrong because 'diagnose debug application crashlog read' is used to view crash logs for debugging application failures, not for real-time CPU monitoring. Option D is wrong because 'get system performance status' provides a high-level summary of system resource usage (CPU, memory, sessions) but does not break down CPU usage by individual process.

Practice this question →

133

Multi-Selectmedium

An administrator is configuring a FortiGate to inspect SMTP traffic for spam and viruses. The traffic must be decrypted to inspect the content. Which THREE elements are required for this configuration? (Choose three.)

Select 3 answers

A.A spam filter profile applied to the firewall policy

B.A web filter profile applied to the firewall policy

C.An antivirus profile applied to the firewall policy

D.An application control profile applied to the firewall policy

E.A firewall policy that allows SMTP traffic and has SSL inspection enabled

AnswersA, C, E

Spam filtering is needed to identify and block spam.

Why this answer

A spam filter profile is required to inspect SMTP traffic for spam. FortiGate uses this profile to apply anti-spam techniques such as DNSBL, SURBL, and heuristic analysis on the email content after decryption. Without it, spam detection cannot occur.

Exam trap

The trap here is that candidates often assume a web filter profile can inspect email traffic because it handles content filtering, but web filters are strictly for HTTP/HTTPS protocols and cannot process SMTP MIME data.

Practice this question →

134

MCQhard

A FortiGate is blocking HTTP traffic from 10.0.1.5 to 10.0.2.100, despite an explicit allow policy. The exhibit shows the configuration and debug flow output. What is the most likely cause?

A.The policy is applied to the wrong source interface.

B.The policy action is set to deny.

C.TCP SYN flood protection is dropping the incomplete session.

D.The source address object does not include 10.0.1.5.

AnswerC

The 'state proto not ready' indicates TCP handshake incomplete; often due to DoS protection thresholds.

Why this answer

The debug flow output shows the session is in a 'SYN_RECV' state and never transitions to 'ESTABLISHED', which is characteristic of TCP SYN flood protection. When the FortiGate's SYN flood protection threshold is exceeded, it drops incomplete sessions before they can be fully established, even if an explicit allow policy exists. This explains why HTTP traffic from 10.0.1.5 to 10.0.2.100 is blocked despite the policy being correctly configured.

Exam trap

The trap here is that candidates often assume a policy issue (wrong interface, wrong action, or wrong address object) when the debug flow shows a session being created but not completing, but the real cause is a DoS protection mechanism that drops the session after the initial SYN.

How to eliminate wrong answers

Option A is wrong because if the policy were applied to the wrong source interface, the debug flow would typically show a 'no matching policy' message or a policy lookup failure, not a session stuck in SYN_RECV. Option B is wrong because if the policy action were set to deny, the debug flow would show an explicit deny action or a 'deny' flag in the session table, not a session that is being tracked but never completes. Option D is wrong because if the source address object did not include 10.0.1.5, the policy lookup would fail to match, resulting in a 'no matching policy' or implicit deny, not a session that reaches SYN_RECV and then stalls.

Practice this question →

135

MCQeasy

A network administrator runs 'diagnose sys top' and sees that the 'ipsengine' process is consistently using 99% CPU. What is the BEST immediate action to reduce CPU load?

A.Reboot the FortiGate

B.Increase the session limit

C.Disable IPS inspection on policies that don't require it

D.Change IPS engine to flow-based mode

AnswerC

Disabling IPS reduces CPU usage by the ipsengine process.

Why this answer

The 'ipsengine' process consuming 99% CPU indicates that IPS inspection is being applied to traffic that may not require it, causing excessive processing overhead. Disabling IPS on policies that do not need it (Option C) directly reduces the workload on the IPS engine without affecting other security functions or requiring a reboot. This is the most immediate and targeted action to alleviate CPU pressure.

Exam trap

The trap here is that candidates often assume a reboot or mode change (flow-based) will immediately solve high CPU, but the NSE7 exam tests the understanding that unnecessary inspection is the primary culprit and that targeted policy adjustment is the best immediate action.

How to eliminate wrong answers

Option A is wrong because rebooting the FortiGate is a disruptive, temporary fix that does not address the root cause; the IPS engine will resume high CPU usage once traffic flows again. Option B is wrong because increasing the session limit does not reduce CPU load from IPS processing; it may actually worsen the problem by allowing more sessions to be inspected. Option D is wrong because changing to flow-based mode alters the inspection method but does not eliminate unnecessary IPS scanning; if IPS is still enabled on policies with high traffic, CPU usage may remain high or even increase due to different processing characteristics.

Practice this question →

136

MCQhard

An administrator runs 'diagnose debug application sslvpn -1' and sees repeated 'SSL_ERROR_SSL: error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate'. The SSL-VPN is configured to require client certificates. What is the cause?

A.The client is not sending a client certificate

B.The SSL-VPN server certificate is expired

C.The SSL-VPN tunnel mode is misconfigured

D.The CA certificate is not imported on FortiGate

AnswerA

Correct. The error 'peer did not return a certificate' means the client did not provide the required certificate.

Why this answer

The error 'SSL_ERROR_SSL: error:1417C0C7:SSL routines:tls_process_client_certificate:peer did not return a certificate' occurs during the TLS handshake when the server requests a client certificate and the client fails to provide one. Since the SSL-VPN is configured to require client certificates, the FortiGate expects the client to present a valid certificate; if none is sent, the handshake fails with this specific OpenSSL error. This directly indicates that the client is not sending a client certificate, making option A correct.

Exam trap

The trap here is that candidates may confuse a client certificate not being sent with a CA certificate not being imported on the FortiGate, but the error message explicitly points to the absence of a certificate from the client, not a validation failure after receipt.

How to eliminate wrong answers

Option B is wrong because an expired SSL-VPN server certificate would produce a different error, such as 'certificate expired' or 'certificate verify failed', not a 'peer did not return a certificate' message. Option C is wrong because tunnel mode misconfiguration (e.g., using tunnel mode instead of web mode) affects how traffic is encapsulated, not the TLS client certificate exchange; the error is specific to the SSL handshake layer. Option D is wrong because the CA certificate not being imported on the FortiGate would prevent validation of the client certificate if one were sent, but the error clearly states the peer did not return a certificate at all, indicating the client failed to send one, not that validation failed.

Practice this question →

137

MCQeasy

Which two commands display the current session count on a FortiGate?

A.get system performance status

B.diagnose sys session stat

C.show system session

D.diagnose hardware sysinfo session

AnswerA, B

Correct: 'get system performance status' displays the current session count as part of the performance overview.

Why this answer

Both 'get system performance status' and 'diagnose sys session stat' display the current session count on a FortiGate. 'get system performance status' provides a real-time snapshot including active sessions, while 'diagnose sys session stat' shows session table statistics such as total and used sessions. Therefore, both commands are valid answers to the question.

Exam trap

Candidates often think only 'get system performance status' shows session count, but 'diagnose sys session stat' also provides session statistics including count. The trap is that both commands are valid, making this a multi-select question.

How to eliminate wrong answers

Option B is wrong because 'diagnose sys session stat' displays detailed statistics about session table usage (e.g., total sessions, hash table collisions) but does not directly show the current active session count in a single line; it requires parsing of output. Option C is wrong because 'show system session' is not a valid FortiGate CLI command; the correct syntax for viewing session details is 'diagnose sys session list' or 'get system session' (though the latter is not standard). Option D is wrong because 'diagnose hardware sysinfo session' is not a valid command; the correct command for hardware-related session info is 'diagnose hardware sysinfo' (which shows CPU/memory info) but does not include session count.

Practice this question →

138

Multi-Selectmedium

An administrator is troubleshooting a VPN tunnel that is not coming up. The remote peer is a third-party device. Which THREE actions should be taken to diagnose the issue?

Select 3 answers

A.Ensure that the pre-shared key matches on both sides.

B.Confirm that UDP ports 500 and 4500 are not blocked by any firewall.

C.Verify that the remote peer's IP address is reachable via ping.

D.Check the IPSec VPN logs with 'diag debug application ike -1'.

E.Review the routing table to ensure the remote subnet is reachable through the tunnel interface.

AnswersA, C, D

Mismatched PSK is a common cause of tunnel failure.

Why this answer

IPsec IKE (Internet Key Exchange) uses the pre-shared key (PSK) during authentication phase 1 (Main Mode or Aggressive Mode). If the PSK does not match on both peers, the IKE SA will fail to establish, and the VPN tunnel will not come up. This is a fundamental prerequisite for any IPsec VPN, and mismatched PSKs are a common misconfiguration.

Exam trap

The trap here is that candidates often confuse post-tunnel routing checks (Option E) with pre-tunnel connectivity checks, or they assume firewall port blocking (Option B) is a direct diagnostic step rather than a prerequisite to verify after other checks fail.

Practice this question →

139

MCQmedium

An administrator configured a firewall policy to inspect SMTP traffic using an antivirus profile. However, email attachments are not being scanned. The FortiGate is operating in proxy-based inspection mode. What is the most likely cause?

A.The policy is set to 'accept' instead of 'deny'

B.The email is sent over TLS encryption

C.The antivirus profile is set to flow-based inspection

D.The SMTP session helper is not enabled

AnswerD

Correct. The SMTP helper ensures FortiGate understands the SMTP protocol and can inspect email attachments.

Why this answer

In proxy-based inspection mode, the FortiGate must reassemble the SMTP session to scan attachments. The SMTP session helper is required to parse the SMTP commands and data stream so the antivirus engine can access the attachments. Without the helper enabled, the FortiGate treats the traffic as raw TCP and cannot extract MIME parts for scanning.

Exam trap

The trap here is that candidates often assume antivirus scanning fails due to encryption or policy action, but the NSE7 exam specifically tests the dependency on session helpers for protocol-level inspection in proxy mode.

How to eliminate wrong answers

Option A is wrong because the policy action (accept vs. deny) controls whether traffic is allowed or blocked, not whether scanning occurs; antivirus scanning is applied to accepted traffic. Option B is wrong because TLS encryption prevents inspection only if the antivirus profile does not have a decryption profile or deep inspection enabled; the question does not indicate decryption is configured, but the core issue is the missing session helper, not encryption. Option C is wrong because the antivirus profile's inspection mode (proxy vs. flow) must match the FortiGate's operating mode; the question states the FortiGate is in proxy-based mode, so the profile should also be proxy-based, but the missing session helper is the root cause regardless of profile setting.

Practice this question →

140

MCQmedium

An administrator notices that SD-WAN rule-based traffic is not failing over as expected when the primary link goes down. The SLA targets are configured correctly, and the interface health check is showing 'dead' for the primary link. What is the MOST likely reason for the failover not occurring?

A.The SD-WAN rule's 'set strategy' is 'manual' and the preferred member is still set to the primary interface

B.The SD-WAN rule's 'set status' is set to 'disable'

C.The secondary interface has a higher cost than the primary interface

D.The 'set update-static-route' is not enabled on the SD-WAN

AnswerA

When strategy is 'manual', the rule will not failover automatically; traffic continues to be sent to the preferred member even if the SLA is dead.

Why this answer

When an SD-WAN rule's strategy is set to 'manual', the rule uses a static preferred member list and will not automatically fail over to another member, even if the primary link's SLA health check status is 'dead'. The SLA targets are correctly configured and the health check is detecting the failure, but the manual strategy overrides dynamic path selection, so traffic continues to be sent to the dead primary interface. To enable failover, the strategy must be set to 'optimal' or 'maximize-bandwidth' (or similar dynamic strategy), or the preferred member must be manually updated.

Exam trap

The trap here is that candidates assume a 'dead' SLA health check will automatically trigger failover in all SD-WAN rules, but they overlook that the rule's strategy must be dynamic (e.g., 'optimal') for automatic failover to occur; a 'manual' strategy explicitly prevents this behavior.

How to eliminate wrong answers

Option B is wrong because setting 'set status' to 'disable' would completely disable the SD-WAN rule, preventing any traffic from being processed by it, not just preventing failover. Option C is wrong because interface cost influences route selection in routing tables, not SD-WAN rule-based traffic steering; SD-WAN rules use SLA and strategy, not cost, for failover decisions. Option D is wrong because 'set update-static-route' controls whether the SD-WAN zone updates static routes when the interface status changes, but it does not affect SD-WAN rule-based traffic failover, which is governed by the rule's strategy and SLA configuration.

Practice this question →

141

MCQmedium

When troubleshooting an IPsec VPN phase 1 failure, you run 'diagnose vpn ike config' and see that the remote gateway IP address is incorrect. Which command is used to correct the peer IP configuration?

A.set psksecret <secret>

B.execute vpn tunnel down <tunnel>

C.config vpn ipsec phase1-interface edit <name> set remote-gw <ip>

D.set certificate <name>

AnswerC

This sets the remote gateway IP address.

Why this answer

The 'config vpn ipsec phase1-interface' command allows you to edit the phase1 configuration, and the 'set remote-gw <ip>' command directly corrects the peer IP address. This is the standard FortiGate CLI method to update the remote gateway IP for an IPsec VPN phase1 interface, which is essential for establishing the IKE session.

Exam trap

The trap here is that candidates may confuse operational commands (like 'execute vpn tunnel down') with configuration commands, or mistake authentication settings (PSK or certificate) for peer addressing, leading them to select options that do not actually change the remote gateway IP.

How to eliminate wrong answers

Option A is wrong because 'set psksecret <secret>' configures the pre-shared key, not the remote gateway IP address; it addresses authentication, not peer reachability. Option B is wrong because 'execute vpn tunnel down <tunnel>' only tears down an existing tunnel, but does not modify the configuration; it is a troubleshooting command, not a correction command. Option D is wrong because 'set certificate <name>' assigns a certificate for authentication, which is unrelated to correcting the peer IP address.

Practice this question →