Courseiva

CCNA Troubleshooting and Diagnostics Questions

75 of 112 questions · Page 1/2 · Troubleshooting and Diagnostics · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

An administrator is troubleshooting why a FortiGate is not applying the expected application control profile to traffic from a specific subnet. The administrator wants to verify which application signature is matching a live session in real time. Which CLI command should be used to display the application name and category for active sessions?

A.diagnose sys session filter clear
B.diagnose firewall iprope list
C.diagnose sys session list
D.diagnose debug application ipsmonitor -1
AnswerC

This command lists all active sessions and includes the application name and category if application control is inspecting the session. It provides real-time visibility into which application signature matched, allowing the administrator to confirm whether the correct profile is applied. It is the standard tool for session-level troubleshooting on FortiGate.

Why this answer

The administrator needs to see the application name and category for active sessions. The diagnose sys session list command provides detailed session information, including application identification when application control is enabled. This allows real-time verification of which signature is matching, confirming whether the correct application control profile is applied to the subnet's traffic.

Exam trap

The trap here is assuming that any diagnose debug command will show application identification, when only session listing commands provide that level of detail.

Practice this question →
2
MCQmedium

A FortiGate is configured to send logs to FortiAnalyzer. The administrator notices that logs are not appearing on FortiAnalyzer. Running 'diagnose log device show' shows 'connected=no'. What is the most likely cause?

A.The log rate is too high and logs are being dropped
B.The FortiGate's log buffer is full
C.The FortiGate cannot reach the FortiAnalyzer due to a network issue
D.The FortiAnalyzer license has expired
AnswerC

Connectivity failure is the primary reason for 'connected=no'.

Why this answer

The 'diagnose log device show' output showing 'connected=no' indicates that the TCP connection between the FortiGate and FortiAnalyzer (typically on port 514 for syslog or port 514/3000 for FortiAnalyzer protocol) is not established. The most likely cause is a network issue preventing the FortiGate from reaching the FortiAnalyzer, as the connection status is directly tied to Layer 3 reachability and TCP handshake completion.

Exam trap

The trap here is that candidates often confuse 'connected=no' with log delivery failures caused by high log rates or buffer issues, but the connection status is a Layer 4 TCP state indicator, not a measure of log throughput or storage capacity.

How to eliminate wrong answers

Option A is wrong because a high log rate would cause logs to be dropped or buffered locally, but the connection status ('connected=no') would still show as 'connected=yes' if the TCP session to FortiAnalyzer is up; log dropping does not affect the device connectivity state. Option B is wrong because a full log buffer would cause log loss or overwriting, but the 'connected=no' status indicates the FortiGate has not established a TCP connection to the FortiAnalyzer, which is independent of buffer utilization. Option D is wrong because an expired FortiAnalyzer license would still allow log reception and the TCP connection to remain established; the FortiAnalyzer would simply stop processing or storing logs, but the FortiGate would still show 'connected=yes'.

Practice this question →
3
MCQhard

An administrator is troubleshooting an SD-WAN scenario where traffic from a branch office to a critical SaaS application is experiencing high latency. The SD-WAN rule uses the best quality SLA strategy. The administrator runs 'diagnose sys sdwan neighbor' and sees that both WAN links have SLA compliance above 90%. However, traffic still uses the slower link. The administrator then runs 'diagnose sys sdwan health-check list' and notices that the health-check server IP is different from the SaaS application's server IP. What is the MOST likely reason the traffic is not using the best-performing link?

A.The health-check server's IP does not match the application's destination IP, so SLA measurements are not representative
B.The SD-WAN rule is configured with 'set load-balance-mode' instead of 'best-quality'
C.The health-check server is not reachable from the faster link
D.The SD-WAN rule has a manual routing override configured
AnswerA

SLA probes measure latency to the health-check server, not the SaaS endpoint. When those IPs differ, the best quality strategy selects a link based on unrepresentative measurements, so the genuinely faster path to the application may be ignored.

Why this answer

The SD-WAN rule uses the best quality SLA strategy, which selects the link with the best SLA metrics (latency, jitter, packet loss) for the traffic. However, if the health-check server IP does not match the SaaS application's destination IP, the SLA measurements are not representative of the actual path to the application. The SD-WAN device measures performance to the health-check server, not the application server, so the link that appears best for the health-check may be worse for the actual application traffic, causing the slower link to be selected.

Exam trap

The trap here is that candidates assume high SLA compliance on both links means the best link will always be selected, but they overlook that the health-check target must match the application destination for SLA measurements to be relevant.

How to eliminate wrong answers

Option B is wrong because the question states the SD-WAN rule uses the best quality SLA strategy, so 'set load-balance-mode' is not configured; if it were, traffic would be distributed based on load balancing, not SLA quality. Option C is wrong because if the health-check server were not reachable from the faster link, the SLA would show non-compliance for that link, but the output shows both links have SLA compliance above 90%. Option D is wrong because a manual routing override would bypass SD-WAN policy entirely, but the administrator is observing SD-WAN behavior (traffic using a slower link despite SLA compliance), and the diagnostic commands confirm SD-WAN is active.

Practice this question →
4
MCQeasy

A network administrator runs 'get system ha status' on a FortiGate HA cluster and sees that only one unit shows as primary. The secondary unit shows as 'standalone' with no HA peer detected. What is the MOST likely cause of this issue?

A.The cluster serial numbers do not match
B.The heartbeat interface is down or misconfigured
C.The HA group ID is different on each unit
D.The HA priority on the secondary unit is set to 0
AnswerB

A secondary showing standalone means it never received HA heartbeat packets, so the cluster never formed. Heartbeat interfaces must be correctly cabled and configured on both units; if that link is down or mismatched, the peer is undetectable, producing exactly this split state.

Why this answer

When a secondary unit shows as 'standalone' with no HA peer detected, it indicates that the heartbeat communication between the two FortiGate units has failed. The most common cause is that the heartbeat interface is down, misconfigured, or not physically connected, preventing the units from discovering each other as HA peers. Without a functioning heartbeat link, the secondary unit cannot join the cluster and remains in standalone mode.

Exam trap

The trap here is that candidates often confuse 'no HA peer detected' with configuration mismatches like serial numbers or group IDs, but those mismatches still allow peer detection and generate specific error messages, whereas a failed heartbeat link results in a complete lack of peer visibility.

How to eliminate wrong answers

Option A is wrong because mismatched serial numbers would cause the units to reject each other as valid HA members, but the secondary unit would still detect the peer and show an error or 'mismatch' status, not 'standalone'. Option C is wrong because a different HA group ID would prevent the units from forming a cluster, but the secondary unit would still see the peer and report a group ID mismatch, not a 'no HA peer detected' state. Option D is wrong because setting the HA priority to 0 on the secondary unit would not prevent it from detecting the primary; it would simply make the secondary unit ineligible to become primary, but it would still join the cluster and show as a secondary member.

Practice this question →
5
MCQmedium

An administrator configures BGP route advertisement but the routes are not being sent to the neighbor. The BGP session is established. What is the MOST likely cause?

A.The BGP administrative distance is set too high
B.The BGP neighbor has the wrong update-source interface
C.The route is filtered by a route-map
D.The 'network' statement is missing for the desired prefix
AnswerD

In BGP, the 'network' statement is what injects a prefix from the routing table into BGP for advertisement. Without it, no matching route is originated, so the established session carries no updates for that prefix to the neighbour.

Why this answer

The BGP session is established, so Layer 3 connectivity and TCP port 179 are working. The most common reason for routes not being advertised to a neighbor is that the 'network' statement is missing for the desired prefix. In BGP, the 'network' command does not advertise the prefix unless it matches an exact route in the IP routing table; without it, BGP has no prefix to send, even if the session is up.

Exam trap

The trap here is that candidates often assume a BGP session being established guarantees route advertisement, but BGP requires explicit 'network' statements or redistribution to inject prefixes, and the session state only indicates TCP connectivity and BGP open message exchange.

How to eliminate wrong answers

Option A is wrong because BGP administrative distance (e.g., 20 for eBGP, 200 for iBGP) affects route preference in the routing table, not the advertisement of routes to a neighbor. Option B is wrong because the update-source interface only affects the source IP of BGP packets; if the session is already established, the update-source is correctly configured, so it cannot be the cause of missing route advertisements. Option C is wrong because while a route-map can filter routes, the question states the session is established and routes are not being sent; a missing 'network' statement is a more fundamental and likely cause than a route-map, which would require explicit configuration to block routes.

Practice this question →
6
Multi-Selectmedium

An administrator is troubleshooting high CPU usage on a FortiGate. The administrator suspects that a specific process is causing the issue. Which TWO commands should the administrator use to identify the top CPU-consuming processes? (Choose two.)

Select 2 answers
A.get system performance status
B.diagnose sys top-summary
C.diagnose sys session list
D.diagnose sys top
E.diagnose hardware sysinfo memory
AnswersB, D

The 'diagnose sys top-summary' command provides a summary of CPU usage by process, showing the top consumers in a concise format. It is ideal for quickly identifying which processes are using the most CPU without the interactive display of 'diagnose sys top'. This command is specifically designed for performance troubleshooting.

Why this answer

To identify the top CPU-consuming processes, the administrator should use commands that provide per-process CPU usage. 'diagnose sys top' offers an interactive real-time view, while 'diagnose sys top-summary' provides a concise summary. Both are effective for pinpointing the process responsible for high CPU.

Exam trap

The trap here is assuming that general system performance commands like 'get system performance status' provide per-process CPU details, when they only give overall statistics.

Practice this question →
7
MCQeasy

An administrator needs to monitor the FortiGate's CPU usage in real-time from the CLI. Which command should be used?

A.diagnose debug application httpsd
B.diagnose hardware sysinfo memory
C.get system performance status
D.diagnose sys top
AnswerD

`diagnose sys top` launches an interactive, continuously refreshing process monitor directly in the CLI, listing per-process CPU and memory consumption. This satisfies the stem's real-time requirement, unlike snapshot commands such as `get system performance status`, which report averaged or instantaneous values without live refresh.

Why this answer

'diagnose sys top' is the FortiGate CLI command that provides a real-time, top-like display of CPU usage per process, including process IDs and CPU consumption percentages. This command is specifically designed for live performance monitoring and troubleshooting from the CLI, unlike static snapshots or debug outputs.

Exam trap

The trap here is that candidates often confuse 'get system performance status' (a static snapshot) with a real-time monitoring tool, or they mistakenly think debug commands like 'diagnose debug application' are used for performance metrics instead of debugging specific daemon logs.

How to eliminate wrong answers

Option A is wrong because 'diagnose debug application httpsd' enables debug logging for the HTTPS daemon, not CPU monitoring; it outputs verbose HTTP-related debug messages. Option B is wrong because 'diagnose hardware sysinfo memory' displays memory usage statistics (total, used, free), not CPU usage. Option C is wrong because 'get system performance status' shows a static summary of CPU, memory, and session utilization at the moment of execution, but it does not provide the real-time, continuously updating process-level view that 'diagnose sys top' offers.

Practice this question →
8
MCQeasy

An administrator needs to verify if a FortiGate is receiving BGP routes from a peer. Which command should the admin run to see the BGP routing table?

A.get router info routing-table bgp
B.show ip bgp
C.diagnose ip router bgp table
D.get router info bgp table
AnswerD

The get router info bgp table command displays the BGP routing table, showing prefixes learned from each peer and their attributes. This directly confirms whether routes are being received from the neighbour, satisfying the stem's requirement to verify inbound BGP advertisements.

Why this answer

'get router info bgp table' is the exact FortiOS CLI command to display the BGP routing table, showing all BGP-learned routes and their attributes. This command is specific to FortiGate's proprietary CLI syntax, which differs from Cisco IOS or generic Linux networking commands. The administrator needs this output to verify received BGP prefixes from a peer.

Exam trap

The trap here is that candidates familiar with Cisco IOS might instinctively choose 'show ip bgp' (Option B) or misremember FortiGate syntax as similar to Cisco's 'show ip bgp table', but FortiGate uses a distinct CLI structure where 'get router info bgp table' is the correct command for viewing the BGP table.

How to eliminate wrong answers

Option A is wrong because 'get router info routing-table bgp' is not a valid FortiOS command; the correct syntax for viewing the routing table filtered by BGP is 'get router info routing-table bgp' on FortiGate, but this shows the actual routing table (RIB) entries, not the raw BGP table (Adj-RIB-In). Option B is wrong because 'show ip bgp' is a Cisco IOS command, not a FortiGate command; FortiGate uses 'get' instead of 'show' and has different syntax. Option C is wrong because 'diagnose ip router bgp table' is not a valid FortiOS command; the 'diagnose' commands are for debugging and do not include a 'table' subcommand for BGP.

Practice this question →
9
Multi-Selecthard

A FortiGate administrator is investigating a slow network performance issue. The administrator suspects that session table limits are being reached. Which TWO metrics should be monitored to confirm this? (Choose two.)

Select 2 answers
A.Interface bandwidth utilization
B.Session fail rate
C.Current session count
D.CPU usage
E.Memory usage
AnswersB, C

Session fail rate counts new sessions rejected because the session table is full. A rising fail rate directly evidences that the configured session limit is being reached, confirming the suspected cause of the slow network performance.

Why this answer

The session fail rate (B) directly indicates when the FortiGate is unable to establish new sessions because the session table is full, which is a clear symptom of hitting session table limits. The current session count (C) shows how many sessions are active; when this approaches the maximum session limit (e.g., 2 million on a FortiGate-600E), it confirms the table is near capacity. Monitoring both metrics together provides definitive evidence of session table exhaustion.

Exam trap

The NSE7 exam often tests the misconception that high CPU or memory usage directly indicates session table limits, but the trap here is that session table exhaustion is specifically confirmed by session fail rate and current session count, not by general resource utilization metrics.

Practice this question →
10
Multi-Selectmedium

An administrator is troubleshooting an IPsec VPN tunnel that establishes phase 1 but fails to establish phase 2. The phase 2 configuration shows 'set proposal aes128-sha256' on both sides. Which TWO configuration items should the administrator verify?

Select 2 answers
A.PFS (Perfect Forward Secrecy) settings
B.The local authentication method (certificate vs pre-shared key)
C.The encryption algorithm for phase 2
D.The local and remote subnets defined in phase 2 (proxy IDs)
E.The pre-shared key
AnswersA, D

If one side has PFS enabled and the other does not, or they use different DH groups, phase 2 will fail.

Why this answer

PFS ensures that if one session key is compromised, previous and future session keys remain secure by using a Diffie-Hellman exchange in phase 2. If PFS is enabled on one side but not the other, or if the DH groups do not match, phase 2 will fail even when the encryption and authentication proposals are identical. Since the phase 2 proposal 'aes128-sha256' matches on both sides, the mismatch likely lies in PFS settings.

Exam trap

The trap here is that candidates assume matching encryption and authentication proposals guarantee phase 2 success, overlooking PFS and proxy ID mismatches which are frequently tested in NSE7 troubleshooting scenarios.

Practice this question →
11
Multi-Selecteasy

A FortiGate administrator wants to monitor performance thresholds to be alerted when the firewall is under heavy load. Which THREE metrics can be monitored using the built-in performance monitoring features (e.g., 'diagnose sys top' or SNMP)?

Select 3 answers
A.CPU utilization percentage
B.Interface speed
C.Number of concurrent sessions
D.Disk space utilization
E.Memory utilization percentage
AnswersA, C, E

CPU usage is a critical performance indicator.

Why this answer

The built-in 'diagnose sys top' command and SNMP monitoring both provide real-time CPU utilization percentage, which is a key metric for detecting heavy load on a FortiGate firewall. High CPU usage can indicate resource contention, impacting packet processing and overall performance.

Exam trap

The trap here is that candidates confuse static interface properties (like speed) with dynamic performance metrics, or mistakenly think disk space is relevant to firewall load, when in fact only CPU, memory, and session counts are directly monitored for performance thresholds.

Practice this question →
12
Multi-Selecthard

An administrator is troubleshooting an IPsec VPN Phase 2 negotiation failure. The debug shows 'no matching phase 2 proposal' from the remote peer. Which TWO of the following are likely causes? (Choose two.)

Select 2 answers
A.The local and remote proxy IDs (subnets) are not matching
B.The pre-shared key is incorrect
C.The firewall policy does not allow UDP port 500
D.The encryption algorithm (e.g., AES256 vs AES128) does not match between peers
E.The IKE version (IKEv1 vs IKEv2) is different
AnswersA, D

Phase 2 requires matching proxy IDs to establish SAs.

Why this answer

IPsec Phase 2 negotiation requires the proxy IDs (local and remote subnets) to match exactly between peers. The 'no matching phase 2 proposal' debug message indicates the remote peer received a proposal with a subnet or traffic selector that does not match its configured proxy ID. This is a common misconfiguration when defining which traffic should be encrypted over the VPN tunnel.

Exam trap

The trap here is that candidates often confuse Phase 1 and Phase 2 parameters, incorrectly attributing a Phase 2 'no matching proposal' error to authentication or IKE version mismatches, which actually cause Phase 1 failures.

Practice this question →
13
Multi-Selectmedium

A network administrator is troubleshooting a split-brain scenario in an HA cluster. Which TWO conditions can cause split-brain? (Choose two.)

Select 2 answers
A.Loss of heartbeat link between HA members
B.One unit has a higher priority
C.Firmware version mismatch
D.Mismatched HA configuration (e.g., different HA mode)
E.Session pickup is disabled
AnswersA, D

Loss of the heartbeat link severs the dedicated HA communication path, so each FortiGate independently concludes the peer has failed and transitions to primary. Both devices then hold the same IP addresses and MAC addresses, producing the duplicate-active condition the stem describes. This satisfies the split-brain cause directly.

Why this answer

Options A and D are correct. Loss of HA heartbeat communication (A) causes both units to think they are primary. Mismatched HA configuration (D) can also cause split-brain.

Option B causes failover but not split-brain. Option C is irrelevant.

Practice this question →
14
Multi-Selectmedium

An admin is troubleshooting an IPsec VPN tunnel that is failing phase 2. The IKE debug shows 'no matching proposal'. Which TWO settings should the admin verify on both sides? (Choose two.)

Select 2 answers
A.Dead Peer Detection interval
B.Encryption algorithm (e.g., AES128, AES256)
C.Diffie-Hellman group for PFS
D.Pre-shared key
E.Local and remote gateway IP addresses
AnswersB, C

Phase 2 (Quick Mode) negotiates the IPsec SA using the Phase 2 proposal, so a mismatch in the encryption algorithm between peers produces exactly the "no matching proposal" error. Verifying AES128 or AES256 on both gateways ensures the Phase 2 encryption transforms align, satisfying the stem's requirement to resolve the failing negotiation.

Why this answer

In IPsec phase 2, the IKE debug message 'no matching proposal' indicates a mismatch in the security association (SA) parameters used to establish the IPsec SA. The encryption algorithm (option B) is a core component of the IPsec proposal that must match exactly on both peers. Perfect Forward Secrecy (PFS) using a Diffie-Hellman group (option C) is also negotiated during phase 2; if one side requires PFS and the other does not, or if the DH groups differ, phase 2 will fail with this error.

Exam trap

The trap here is that candidates often confuse phase 1 and phase 2 parameters, incorrectly selecting pre-shared key (option D) or gateway IPs (option E) as causes for a phase 2 proposal mismatch, when in fact only the IPsec SA parameters (encryption, authentication, PFS) are negotiated in phase 2.

Practice this question →
15
MCQmedium

A FortiGate administrator is troubleshooting a VPN tunnel that connects to a remote site. The tunnel is up, but traffic is not passing. The administrator checks the Phase 2 settings and sees that the local and remote subnets are correctly defined. What is the next step to diagnose the issue?

A.Check the firewall policies that reference the VPN interface
B.Check the routing table for the remote subnet
C.Run 'diagnose vpn ike log' to check for Phase 1 errors
D.Restart the VPN tunnel
AnswerA

Phase 2 selectors can match correctly while firewall policies referencing the VPN interface still block traffic, since policy lookup governs whether decrypted packets are permitted. Checking those policies is the logical next diagnostic step after confirming subnet definitions.

Why this answer

When the VPN tunnel is up (Phase 1 and Phase 2 are established) but traffic is not passing, the most common cause is that a firewall policy referencing the VPN interface is either missing or misconfigured. Even with correct Phase 2 selectors and routing, the FortiGate will drop traffic if no policy explicitly permits it from the source to the destination over the VPN interface. Therefore, checking the firewall policies is the logical next step.

Exam trap

The trap here is that candidates assume a working Phase 2 (tunnel up) guarantees traffic flow, but FortiGate requires an explicit firewall policy to permit traffic through the VPN interface, unlike some other vendors where a route alone is sufficient.

How to eliminate wrong answers

Option B is wrong because if the tunnel is up and Phase 2 subnets are correctly defined, the routing table for the remote subnet is typically already present (either statically or via dynamic routing); a missing route would prevent the tunnel from coming up or cause Phase 2 to fail, not just block traffic. Option C is wrong because 'diagnose vpn ike log' is used to debug Phase 1 (IKE) issues, but the tunnel is already up, indicating Phase 1 completed successfully; this command would not reveal why traffic is not passing through an established tunnel. Option D is wrong because restarting the VPN tunnel is a brute-force approach that does not diagnose the root cause; if the tunnel is up and the configuration is correct, restarting it will not resolve a missing or misconfigured firewall policy.

Practice this question →
16
MCQmedium

A network administrator is troubleshooting an IPsec VPN tunnel that fails to establish. The remote gateway logs show a proposal mismatch. On FortiGate, the administrator runs 'diagnose vpn ike config' and sees 'proposal: aes128-sha1, aes256-sha256'. The remote side expects 'aes256-sha1'. What is the most likely cause?

A.The Phase 1 proposal list does not include the algorithm combination the remote gateway requires
B.The pre-shared key is incorrect
C.The Phase 2 selectors are misconfigured
D.The IKE version is set to 1 but remote uses 2
AnswerA

Phase 1 negotiation selects a matching proposal from both peers' lists. The remote expects aes256-sha1, which is absent from the local list containing only aes128-sha1 and aes256-sha256, so no common combination exists and the tunnel fails.

Why this answer

The 'diagnose vpn ike config' output shows the FortiGate's Phase 1 proposal list includes 'aes128-sha1' and 'aes256-sha256', but the remote gateway expects 'aes256-sha1'. Since neither of the local proposals matches the remote's required combination, the IKE negotiation fails with a 'proposal mismatch' error. The administrator must add 'aes256-sha1' to the Phase 1 proposal list on the FortiGate to align with the remote gateway's expectation.

Exam trap

The trap here is that candidates often confuse a proposal mismatch with a pre-shared key or IKE version issue, but the specific error message and the 'diagnose vpn ike config' output directly point to an algorithm mismatch in Phase 1, not authentication or version negotiation.

How to eliminate wrong answers

Option B is wrong because a pre-shared key mismatch typically results in an authentication failure, not a proposal mismatch; the logs would show 'authentication failed' or 'invalid cookie' rather than a proposal error. Option C is wrong because Phase 2 selectors (traffic selectors) are negotiated after Phase 1 is established, so a Phase 2 misconfiguration would cause the tunnel to fail later, not prevent Phase 1 from completing. Option D is wrong because an IKE version mismatch (v1 vs v2) would produce a different error, such as 'no acceptable proposal' or 'unsupported IKE version', not a proposal mismatch on algorithms; the proposal mismatch specifically refers to encryption/hash algorithms, not the IKE version.

Practice this question →
17
MCQeasy

An administrator wants to monitor the session count on a FortiGate in real time. Which CLI command provides this information?

A.diagnose sys top
B.get system performance status
C.diagnose sys session stat
D.diagnose debug enable
AnswerC

diagnose sys session stat returns real-time session counts and memory usage for the session table, giving the administrator an immediate snapshot. It reads current session statistics directly, unlike log or policy commands that do not expose live session totals.

Why this answer

'diagnose sys session stat' is the specific FortiGate CLI command that displays real-time session statistics, including the total number of sessions currently tracked by the firewall. This command provides a live count of active sessions, which is exactly what the administrator needs for real-time monitoring.

Exam trap

The trap here is confusing general performance monitoring commands (like 'get system performance status') with session-specific diagnostics, leading candidates to select options that show system health but not the exact session count required.

How to eliminate wrong answers

Option A is wrong because 'diagnose sys top' shows real-time CPU and memory usage per process, not session counts. Option B is wrong because 'get system performance status' displays overall system performance metrics like CPU load and memory usage, but does not include session count details. Option D is wrong because 'diagnose debug enable' is used to enable debug output for troubleshooting, not to display session statistics.

Practice this question →
18
MCQeasy

An administrator applies the above policy but users from 10.0.1.0/24 cannot access web servers at 10.0.2.0/24. However, they can ping the servers. What is the most likely cause?

A.The service 'HTTP' does not include port 443 or the web application is using HTTPS.
B.The destination address is incorrect.
C.The schedule 'always' is not correctly configured.
D.The source interface is incorrect.
AnswerA

ICMP succeeds because ping is permitted, but the policy's HTTP service object covers only port 80. If the web application serves HTTPS on port 443, that traffic matches no allowing policy and is dropped, blocking access.

Why this answer

The policy allows HTTP traffic (port 80), but the web servers are likely using HTTPS (port 443). Since the service object 'HTTP' in FortiGate typically only includes TCP/80, HTTPS traffic is denied by default. The administrator can ping the servers because ICMP is permitted by an implicit or explicit policy, confirming that routing and connectivity are functional.

Exam trap

The trap here is that candidates assume 'HTTP' covers all web traffic, but FortiGate strictly matches the defined ports in the service object, so HTTPS (port 443) is blocked unless explicitly permitted.

How to eliminate wrong answers

Option B is wrong because the destination address 10.0.2.0/24 is correct for the web servers, and ping success confirms reachability. Option C is wrong because the schedule 'always' is a default, always-active schedule that cannot be misconfigured; if it were invalid, no traffic would pass. Option D is wrong because the source interface is correctly set to the interface connected to 10.0.1.0/24, as evidenced by successful ping traffic from that subnet.

Practice this question →
19
MCQhard

An administrator is investigating a security incident and needs to view raw logs from a FortiAnalyzer for a specific time range. The administrator wants to ensure the logs are not aggregated or summarized. Which type of log view should be used?

A.Event Management
B.FortiView
C.Reports
D.Log View
AnswerD

Log View presents raw, unaggregated log entries for the selected time range, preserving each individual event. Other views roll records into summaries or charts, which would hide the granular detail the administrator needs during incident investigation.

Why this answer

The Log View in FortiAnalyzer displays raw, unaggregated logs exactly as received from FortiGate devices, making it the correct choice for viewing logs without summarization. Unlike other views that pre-process or summarize data, Log View provides direct access to the original log entries for a specified time range, which is essential for detailed incident investigation.

Exam trap

The trap here is that candidates confuse FortiView's real-time graphical summaries with raw log access, assuming 'Log View' is just another dashboard, when in fact FortiView aggregates data and Log View shows the original unmodified logs.

How to eliminate wrong answers

Option A is wrong because Event Management aggregates and correlates logs into events, summarizing multiple log entries into a single event record, which does not show raw logs. Option B is wrong because FortiView provides pre-processed, summarized graphical views and dashboards that aggregate data for quick analysis, not raw logs. Option C is wrong because Reports generate summarized, formatted output based on templates and scheduled aggregation, not the original unaggregated log entries.

Practice this question →
20
MCQhard

An administrator is troubleshooting an HA cluster (active-passive) where both units show 'primary' in 'get system ha status'. The cluster is not synchronizing configurations. What is the MOST likely cause?

A.The HA password is incorrect
B.The HA heartbeat interface is disconnected or misconfigured
C.The HA group ID is mismatched
D.The HA priority values are equal for both units
AnswerB

If heartbeat communication fails, each unit assumes the other is down and transitions to primary, causing a split-brain.

Why this answer

In an active-passive HA cluster, both units showing 'primary' indicates a failure in heartbeat communication. The HA heartbeat interface is used to exchange cluster state and session information; if it is disconnected or misconfigured, each unit assumes the other is down and transitions to primary, leading to a split-brain scenario. This prevents configuration synchronization because the units cannot agree on a primary-secondary role.

Exam trap

The trap here is that candidates often assume an HA password mismatch or group ID mismatch causes role conflicts, but in reality, a heartbeat failure is the only scenario that makes both units independently declare themselves primary.

How to eliminate wrong answers

Option A is wrong because an incorrect HA password would cause authentication failures during heartbeat exchanges, but both units would still show their correct roles (primary/secondary) based on priority; they would not both become primary. Option C is wrong because a mismatched HA group ID would prevent the cluster from forming entirely, resulting in both units showing as standalone or 'standalone', not both as 'primary'. Option D is wrong because equal HA priority values do not cause both units to become primary; in an active-passive cluster, if priorities are equal, the unit with the higher serial number becomes primary, and the other becomes secondary, so both would not show 'primary'.

Practice this question →
21
MCQmedium

A FortiGate VPN tunnel shows 'phase1 negotiation failed' in the logs. The remote gateway is a third-party device. The debug command 'diagnose vpn ike config' shows mismatched proposals. Which setting is MOST likely incorrect on the FortiGate?

A.The pre-shared key
B.The local ID type
C.The encryption algorithm (e.g., AES256 vs 3DES)
D.The DPD configuration
AnswerC

Phase 1 negotiation fails when the two peers' IKE proposals do not intersect. A mismatched encryption algorithm, such as AES256 against 3DES, means no common transform is offered, so the FortiGate's phase 1 proposal must be aligned with the third-party gateway's supported encryption.

Why this answer

The 'diagnose vpn ike config' command displays the IKE proposal parameters (encryption, authentication, DH group) that the FortiGate is configured to offer. When the log shows 'phase1 negotiation failed' and the debug output indicates 'mismatched proposals', it means the FortiGate's configured encryption algorithm (e.g., AES256) does not match any algorithm supported by the remote third-party device (e.g., 3DES). This is the most direct cause of proposal mismatch, as IKE phase 1 requires both sides to agree on a common transform set.

Exam trap

The trap here is that candidates often confuse 'mismatched proposals' with authentication failures (pre-shared key) or identification issues (local ID), but the debug command specifically shows the proposal attributes, making encryption algorithm the most likely culprit.

How to eliminate wrong answers

Option A is wrong because a pre-shared key mismatch would cause an authentication failure after the proposal is accepted, not a 'mismatched proposals' error in the IKE config debug. Option B is wrong because the local ID type is used for identification and policy matching after phase 1 is established; it does not affect the initial proposal exchange. Option D is wrong because DPD (Dead Peer Detection) is a keepalive mechanism configured after phase 1 is complete; a DPD mismatch would not cause a phase 1 negotiation failure.

Practice this question →
22
MCQeasy

A FortiGate administrator needs to verify that the firewall is correctly identifying and logging a specific application, 'Facebook', that is being used by internal users. The administrator has already configured an application control profile with logging enabled for Facebook. Which CLI command should the administrator use to view the application control logs in real-time?

A.diagnose debug enable
B.diagnose debug application appctrl -1
C.diagnose sys session list
D.diagnose debug application ipsmonitor -1
AnswerB

The command 'diagnose debug application appctrl -1' enables debug output for the application control daemon, which shows real-time information about application identification and logging. This allows the administrator to see when Facebook is detected and logged. It is the most direct way to verify application control logging in real-time.

Why this answer

To view application control logs in real-time, the administrator should use the debug command for the application control daemon. The 'diagnose debug application appctrl -1' command provides detailed output about application identification and logging decisions. This is more specific than general debug commands and directly addresses the need to verify that Facebook is being identified and logged.

Other commands like ipsmonitor debug or session list do not provide the same level of detail for application control logs.

Exam trap

The trap here is confusing IPS engine debugging with application control debugging; they are separate processes, and only the appctrl debug shows application control logs.

Practice this question →
23
MCQmedium

A FortiGate administrator is troubleshooting high CPU usage. The administrator runs 'diagnose sys top' and sees that the 'ipsengine' process is consuming a large amount of CPU. Which action should the administrator take to reduce the CPU usage while maintaining security?

A.Disable IPS globally.
B.Adjust the IPS fail-open setting to enable fail-open.
C.Increase the FortiGate's memory allocation to the ipsengine process.
D.Review and optimize the IPS sensor configuration to reduce the number of signatures or adjust anomaly thresholds.
AnswerD

Optimizing the IPS sensor by removing unnecessary signatures, adjusting thresholds, or applying IPS only to relevant policies can significantly reduce CPU usage while still providing essential protection. This approach maintains security by focusing on the most critical threats and avoiding unnecessary inspection overhead.

Why this answer

The ipsengine process handles IPS inspection. High CPU usage can be mitigated by optimizing the IPS sensor configuration, such as disabling signatures that are not relevant to the environment, reducing the number of policies with IPS enabled, or adjusting anomaly thresholds. This maintains security by keeping essential protections while reducing the processing load.

Exam trap

The trap here is thinking that disabling IPS or enabling fail-open are acceptable trade-offs, but they weaken security; optimization is the better approach.

Practice this question →
24
MCQeasy

Which FortiGate command is used to view the current CPU usage of individual processes in real time?

A.diagnose sys session stat
B.get system performance status
C.diagnose sys top
D.diagnose hardware sysinfo memory
AnswerC

`diagnose sys top` refreshes process-level CPU and memory statistics live, satisfying the real-time per-process requirement. Unlike `get system performance status`, which reports only aggregate CPU averages, it lists each running process individually, letting you identify the specific daemon consuming resources.

Why this answer

The 'diagnose sys top' command on FortiGate provides a real-time, top-like display of CPU and memory usage for individual processes, allowing administrators to identify which specific daemons or tasks are consuming resources. This command is essential for troubleshooting performance issues at the process level, unlike other commands that show aggregate or different diagnostic data.

Exam trap

The trap here is that candidates often confuse 'get system performance status' (which shows overall CPU usage) with the per-process view needed for granular troubleshooting, leading them to select option B instead of the correct 'diagnose sys top'.

How to eliminate wrong answers

Option A is wrong because 'diagnose sys session stat' displays session statistics (total sessions, active sessions, etc.) and does not show CPU usage per process. Option B is wrong because 'get system performance status' shows overall system performance metrics (CPU, memory, disk) but not per-process CPU usage in real time. Option D is wrong because 'diagnose hardware sysinfo memory' reports memory hardware information and usage statistics, not CPU usage per process.

Practice this question →
25
MCQeasy

A FortiGate administrator needs to identify which process is consuming the most memory. Which command should be used?

A.diagnose sys top
B.show system resource usage
C.diagnose hardware sysinfo memory
D.get system performance status
AnswerA

The diagnose sys top command displays a live, refreshable list of running FortiGate processes ranked by CPU and memory consumption. This directly identifies the process using the most memory, which is the administrator's stated goal.

Why this answer

The 'diagnose sys top' command displays a real-time list of running processes sorted by CPU and memory usage, allowing the administrator to identify which process is consuming the most memory. This is the standard FortiGate CLI command for process-level resource monitoring, similar to 'top' on Linux systems.

Exam trap

The trap here is that candidates may confuse system-level memory commands (like 'diagnose hardware sysinfo memory' or 'show system resource usage') with process-level memory diagnostics, assuming any 'memory' or 'resource' command will show per-process details.

How to eliminate wrong answers

Option B is wrong because 'show system resource usage' displays overall system resource statistics (CPU, memory, disk) but does not break down memory usage by individual process. Option C is wrong because 'diagnose hardware sysinfo memory' shows hardware-level memory information (total, used, free) and memory module details, not per-process memory consumption. Option D is wrong because 'get system performance status' provides a summary of system performance metrics (CPU, memory, sessions) but lacks process-level granularity.

Practice this question →
26
Multi-Selectmedium

An administrator is troubleshooting a BGP session that is not establishing between two FortiGates. The administrator has verified that the neighbor IP is reachable. Which TWO commands should be used to further diagnose the issue? (Choose two.)

Select 2 answers
A.get router info bgp neighbor <IP>
B.diagnose debug flow filter daddr <IP>
C.get router info routing-table bgp
D.diagnose sys session filter dport 179
E.diagnose ip router bgp all enable
AnswersA, E

This command shows BGP session state and counters, useful for troubleshooting.

Why this answer

'get router info bgp neighbor <IP>' displays detailed BGP session state information, including the current state (e.g., Idle, Connect, Active, OpenSent, OpenConfirm, Established), hold timer, keepalive interval, and any error codes or notifications. This command directly reveals why the session is not establishing, such as a mismatch in BGP capabilities, AS numbers, or authentication.

Exam trap

The trap here is that candidates often confuse general network troubleshooting commands (like session filtering or flow debugging) with BGP-specific diagnostic commands, failing to recognize that BGP session establishment requires examining the BGP state machine and debug logs, not just TCP connectivity or routing table contents.

Practice this question →
27
Multi-Selectmedium

A FortiGate administrator is troubleshooting an issue where users are unable to access a web server behind the FortiGate. The web server is on the DMZ network, and users are on the internal network. The firewall policy from internal to DMZ is configured to allow HTTP and HTTPS. The administrator runs 'diagnose debug flow' and sees that packets are being dropped with the message 'iprope_in_check() check failed, drop'. Which two actions should the administrator take to resolve this issue? (Choose two.)

Select 2 answers
A.Verify that the firewall policy from internal to DMZ is correctly configured with the correct source and destination interfaces and addresses.
B.Check the FortiGate's ARP table for the web server's MAC address.
C.Verify that the web server is listening on the correct ports and is reachable from the FortiGate.
D.Ensure that the policy is placed in the correct order in the firewall policy list, as a previous policy might be blocking the traffic.
E.Check the routing table to ensure there is a route to the DMZ network.
AnswersA, D

The drop occurs during inbound policy check, which means the packet does not match any policy. Checking the policy configuration ensures that the source interface (internal), destination interface (DMZ), and addresses are correct. A misconfiguration here would cause the drop.

Why this answer

The 'iprope_in_check()' drop indicates that the packet failed the inbound policy check. This can happen if the policy is misconfigured, such as incorrect interfaces or addresses, or if a preceding policy is denying the traffic. Therefore, verifying the policy configuration and its order are the correct actions.

Routing and server-side issues would produce different symptoms.

Exam trap

The trap here is assuming that routing or server issues cause the policy check failure, when in fact the drop is specifically due to policy lookup, so policy configuration and order must be examined.

Practice this question →
28
MCQhard

An administrator configures an ALG for SIP traffic but notices that some SIP calls are failing. The admin suspects the ALG is modifying SIP headers incorrectly. Which debug command can help verify the ALG's actions on SIP packets?

A.diagnose debug application sip -1
B.diagnose debug application alg -1
C.get system performance status
D.diagnose sys session filter proto 17
AnswerA

diagnose debug application sip -1 enables verbose SIP ALG debugging, printing how the ALG parses and rewrites SIP headers and SDP. This directly exposes incorrect header modifications causing call failures, satisfying the administrator's need to verify ALG behaviour on live traffic.

Why this answer

The command 'diagnose debug application sip -1' enables detailed debugging of the SIP ALG process on FortiGate, showing how the ALG inspects and modifies SIP headers (e.g., Via, Contact, SDP). This allows the admin to verify if the ALG is incorrectly rewriting IP addresses or ports, which is a common cause of call failures. The '-1' flag sets the debug level to maximum verbosity, capturing all ALG-related SIP transactions.

Exam trap

The trap here is that candidates confuse the generic 'debug application alg' command with the protocol-specific debug commands, or they assume 'get system performance status' can diagnose ALG issues, when in fact only the protocol-specific debug (e.g., 'debug application sip') reveals header-level modifications.

How to eliminate wrong answers

Option B is wrong because 'diagnose debug application alg -1' is not a valid command; the correct syntax for debugging an ALG requires specifying the application protocol (e.g., 'sip', 'h323') after 'application', not 'alg' itself. Option C is wrong because 'get system performance status' shows system resource usage (CPU, memory) and does not provide packet-level or ALG-specific header modification details. Option D is wrong because 'diagnose sys session filter proto 17' filters sessions by protocol number 17 (UDP), which is useful for narrowing session dumps but does not debug ALG actions or show SIP header modifications.

Practice this question →
29
MCQmedium

A network administrator is troubleshooting why a FortiGate does not appear to be enforcing a newly configured application control profile. The policy is applied to traffic from the internal network to the internet. The administrator runs 'diagnose sys session list' and sees that sessions are being created, but the application control profile is not listed in the session details. Which action should the administrator take to verify that the application control profile is being applied?

A.Use 'diagnose sys session filter' to filter sessions by the policy ID and then run 'diagnose sys session list' to check if the application control profile is referenced.
B.Check the FortiGate's event log for application control violations.
C.Run 'diagnose debug application ipsmonitor -1' to check if the IPS engine is inspecting the traffic.
D.Run 'diagnose test application appctrl 1' to display the application control statistics.
AnswerA

Filtering sessions by the policy ID and listing them will show detailed session information, including the UTM profiles applied. If the application control profile is active, it will appear in the session output. This is the most direct way to verify profile enforcement on a per-session basis.

Why this answer

To verify that an application control profile is being applied to a session, the administrator should filter sessions by the policy ID and list them. The session output includes the UTM profiles associated with the session. This method provides definitive evidence of whether the profile is active, unlike global statistics or logs that may not reflect per-session enforcement.

Exam trap

The trap here is assuming that global application control statistics or logs will confirm per-session profile enforcement, when in fact only detailed session inspection reveals the applied profiles.

Practice this question →
30
MCQeasy

Which of the following is a valid command to check the status of all BGP neighbors on a FortiGate?

A.diagnose router bgp summary
B.get router info bgp summary
C.show bgp neighbors
D.diagnose ip router bgp all
AnswerB

'get router info bgp summary' is the FortiOS diagnostic command that lists all BGP neighbours with their state, peer address and prefix counts, letting an administrator verify neighbour status directly from the CLI. It satisfies the requirement to check all BGP neighbours.

Why this answer

'get router info bgp summary' is the standard FortiGate CLI command to display the status of all BGP neighbors, including their state, uptime, and prefixes received. This command retrieves the BGP routing table summary from the FortiGate's routing daemon, which is essential for verifying neighbor relationships and troubleshooting BGP peering issues.

Exam trap

The trap here is that candidates familiar with Cisco IOS often default to 'show bgp neighbors' (Option C), but FortiGate uses a different CLI syntax with 'get router info' for operational state queries, and 'diagnose' commands are reserved for low-level debugging, not standard status checks.

How to eliminate wrong answers

Option A is wrong because 'diagnose router bgp summary' is not a valid FortiGate command; the 'diagnose' prefix is used for advanced debugging, but the correct syntax for BGP summary is under 'get router info bgp summary'. Option C is wrong because 'show bgp neighbors' is a Cisco IOS command, not a FortiGate CLI command; FortiGate uses 'get router info bgp neighbors' for detailed neighbor information, but the question specifically asks for a summary of all neighbors. Option D is wrong because 'diagnose ip router bgp all' is not a valid FortiGate command; the correct diagnostic command for BGP is 'diagnose router bgp all' (without 'ip'), but even that does not provide a summary of neighbor status.

Practice this question →
31
MCQhard

You are troubleshooting a VPN phase 2 negotiation failure. The logs show 'no proposal chosen'. What is the MOST likely cause?

A.The remote gateway IP is incorrect
B.The pre-shared key mismatch
C.The IKE version mismatch
D.The phase 2 proposal settings differ between the peers
AnswerD

Phase 2 negotiation requires both peers to agree on identical encryption, authentication and lifetime parameters. When the responder's proposal set shares no matching transform with the initiator's, it discards every offer and returns 'no proposal chosen', so mismatched phase 2 settings directly cause the failure.

Why this answer

The 'no proposal chosen' error in VPN phase 2 indicates that the IPsec peers could not agree on a common set of phase 2 parameters (such as encryption algorithm, authentication algorithm, or PFS group). Since phase 2 negotiation occurs after IKE phase 1 has successfully completed, the issue is specifically with the IPsec SA proposal settings, not with pre-shared keys or IKE version. Therefore, differing phase 2 proposals between the peers are the most likely cause.

Exam trap

The trap here is that candidates often confuse phase 1 and phase 2 errors, assuming any 'no proposal chosen' relates to IKE proposals, when in fact the error message is specific to the IPsec SA negotiation in phase 2.

How to eliminate wrong answers

Option A is wrong because an incorrect remote gateway IP would prevent phase 1 (IKE) from establishing, not cause a phase 2 'no proposal chosen' error. Option B is wrong because a pre-shared key mismatch would cause an IKE authentication failure during phase 1, not a phase 2 proposal mismatch. Option C is wrong because an IKE version mismatch would prevent phase 1 negotiation entirely, resulting in a different error (e.g., 'no acceptable proposal' during phase 1), not a phase 2-specific 'no proposal chosen'.

Practice this question →
32
MCQmedium

During a failover test in an active-passive HA cluster, the administrator notices that the secondary unit does not take over the primary role after a link failure on the primary. The 'get system ha status' shows both units in 'standalone' mode. What is the MOST likely cause?

A.The session pickup feature is disabled
B.The HA heartbeat interface is down or misconfigured on one unit
C.The cluster is running in active-active mode
D.The HA override feature is disabled
AnswerB

HA state synchronisation and failover depend on heartbeat packets traversing the dedicated HA link. If that interface is down or misconfigured, each unit loses peer visibility and reverts to standalone, so the secondary never detects primary failure and cannot assume the primary role.

Why this answer

When both units show 'standalone' mode in 'get system ha status', it indicates that the HA cluster has lost communication between the primary and secondary units, causing them to operate independently. The most common cause is a failure or misconfiguration of the HA heartbeat interface, which is the dedicated link used for cluster synchronization and health monitoring. Without a functional heartbeat, the secondary cannot detect the primary's link failure and will not initiate a failover.

Exam trap

The trap here is that candidates often confuse session pickup or override features with the fundamental requirement of a working heartbeat interface, assuming that failover is triggered by link failure detection on data ports rather than requiring a separate, dedicated heartbeat link.

How to eliminate wrong answers

Option A is wrong because session pickup is a feature for synchronizing existing sessions during a failover, not for detecting link failures or triggering role changes; disabling it does not prevent the secondary from taking over the primary role. Option C is wrong because if the cluster were running in active-active mode, both units would show as 'active' in HA status, not 'standalone', and the question specifies an active-passive cluster. Option D is wrong because the HA override feature controls whether a primary unit can preempt a secondary after recovery, not the ability to detect link failures or perform failover; disabling it does not cause standalone mode.

Practice this question →
33
MCQmedium

A FortiGate is configured with a firewall policy that has a URL filter profile. Users report that access to a specific website is blocked, but the administrator wants to verify which URL filter category matched the request. The administrator runs 'diagnose debug application urlfilter -1' in the CLI. However, no output appears. What is the MOST likely reason for the lack of output?

A.The urlfilter debug application is not available on this FortiGate model or firmware version.
B.The URL filter profile is not applied to the firewall policy that matches the user traffic.
C.The URL filter debug level is set to 0 by default and must be enabled with 'diagnose debug enable'.
D.The administrator did not run 'diagnose debug enable' after setting the debug level.
AnswerD

In FortiOS, to view debug output for a specific application, you must first set the debug level using 'diagnose debug application <name> <level>' and then enable debug globally with 'diagnose debug enable'. Without enabling debug, no output is displayed even if the level is set. This is a common oversight. The command 'diagnose debug application urlfilter -1' sets the level to verbose, but debug remains disabled until 'diagnose debug enable' is issued.

Why this answer

To capture URL filter debug messages, the administrator must set the debug level for the urlfilter application and then enable debug globally. The command 'diagnose debug application urlfilter -1' sets the level, but without 'diagnose debug enable', no output is generated. This is a common troubleshooting step that is often missed.

Once enabled, the debug will show category matches and other details.

Exam trap

The trap here is assuming that setting the debug level automatically enables debug output, when in fact a separate global enable command is required.

Practice this question →
34
MCQeasy

A FortiGate administrator wants to see the current number of active sessions. Which command provides this information?

A.show system session-info
B.diagnose sys session stat
C.diagnose sys session list
D.get system performance status
AnswerB

The diagnose sys session stat command outputs session statistics including the current count of active sessions on the FortiGate. It directly satisfies the requirement to view the present number of established sessions, unlike commands that list session details or clear the session table.

Why this answer

The 'diagnose sys session stat' command displays a summary of the current session table, including the total number of active sessions, which is exactly what the administrator needs. This command is part of FortiGate's diagnostic tools and provides a quick statistical overview without listing individual session details.

Exam trap

The trap here is that candidates confuse 'diagnose sys session stat' with 'diagnose sys session list' or 'show system session-info', assuming any command with 'session' in it will show the session count, but only 'stat' provides the aggregated summary without listing every session.

How to eliminate wrong answers

Option A is wrong because 'show system session-info' is not a valid FortiGate CLI command; the correct command for viewing session information is 'diagnose sys session stat' or 'get system session-info' (which shows session-related configuration, not active session counts). Option C is wrong because 'diagnose sys session list' dumps all individual session entries, which is useful for deep inspection but does not provide a simple count of active sessions and can overwhelm the output. Option D is wrong because 'get system performance status' shows overall system performance metrics like CPU and memory usage, not the number of active sessions.

Practice this question →
35
MCQhard

A network administrator is troubleshooting a FortiGate HA cluster in active-passive mode. The administrator notices that the secondary unit is not receiving heartbeat packets from the primary unit, and the cluster has split. The administrator runs 'diagnose sys ha status' on both units and sees that the primary unit shows the secondary as 'not connected', while the secondary unit shows the primary as 'not connected'. The administrator verifies that the heartbeat interfaces are correctly configured and physically connected. What is the MOST likely cause of the split?

A.The primary unit is overloaded and cannot send heartbeat packets.
B.The heartbeat interfaces are configured with different VLAN IDs on each unit.
C.The HA group ID is different on the two units, preventing them from forming a cluster.
D.The heartbeat packets are being dropped by an intermediate switch due to a native VLAN mismatch.
AnswerD

In HA, heartbeat packets are typically sent as untagged or with a specific VLAN. If the heartbeat interfaces are connected through a switch, a native VLAN mismatch on the switch ports can cause untagged heartbeat packets to be dropped or misdirected. This would result in both units showing each other as not connected, leading to a split. Since the administrator verified the FortiGate interfaces are correctly configured, the issue likely lies in the network infrastructure, such as a native VLAN mismatch on the switch.

Why this answer

The most likely cause is that heartbeat packets are being dropped by an intermediate switch due to a native VLAN mismatch. When the FortiGate heartbeat interfaces are connected through a switch, the switch must properly forward the heartbeat traffic. A native VLAN mismatch can cause untagged packets to be dropped or sent to the wrong VLAN, preventing heartbeats from reaching the peer.

This leads to both units losing communication and forming separate clusters.

Exam trap

The trap here is focusing solely on FortiGate configuration and overlooking the network infrastructure, such as switch VLAN settings, which can silently drop heartbeat packets.

Practice this question →
36
MCQmedium

A site-to-site IPsec VPN tunnel is failing. The administrator runs 'diagnose vpn ike config' and sees that phase 1 parameters are correct. However, phase 2 negotiation fails with 'no proposal chosen'. What is the MOST likely cause?

A.The pre-shared key is incorrect
B.The phase 2 encryption/authentication algorithms do not match between peers
C.The firewall policy allowing IKE traffic is missing
D.The remote gateway IP address is wrong
AnswerB

Phase 2 uses its own proposal set covering encryption and authentication algorithms, independent of phase 1. When peers offer no overlapping phase 2 proposal, the responder returns 'no proposal chosen', so mismatched phase 2 algorithms are the likely cause.

Why this answer

The 'no proposal chosen' error in phase 2 indicates that the IPsec security association (SA) parameters—specifically the encryption algorithm, authentication algorithm, or Diffie-Hellman group—do not match between the two peers. Since the administrator confirmed phase 1 is correct via 'diagnose vpn ike config', the issue is isolated to phase 2 proposal mismatch, making option B the most likely cause.

Exam trap

The trap here is that candidates often confuse phase 1 and phase 2 failures, assuming any 'no proposal chosen' error relates to IKE phase 1, when in fact the error message specifically indicates a phase 2 proposal mismatch after phase 1 has successfully completed.

How to eliminate wrong answers

Option A is wrong because an incorrect pre-shared key would cause phase 1 (IKE) negotiation to fail, not phase 2; the administrator already verified phase 1 parameters are correct. Option C is wrong because a missing firewall policy for IKE traffic would prevent UDP port 500 or 4500 packets from reaching the FortiGate, blocking phase 1 entirely, not just phase 2. Option D is wrong because an incorrect remote gateway IP address would prevent any IKE communication, leading to a phase 1 failure, not a phase 2 'no proposal chosen' error.

Practice this question →
37
MCQmedium

An administrator wants to troubleshoot why specific traffic is not matching a configured firewall policy. Which debug command should be used?

A.diagnose sys session list
B.get firewall policy <id>
C.diagnose netlink interface list
D.diagnose debug flow
AnswerD

The diagnose debug flow command traces packet processing through the FortiGate's policy engine, showing which policy each packet matches or why it is dropped. This directly satisfies the troubleshooting constraint by revealing the specific policy lookup and denial reason for the traffic in question.

Why this answer

The 'diagnose debug flow' command is the correct tool for tracing traffic through the firewall policy engine in FortiOS. It captures the packet flow in real time, showing which policy is evaluated, why a match or no-match occurs, and any drop reasons. This directly addresses the administrator's need to troubleshoot why specific traffic is not matching a configured firewall policy.

Exam trap

The trap here is that candidates often confuse session listing commands with flow debugging, assuming that viewing existing sessions ('diagnose sys session list') will reveal why new traffic fails to match a policy, when in fact it only shows already-established sessions and not the real-time policy evaluation path.

How to eliminate wrong answers

Option A is wrong because 'diagnose sys session list' displays existing session entries in the session table, not the policy matching process for new traffic; it shows what has already been matched, not why a match failed. Option B is wrong because 'get firewall policy <id>' only displays the configuration of a specific policy, not the real-time debugging of traffic flow or policy matching decisions. Option C is wrong because 'diagnose netlink interface list' shows interface information and netlink kernel state, which is unrelated to firewall policy matching or traffic debugging.

Practice this question →
38
MCQhard

An administrator runs 'diagnose debug application fnbam -1' and sees messages like 'LB_SELECT: selected server 10.0.0.2:80' but the client connection fails. The FortiGate is configured with server load balancing. What could be the issue?

A.The real server is not reachable or is down
B.The load balancing algorithm is set to least-connection
C.The persistence setting is misconfigured
D.The virtual server IP is overlapping with a physical interface
AnswerA

The debug shows the load balancer successfully selecting a real server, so the failure occurs after selection. If that server is down or unreachable, the client connection cannot complete, matching the symptom of selection succeeding but the connection failing.

Why this answer

The 'LB_SELECT: selected server 10.0.0.2:80' message indicates that the FortiGate's load-balancing process has chosen a real server for the connection. However, the client connection fails, which points to a problem with the selected server itself. The most common cause is that the real server is unreachable or down, preventing the TCP handshake or HTTP response from completing, even though the load-balancing decision was made successfully.

Exam trap

The trap here is that candidates see 'LB_SELECT' and assume the load-balancing decision is the problem, when in fact the debug output confirms the selection logic is working, and the failure lies in the server's reachability or health.

How to eliminate wrong answers

Option B is wrong because the load-balancing algorithm (e.g., least-connection) affects how servers are selected, not whether the selected server is reachable; the debug message shows a server was selected, so the algorithm is functioning. Option C is wrong because persistence (stickiness) settings control whether subsequent connections from the same client go to the same server, but the initial connection failure is unrelated to persistence misconfiguration. Option D is wrong because an overlapping virtual server IP with a physical interface would typically cause a configuration error or routing issue, not a specific 'selected server' message in the debug output, and the FortiGate would likely reject the VIP configuration or produce different diagnostic messages.

Practice this question →
39
MCQmedium

A FortiGate is configured with multiple BGP peers. One of the peers is not receiving the expected routes. The administrator runs 'get router info bgp neighbors <IP>' and sees that the 'State/PfxRcd' field is 'Active'. What does this indicate?

A.The BGP peer has reached the maximum prefix limit
B.The BGP peer has been administratively shut down
C.The BGP session is in the Active state, meaning the FortiGate is trying to establish a TCP connection to the peer
D.The BGP session has been established and routes are being exchanged
AnswerC

Active state indicates the router is actively trying to initiate a TCP connection to the peer, but the session is not yet up.

Why this answer

The 'Active' state in BGP indicates that the FortiGate has sent an OPEN message and is waiting for a TCP connection from the peer, or is actively retrying the TCP connection. This means the session has not yet reached the Established state, so no routes are being exchanged. Option C correctly identifies that the FortiGate is attempting to establish a TCP connection to the peer.

Exam trap

The trap here is that candidates confuse 'Active' with 'Established' because both sound like the session is working, but 'Active' actually means the TCP connection has not been completed, while 'Established' is the only state where routes are exchanged.

How to eliminate wrong answers

Option A is wrong because the 'State/PfxRcd' field shows 'Active', not 'Idle (PfxCtx)' or a prefix limit exceeded message; the maximum prefix limit would cause the session to go to Idle state, not Active. Option B is wrong because an administratively shut down peer would show 'Idle (Admin)' in the state field, not 'Active'. Option D is wrong because the 'Active' state explicitly means the session is not yet established; routes are only exchanged after the session reaches the 'Established' state, which would show a numeric prefix count in 'State/PfxRcd'.

Practice this question →
40
MCQmedium

An administrator notices high CPU usage on a FortiGate. To identify which process is consuming the most CPU, which command should be used?

A.diagnose sys top
B.diagnose sys session stat
C.get system performance status
D.diagnose hardware sysinfo
AnswerA

The diagnose sys top command displays a live, sorted list of running processes with their CPU and memory consumption on FortiGate, letting the administrator pinpoint the exact process driving the high CPU usage reported in the stem.

Why this answer

The 'diagnose sys top' command displays a real-time list of running processes on the FortiGate, sorted by CPU usage, allowing the administrator to identify which process is consuming the most CPU. This is the standard diagnostic tool for process-level CPU troubleshooting in FortiOS.

Exam trap

The trap here is that candidates confuse high-level performance commands like 'get system performance status' with process-level diagnostics, but only 'diagnose sys top' provides per-process CPU breakdown.

How to eliminate wrong answers

Option B is wrong because 'diagnose sys session stat' shows session statistics (total sessions, active sessions, etc.), not process-level CPU usage. Option C is wrong because 'get system performance status' provides a high-level summary of CPU and memory utilization but does not break down usage by individual process. Option D is wrong because 'diagnose hardware sysinfo' displays hardware information such as serial numbers, temperatures, and fan status, not process CPU consumption.

Practice this question →
41
MCQmedium

A FortiGate is configured with a firewall policy that applies an application control profile blocking social media. Users report that they can still access Facebook. The administrator verifies that the policy is correctly matching the traffic and that the application control profile is applied. Which CLI command should the administrator use to verify whether the application control is correctly identifying the traffic?

A.diagnose firewall iprope list
B.diagnose debug application appctrl -1
C.diagnose debug application ipsmonitor -1
D.diagnose sys session list
AnswerB

This command enables debugging for the application control daemon, which performs application identification. It will show logs indicating which application is detected for each session, including whether Facebook is identified as 'Facebook' or a sub-application. This directly verifies if the application control engine is working correctly.

Why this answer

The application control daemon (appctrl) is responsible for identifying applications based on signatures and behavior. Debugging it with 'diagnose debug application appctrl -1' shows real-time detection results for each session, allowing the administrator to confirm if Facebook is being recognized. If it is not, they can then check signature updates or traffic patterns.

Exam trap

The trap here is confusing application control debugging with IPS debugging, as both are security profiles but handled by different daemons.

Practice this question →
42
MCQhard

A FortiGate is configured with a VIP for an internal web server. Users report that the web server is unreachable from the internet, but it is accessible from the internal network. The administrator runs 'diagnose debug flow' with filters for the public IP and sees that the traffic reaches the FortiGate but is dropped with the message 'iprope_in_check() check failed, drop'. What is the MOST likely cause?

A.The VIP is not configured with the correct external interface.
B.The web server's default gateway is not set to the FortiGate's internal interface.
C.A firewall policy allowing traffic from the internet to the VIP is missing or misordered.
D.The VIP is configured with port forwarding, but the external port does not match the service port.
AnswerC

The iprope_in_check failure typically indicates that no firewall policy matched the incoming traffic. For a VIP, a policy must explicitly allow traffic from the external interface to the VIP. If the policy is missing, disabled, or placed after a deny policy, the packet is dropped. This matches the symptom: internal access works because it uses a different policy path.

Why this answer

The debug flow message 'iprope_in_check() check failed, drop' indicates that the incoming packet did not match any firewall policy. For a VIP, a policy must explicitly permit traffic from the external interface to the VIP. If such a policy is absent, disabled, or ordered after a deny policy, the packet is dropped.

Internal access works because it uses a different policy path, which is why the issue is isolated to external users.

Exam trap

The trap here is focusing on NAT or routing when the debug message clearly points to a policy lookup failure.

Practice this question →
43
Multi-Selectmedium

An administrator is troubleshooting a FortiGate HA cluster that is experiencing frequent failovers. The administrator wants to verify the HA status and identify potential issues. Which TWO commands should the administrator use to gather relevant information? (Choose two.)

Select 2 answers
A.diagnose sys session list
B.execute ha manage 0
C.diagnose sys ha checksum show
D.get system ha status
E.diagnose debug application hatalk -1
AnswersC, D

This command shows the HA checksum values for each unit, which are used to verify configuration synchronization. If checksums do not match, the cluster may be out of sync, potentially causing failovers or inconsistent behavior. It helps identify configuration discrepancies that could lead to HA instability.

Why this answer

To diagnose frequent HA failovers, the administrator should first check the overall HA status with 'get system ha status' to see which unit is primary and if there are any anomalies. Then, verifying configuration synchronization with 'diagnose sys ha checksum show' helps ensure both units have identical configurations, as mismatches can cause instability. These two commands provide a quick, non-intrusive overview of the cluster's health and are the standard first steps.

Exam trap

The trap here is choosing debug commands that are too detailed or unrelated, instead of starting with basic status and synchronization checks.

Practice this question →
44
MCQeasy

An administrator wants to see the current number of active sessions on a FortiGate. Which command should the admin use?

A.diagnose sys session list
B.diagnose sys session stat
C.get system performance status
D.get system ha status
AnswerB

diagnose sys session stat returns session table statistics, including the current count of active sessions, directly answering the administrator's query. It reads the session table counters rather than listing individual sessions, so it gives the aggregate figure without dumping every entry.

Why this answer

The command 'diagnose sys session stat' displays a summary of session statistics, including the total number of active sessions currently tracked by the FortiGate's session table. This is the correct way to quickly see the current active session count without listing every individual session, which would be overwhelming and resource-intensive.

Exam trap

The trap here is that candidates often confuse 'diagnose sys session list' (which shows individual sessions) with 'diagnose sys session stat' (which shows the count), because both commands start with the same prefix and deal with sessions, but only 'stat' gives the aggregate number without flooding the console.

How to eliminate wrong answers

Option A is wrong because 'diagnose sys session list' dumps every individual session entry in the session table, which is useful for deep inspection but not for simply viewing the current number of active sessions; it can also cause high CPU usage on a busy firewall. Option C is wrong because 'get system performance status' shows overall system resource usage (CPU, memory, disk) and basic throughput, but it does not display the session count. Option D is wrong because 'get system ha status' shows High Availability cluster state and synchronization details, which is unrelated to session statistics.

Practice this question →
45
MCQmedium

A FortiGate is configured with an explicit web proxy on port 8080. Users report that some websites load slowly while others fail to load at all. The administrator runs 'diagnose debug application wad 8' and sees messages about 'proxy worker' and 'connection failed'. Which command should the administrator use to view the current proxy sessions in real time?

A.diagnose firewall iprope list
B.diagnose wad session list
C.diagnose debug application proxy -1
D.diagnose sys session list
AnswerB

This command displays the current explicit proxy sessions managed by the wad daemon, including source, destination, and state. In this scenario, the administrator needs to see which proxy sessions are active or failing to understand why some websites fail to load. The debug output already points to wad, so listing wad sessions is the correct next step.

Why this answer

The explicit web proxy on FortiGate is handled by the wad daemon. To view current proxy sessions in real time, the administrator should use 'diagnose wad session list'. This command provides details such as client IP, destination, and session state, which are essential for troubleshooting why some websites load slowly or fail.

The debug output already indicated wad as the relevant process, making this the correct diagnostic step.

Exam trap

The trap here is assuming that the general session list includes proxy session details, but explicit proxy sessions are managed separately by the wad daemon.

Practice this question →
46
Drag & Dropmedium

Drag and drop the steps to perform a firmware upgrade on a FortiGate device into the correct order.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for a FortiGate firmware upgrade is to first back up the configuration, then upload the new firmware image, confirm the upgrade to start the process, and finally verify the upgrade after the device reboots. This ensures configuration safety and successful upgrade completion.

Practice this question →
47
MCQhard

An HA cluster of two FortiGates is experiencing split-brain. After investigation, you find that the heartbeat link is down on the primary unit. Which action will resolve the split-brain condition?

A.Disable HA on both units and re-enable
B.Restore the heartbeat link by checking cables, interfaces, and VLAN configuration
C.Increase the HA priority on the primary unit
D.Reboot the secondary unit
AnswerB

Split-brain occurs when cluster units lose heartbeat communication and both assume primary role. Restoring the heartbeat link by verifying cables, interfaces and VLAN configuration re-establishes synchronisation, allowing the cluster to renegotiate a single primary and clear the split-brain condition.

Why this answer

Split-brain occurs when HA peers lose heartbeat communication and both assume the primary role. Since the root cause is a failed heartbeat link on the primary unit, restoring that link (checking cables, interfaces, VLAN configuration) re-establishes the control channel, allowing the cluster to negotiate roles and resolve the split-brain condition without disrupting services or requiring a full HA reset.

Exam trap

The trap here is that candidates often assume split-brain requires a full HA reset or priority adjustment, when in fact the most direct and least disruptive fix is to restore the failed heartbeat link that caused the condition.

How to eliminate wrong answers

Option A is wrong because disabling and re-enabling HA on both units is a disruptive, brute-force method that does not address the underlying heartbeat link failure; it forces a full HA re-initialization, causing unnecessary traffic interruption and potential configuration loss. Option C is wrong because increasing the HA priority on the primary unit does not fix the lost heartbeat connectivity; priority only influences role election when heartbeat is functional, and with a dead link, both units will still believe they are primary. Option D is wrong because rebooting the secondary unit does not restore the primary's heartbeat link; the secondary will reboot and immediately re-enter split-brain since the primary still cannot communicate over the heartbeat interface.

Practice this question →
48
MCQmedium

An SD-WAN rule is configured to steer traffic based on SLA metrics. The administrator notices that traffic is not using the expected member interface even though the SLA is meeting thresholds. What should the administrator check FIRST?

A.Check the firewall policy to ensure SD-WAN is enabled
B.Verify the BGP configuration to ensure routes are being advertised
C.Run 'diagnose sys sdwan info' to verify the rule and member status
D.Restart the FortiGate to clear any stale sessions
AnswerC

Running `diagnose sys sdwan info` reveals the rule's matched members, their SLA state, and which interface FortiGate currently selects, exposing mismatches between configured priority and actual steering. This directly satisfies the stem's requirement to check FIRST, since it confirms whether the rule and member status are correct before investigating health-check or routing causes.

Why this answer

'diagnose sys sdwan info' provides a real-time view of SD-WAN rule status, member interface health, and SLA compliance. This command directly shows whether the rule is matching traffic and if the expected member is active or has been deprioritized due to implicit factors like session stickiness or load-balancing algorithm, which are not visible in the SLA thresholds alone.

Exam trap

The trap here is that candidates assume SLA compliance alone guarantees traffic will use the member, ignoring that SD-WAN rules also consider load-balancing algorithms, session stickiness, and explicit member selection in the rule configuration.

How to eliminate wrong answers

Option A is wrong because SD-WAN rules are independent of firewall policy SD-WAN enablement; the firewall policy only needs to reference the SD-WAN zone, and disabling SD-WAN on the policy would block all SD-WAN steering, not cause a specific member to be unused while SLA is met. Option B is wrong because BGP route advertisement affects routing table entries, not SD-WAN rule-based traffic steering; SD-WAN rules override routing decisions based on SLA metrics, so BGP misconfiguration would not cause a member to be unused if the rule is correctly matching. Option D is wrong because restarting the FortiGate is a drastic, unnecessary step that would clear all sessions but not resolve a configuration or rule-matching issue; stale sessions are not the cause when SLA is meeting thresholds and the member is not being used.

Practice this question →
49
MCQeasy

An administrator is troubleshooting an HA cluster where both units show as primary after a link failure. What is the most likely cause of this split-brain scenario?

A.The HA heartbeat interface is down or misconfigured
B.The priority values are set identically
C.The HA uptime is mismatched between the two units
D.The session pickup feature is disabled
AnswerA

A failed or misconfigured heartbeat interface prevents the cluster units from exchanging HA hello packets, so each unit loses visibility of its peer and independently promotes itself to primary. This directly satisfies the stem's link-failure constraint, producing the dual-primary split-brain condition described.

Why this answer

In a Fortinet HA cluster, the heartbeat interface is responsible for exchanging health and synchronization information between units. If this interface goes down or is misconfigured, the units lose communication and each assumes the other is dead, causing both to transition to the primary state (split-brain). This is the most common cause of split-brain scenarios in FortiGate HA clusters.

Exam trap

The trap here is that candidates often confuse the cause of split-brain with configuration mismatches like priority or session pickup, but the root cause is almost always a loss of heartbeat communication between the cluster members.

How to eliminate wrong answers

Option B is wrong because identical priority values do not cause split-brain; they simply mean the cluster will use other tie-breakers (such as serial number or uptime) to determine the primary. Option C is wrong because mismatched uptime is a normal tie-breaker used when priorities are equal, not a cause of split-brain. Option D is wrong because session pickup is a feature for synchronizing sessions during failover, and disabling it does not affect the HA election process or cause both units to become primary.

Practice this question →
50
MCQhard

An administrator configures SD-WAN with multiple members. The SD-WAN rule uses the 'latency' strategy. The administrator notices that traffic is not switching to the best-performing member even when latency exceeds the threshold. What could be the issue?

A.The SLA target is not configured or not applied to the SD-WAN rule
B.The load balancing algorithm is set to 'source-ip-based'
C.The threshold is set too low
D.The SD-WAN members are in different VDOMs
AnswerA

The latency strategy only steers traffic away from a member when an SLA target is defined and bound to the rule. Without that target, FortiGate has no threshold to compare measured latency against, so no member is ever marked out of SLA and traffic stays put.

Why this answer

The latency-based SD-WAN rule requires an SLA target to define acceptable performance thresholds. Without an SLA target configured and applied to the rule, the FortiGate has no baseline to compare against, so it will never trigger a member switch even if latency exceeds the threshold. The SLA target must be linked to the SD-WAN rule via the 'set sla' command in the rule configuration.

Exam trap

The trap here is that candidates assume the 'latency' strategy alone will automatically monitor and switch based on real-time latency, but FortiGate requires an explicit SLA target to define the threshold and trigger the evaluation.

How to eliminate wrong answers

Option B is wrong because the load balancing algorithm (e.g., source-ip-based) affects how traffic is distributed among members under normal conditions, but it does not prevent the latency strategy from switching traffic when the SLA is violated; the latency strategy overrides load balancing for failover decisions. Option C is wrong because setting the threshold too low would cause more frequent switching, not prevent it; the issue is that no switching occurs at all, indicating the threshold is not being evaluated. Option D is wrong because SD-WAN members in different VDOMs are supported as long as inter-VDOM links are properly configured; this would not inherently block SLA-based switching.

Practice this question →
51
Multi-Selectmedium

An administrator is troubleshooting a scenario where traffic from VLAN 100 to a server at 10.1.2.100 is being blocked. The FortiGate has an active security policy allowing the traffic and the routing table shows a correct route. Which TWO diagnostic commands should the administrator run to identify the cause of the blockage?

Select 2 answers
A.diagnose sniffer packet any 'host 10.1.2.100' 4
B.get system performance status
C.diagnose ip arp list
D.diagnose sys session list
E.diagnose debug flow
AnswersA, E

Captures packets to verify traffic reaches the FortiGate.

Why this answer

'diagnose sniffer packet any host 10.1.2.100 4' captures packets to/from the server at the interface level, allowing the administrator to see if traffic from VLAN 100 is actually arriving at the FortiGate and whether it is being dropped or forwarded. This command helps identify if the issue is at Layer 2 (e.g., VLAN misconfiguration) or Layer 3 (e.g., routing or firewall drops).

Exam trap

The trap here is that candidates often choose 'diagnose sys session list' thinking it shows blocked traffic, but it only lists established sessions, not dropped packets or failed session creation attempts.

Practice this question →
52
MCQeasy

A FortiGate administrator wants to check if the device is experiencing high CPU usage due to a specific process. Which command should they use to display real-time process CPU usage?

A.show system resource
B.diagnose sys top
C.get system performance status
D.diagnose debug application crashlog read
AnswerB

The diagnose sys top command displays a live, refreshing list of running processes ranked by CPU and memory consumption, letting the administrator identify the specific process driving high CPU. It also supports interval and sort options for real-time monitoring.

Why this answer

The 'diagnose sys top' command provides a real-time, top-like view of FortiGate processes, showing CPU and memory usage per process. This allows the administrator to identify which specific process is consuming high CPU, making it the correct choice for this diagnostic task.

Exam trap

The trap here is that candidates often confuse 'show system resource' (overall stats) with per-process diagnostics, or they mistakenly think 'get system performance status' provides process-level detail, when it only shows aggregate performance metrics.

How to eliminate wrong answers

Option A is wrong because 'show system resource' displays overall system resource usage (CPU, memory, disk) but does not break down usage by individual process. Option C is wrong because 'get system performance status' shows aggregate performance statistics (e.g., sessions, CPU load average) without per-process detail. Option D is wrong because 'diagnose debug application crashlog read' is used to read crash logs for debugging crashes, not for monitoring real-time process CPU usage.

Practice this question →
53
MCQmedium

When troubleshooting an IPsec VPN phase 1 negotiation failure, which debug command should the administrator run to see detailed IKE negotiation messages?

A.diagnose vpn ike log
B.diagnose debug application ike -1
C.get vpn ipsec tunnel details
D.diagnose debug application ipsec -1
AnswerB

`diagnose debug application ike -1` enables verbose IKE daemon logging, exposing phase 1 proposal exchanges, transform mismatches and vendor ID payloads. The `-1` level prints every negotiation message, satisfying the stem's demand for detailed IKE troubleshooting output rather than summary status or filtered event logs.

Why this answer

The command 'diagnose debug application ike -1' enables detailed IKE (Internet Key Exchange) debug messages in FortiOS, which are essential for troubleshooting Phase 1 negotiation failures. This command captures the full IKE negotiation exchange, including proposals, authentication, and Diffie-Hellman group selection, allowing the administrator to identify where the failure occurs.

Exam trap

The trap here is that candidates often confuse the IKE debug command with the IPsec debug command, mistakenly thinking 'diagnose debug application ipsec -1' will show Phase 1 negotiation details, when in fact it only shows kernel-level IPsec processing and not the IKE control-plane messages.

How to eliminate wrong answers

Option A is wrong because 'diagnose vpn ike log' is not a valid FortiOS command; the correct command uses 'diagnose debug application ike' with a debug level. Option C is wrong because 'get vpn ipsec tunnel details' only displays the current state and configuration of established tunnels, not the real-time IKE negotiation messages needed for troubleshooting Phase 1 failures. Option D is wrong because 'diagnose debug application ipsec -1' debugs the IPsec kernel-level processing (e.g., encryption/decryption), not the IKE control-plane negotiation, so it will not show Phase 1 messages.

Practice this question →
54
MCQhard

Based on the exhibit, what can be concluded about the session?

A.The session is a one-way session with only outbound traffic.
B.The session is not being logged.
C.The session is offloaded to the NPU for hardware acceleration.
D.The session is in the 'npu' state, meaning it is being processed by the CPU.
AnswerC

The exhibit shows traffic matching a policy with NPU offloading enabled, so the session bypasses the main CPU and is processed by the network processor for hardware acceleration. This satisfies the stem's requirement to conclude the session's actual processing path, not merely its security profile or inspection state.

Why this answer

The session state 'npu' indicates that the session has been offloaded to the Network Processor Unit (NPU) for hardware acceleration. This is a normal and expected state for traffic that matches hardware-offloadable profiles, allowing the NPU to process packets at wire speed without CPU intervention.

Exam trap

The trap here is that candidates often confuse the 'npu' state with CPU processing, assuming it means 'NPU processing by CPU' rather than recognizing it as hardware offload, leading them to select Option D incorrectly.

How to eliminate wrong answers

Option A is wrong because the session state 'npu' does not imply one-way or only outbound traffic; it simply indicates hardware offload, and sessions can be bidirectional. Option B is wrong because the session state 'npu' does not indicate whether logging is enabled or disabled; logging is configured separately via firewall policies or session log settings. Option D is wrong because the 'npu' state means the session is offloaded to the NPU for hardware acceleration, not that it is being processed by the CPU; CPU processing would be indicated by states like 'tcp' or 'udp' without offload.

Practice this question →
55
MCQhard

An administrator is troubleshooting a FortiGate that is experiencing high CPU usage. The administrator runs 'diagnose sys top' and observes that the 'ipsengine' process is consuming a large amount of CPU. The administrator suspects that a specific IPS signature is causing the issue. Which command should the administrator use to identify which IPS signature is triggering the high CPU usage?

A.diagnose sys session full-stat
B.diagnose ips anomaly list
C.diagnose test application ipsengine 4
D.diagnose debug application ipsmonitor -1
AnswerC

The command 'diagnose test application ipsengine 4' displays the top IPS signatures by CPU usage, helping identify which signature is causing high CPU. This is the correct tool for pinpointing a specific signature that is consuming excessive CPU resources.

Why this answer

The 'diagnose test application ipsengine 4' command is specifically designed to show the top IPS signatures by CPU usage, allowing the administrator to identify which signature is causing high CPU. Other commands provide general IPS or session information but do not drill down to per-signature CPU consumption.

Exam trap

The trap here is confusing general IPS debugging commands with those that provide per-signature CPU statistics.

Practice this question →
56
Multi-Selectmedium

A FortiGate in an HA cluster is experiencing intermittent session synchronization failures. The administrator runs 'diagnose sys ha dump sync-status' and sees that sessions are not being synchronized properly. Which TWO potential causes should the administrator investigate?

Select 2 answers
A.Mismatched HA group IDs
B.Excessive number of sessions exceeding the session sync limit
C.Incorrect BGP route advertisements
D.High packet loss or latency on the heartbeat interface
E.Mismatched HA passwords
AnswersB, D

FortiGate synchronises only a set number of sessions; once the session count exceeds that sync limit, additional sessions are not replicated to the secondary unit. This produces exactly the intermittent synchronisation failures observed, as only sessions beyond the threshold go unsynchronised.

Why this answer

FortiGate HA has a configurable session sync limit (default 500,000 sessions). When the number of concurrent sessions exceeds this limit, the FortiGate stops synchronizing new sessions to the backup unit, leading to intermittent synchronization failures. This can be verified by checking the 'ses_sync_limit' value in the HA configuration and comparing it to the current session count.

Option D is correct because high packet loss or latency on the heartbeat interface can cause session synchronization failures. The heartbeat interface carries synchronization traffic, and any degradation in its performance can lead to missed or delayed sync packets, resulting in intermittent sync failures. This can be diagnosed by checking heartbeat interface statistics such as packet loss and latency.

Exam trap

The trap here is that candidates often assume all HA synchronization failures are caused by network connectivity issues (high latency/packet loss) and overlook the session sync limit, which is a configuration-based threshold that can cause intermittent failures even with perfect heartbeat connectivity.

Practice this question →
57
MCQmedium

You are troubleshooting an SD-WAN rule where traffic is not matching the expected SLA. The FortiGate shows 'SLA mismatch' in logs. What is the MOST likely cause?

A.The interface is down
B.The SLA probe server is unreachable
C.The measured SLA values exceed the configured thresholds
D.The SD-WAN rule is not enabled
AnswerC

FortiGate compares each member's measured latency, jitter and packet loss against the SLA thresholds configured in the SD-WAN rule. When those measurements exceed the thresholds, the rule reports SLA mismatch and steers traffic to another member.

Why this answer

The 'SLA mismatch' log indicates that the measured SLA values (e.g., jitter, latency, packet loss) for the traffic have exceeded the configured thresholds in the SD-WAN rule. This causes the FortiGate to consider the link as not meeting the SLA, even though the interface is up and the probe server is reachable. The SD-WAN rule itself is enabled, but the traffic is steered away from the preferred member because the SLA is not satisfied.

Exam trap

The trap here is that candidates often confuse 'SLA mismatch' with a connectivity issue (interface down or probe unreachable), but the log specifically indicates that the link is up and probes are responding, just not within the acceptable performance thresholds.

How to eliminate wrong answers

Option A is wrong because if the interface were down, the log would show 'interface down' or 'link down', not 'SLA mismatch'. Option B is wrong because an unreachable SLA probe server would generate 'probe failure' or 'server unreachable' logs, not 'SLA mismatch'. Option D is wrong because if the SD-WAN rule were not enabled, the traffic would not be evaluated against SLA thresholds at all, and no 'SLA mismatch' log would appear.

Practice this question →
58
MCQeasy

An administrator needs to verify that a FortiGate is correctly matching a firewall policy for traffic from 192.168.1.0/24 to 10.0.0.0/8. Which command provides a list of policies that match a given source and destination?

A.diagnose debug flow filter
B.diagnose firewall iprope list 100004
C.diagnose firewall policy lookup
D.show firewall policy
AnswerC

The 'diagnose firewall policy lookup' command allows the administrator to specify source and destination IP addresses, interfaces, and other parameters, and it returns the policy that matches the traffic. This is exactly what is needed to verify which policy is being applied to the given traffic.

Why this answer

The 'diagnose firewall policy lookup' command is designed to simulate a policy lookup based on specified parameters such as source IP, destination IP, and incoming interface. It returns the policy ID that would be matched, making it the ideal tool for verifying policy matching for specific traffic.

Exam trap

The trap here is confusing configuration display commands like 'show firewall policy' with dynamic lookup tools that actually simulate the policy matching process.

Practice this question →
59
MCQhard

Based on the debug flow output, what is the reason the packet is dropped?

A.The route to the destination is missing.
B.There is no firewall policy that matches the traffic.
C.The packet has an invalid source IP address.
D.The session table is full.
AnswerB

The debug flow output shows the packet reaching policy lookup and being denied because no firewall policy matches the source, destination, or service tuple. FortiGate drops unmatched traffic by default, so the absence of a matching policy is the drop reason.

Why this answer

The debug flow output indicates that the packet was dropped because no firewall policy matched the traffic. In FortiGate, even if a valid route exists, the packet must be evaluated against firewall policies; if no policy permits the traffic based on source, destination, service, and interface, the packet is silently dropped. The debug flow will show a message like 'no matching policy' or 'deny by policy' in such cases.

Exam trap

The trap here is that candidates often assume a packet drop is due to a missing route when the debug flow shows a policy drop, because they overlook that FortiGate processes routing before policies and the debug flow output explicitly indicates the stage where the drop occurred.

How to eliminate wrong answers

Option A is wrong because a missing route would cause a different debug flow message, such as 'no route to destination' or 'route lookup failed', and the packet would be dropped at the routing stage, not at the firewall policy stage. Option C is wrong because an invalid source IP address (e.g., RFC 1918 on a public interface) would typically be dropped by antispoofing checks or a specific firewall policy, not by a generic 'no matching policy' message; the debug flow would show 'invalid source' or 'reverse path check failed'. Option D is wrong because a full session table would cause a 'session table full' or 'no session available' message in the debug flow, and the drop would occur during session creation, not during policy lookup.

Practice this question →
60
MCQeasy

An HA cluster of two FortiGates is experiencing split-brain. Which command should the administrator use to check the current HA status and identify which unit is the primary?

A.diagnose debug application had 0
B.diagnose sys ha dump
C.get system ha status
D.show system ha
AnswerC

get system ha status reports each cluster member's role, priority, and synchronisation state, letting the administrator identify the primary and diagnose the split-brain condition. It queries live HA runtime information rather than configuration, which is what the scenario requires.

Why this answer

The correct command to check the current HA status and identify the primary unit is 'get system ha status'. This command displays the HA mode, cluster state, role (primary/secondary), and peer status in a clear, human-readable format. In a split-brain scenario, the administrator needs to quickly confirm which unit believes it is the primary, and this command provides that information directly without debug-level verbosity.

Exam trap

The trap here is that candidates confuse FortiGate CLI syntax with Cisco IOS, where 'show' is used for operational status, but FortiGate uses 'get' for such queries, and they may also mistake debug commands (like 'diagnose debug application had 0') for status-checking commands.

How to eliminate wrong answers

Option A is wrong because 'diagnose debug application had 0' enables debug logging for the HA daemon at debug level 0, which is used for troubleshooting HA protocol issues but does not display a concise status summary or identify the primary unit. Option B is wrong because 'diagnose sys ha dump' outputs raw internal HA state data, including timers and counters, which is too verbose and not intended for quickly checking primary/secondary status. Option D is wrong because 'show system ha' is not a valid FortiGate CLI command; the correct syntax uses 'get' (e.g., 'get system ha status') for operational state retrieval, while 'show' is used in other vendors like Cisco.

Practice this question →
61
MCQmedium

A FortiGate admin notices that HTTPS traffic to a web server is not being scanned by the antivirus profile applied to the firewall policy. The admin confirms the policy is correct and antivirus is enabled. What is the MOST likely reason the traffic is not being scanned?

A.SSL/TLS deep inspection is not enabled on the firewall policy
B.The web server's certificate is self-signed and FortiGate is rejecting the connection
C.The FortiGuard antivirus subscription has expired
D.The antivirus profile is configured for flow-based inspection instead of proxy-based
AnswerA

Antivirus profiles inspect decrypted payloads, so HTTPS traffic remains encrypted and passes unscanned unless SSL/TLS deep inspection is enabled on the policy. Enabling deep inspection lets FortiGate decrypt, scan, then re-encrypt the session, satisfying the requirement that HTTPS be examined.

Why this answer

When HTTPS traffic is not scanned by an antivirus profile despite the policy being correct and antivirus enabled, the most likely cause is that SSL/TLS deep inspection is not enabled on the firewall policy. Without deep inspection, FortiGate cannot decrypt the encrypted HTTPS payload, so the antivirus engine sees only encrypted data and cannot scan for malware. Enabling deep inspection with a valid CA certificate allows FortiGate to perform man-in-the-middle decryption and then apply antivirus scanning to the decrypted content.

Exam trap

The trap here is that candidates often assume antivirus scanning works on all traffic by default, but they overlook the critical prerequisite of SSL/TLS deep inspection to decrypt HTTPS before scanning can occur.

How to eliminate wrong answers

Option B is wrong because a self-signed certificate would cause FortiGate to reject the connection only if the firewall policy has SSL certificate inspection set to 'certificate-inspection' or 'deep-inspection' with an untrusted CA; if deep inspection is not enabled, FortiGate simply passes the encrypted traffic without scanning, regardless of certificate trust. Option C is wrong because an expired FortiGuard antivirus subscription would prevent signature updates but would not stop scanning of already-decrypted traffic; the antivirus engine would still attempt to scan using the last known signatures. Option D is wrong because flow-based vs proxy-based inspection affects how the antivirus engine processes traffic (flow-based uses pattern matching on the fly, proxy-based buffers and reassembles), but both modes require decrypted traffic to scan HTTPS; if deep inspection is not enabled, neither mode can scan the encrypted payload.

Practice this question →
62
MCQeasy

A FortiGate administrator is troubleshooting a policy that is supposed to allow HTTP traffic from an internal subnet to a web server. Users report that they cannot access the web server. The administrator runs 'diagnose debug flow' and sees that the traffic is being denied by policy 0. What is the most likely cause?

A.The traffic is being denied by a security profile.
B.The traffic is being denied by the implicit deny policy.
C.The policy does not match the traffic because of incorrect source or destination interface, address, or service.
D.The policy is disabled or does not exist.
AnswerC

When debug flow shows policy 0, it means no policy matched the traffic. This is often due to mismatched source interface, destination interface, source address, destination address, or service. In this scenario, the administrator should verify that the policy's source and destination interfaces and addresses match the actual traffic, and that the service is set to HTTP. This is the most likely cause and the correct answer.

Why this answer

When 'diagnose debug flow' shows that traffic is denied by policy 0, it means no firewall policy matched the traffic. The most likely cause is that the policy does not match the traffic due to incorrect configuration of interfaces, addresses, or services. The administrator should verify that the policy's source and destination interfaces and addresses align with the actual traffic, and that the service is correctly set to HTTP.

This is a common troubleshooting step for policy mismatches.

Exam trap

The trap here is assuming that policy 0 is a valid policy or that a security profile is blocking, but policy 0 indicates that no policy matched the traffic.

Practice this question →
63
MCQeasy

An administrator needs to check the current CPU and memory usage of a FortiGate to determine if resource exhaustion is causing network delays. Which CLI command provides a real-time, top-like view of processes and their resource consumption?

A.diagnose sys session stat
B.diagnose hardware sysinfo memory
C.diagnose sys top
D.get system performance status
AnswerC

The 'diagnose sys top' command provides an interactive, top-like display of running processes, sorted by CPU or memory usage. It updates in real time and allows the administrator to identify which processes are consuming the most resources. This is the correct tool for live troubleshooting of resource exhaustion.

Why this answer

The correct command is 'diagnose sys top', which offers a dynamic, top-like view of processes and their CPU/memory usage. It is the primary tool for real-time resource monitoring on FortiGate, allowing administrators to quickly identify resource-heavy processes.

Exam trap

The trap here is confusing a one-time performance snapshot with a live process monitor; 'get system performance status' gives a summary, not a dynamic view.

Practice this question →
64
Multi-Selectmedium

A FortiGate administrator is troubleshooting a connectivity issue where users cannot access a web server behind the FortiGate from the internet. The administrator suspects that the virtual IP (VIP) configuration is incorrect. Which two commands should the administrator use to verify the VIP configuration and its associated firewall policy? (Choose two.)

Select 2 answers
A.diagnose debug flow filter
B.show firewall policy
C.diagnose firewall vip list
D.show firewall vip
E.diagnose firewall iprope list
AnswersB, D

This command displays all firewall policies, including those that reference VIPs. By examining the policy list, the administrator can verify that there is a policy allowing traffic from the external interface to the VIP, and that the policy is placed correctly in the order. This is crucial because even a correctly configured VIP requires a matching policy to permit traffic. The output includes policy IDs, source/destination addresses, and services.

Why this answer

The correct commands are 'show firewall vip' and 'show firewall policy'. The first displays the VIP configuration, ensuring the external IP and mapped IP are correct. The second shows the firewall policies, verifying that a policy exists to allow traffic to the VIP.

Together, they allow the administrator to confirm both the VIP setup and the policy that permits access, which are both necessary for connectivity.

Exam trap

The trap here is assuming that a VIP alone is sufficient, but without a matching firewall policy, traffic will still be blocked.

Practice this question →
65
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

The ipsengine process performs IPS inspection, so sustained high CPU points to heavy traffic volume passing through IPS inspection, such as a DoS flood. The stem's constraint is identifying the process consuming CPU, and ipsengine's workload scales directly with inspected sessions.

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 →
66
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

Performance logs capture periodic system statistics such as session counts and CPU utilisation, which FortiAnalyzer stores for historical graphing and trend reporting. Other log types record traffic or events, not the time-series resource metrics the administrator needs.

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 →
67
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

On FortiGate HA clusters, 'execute ha failover' triggers a controlled switchover to the passive unit, letting the administrator verify failover without disrupting active sessions. This satisfies the requirement to test failover while maintaining service continuity.

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 →
68
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

Repeated "no response from client" means the FortiGate sent tunnel replies that never arrived. If the client cannot reach the SSL VPN IP or port, packets are dropped before the FortiGate receives them, so no response is ever returned. This matches the stem's symptom directly.

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 →
69
Multi-Selectmedium

Which TWO actions are appropriate when troubleshooting a slow network connection through a FortiGate?

Select 2 answers
A.Increase the session TTL to reduce session setup overhead.
B.Check the CPU and memory utilization on the FortiGate.
C.Verify the routing table for correct next-hop entries.
D.Disable flow control on the WAN interface.
E.Disable all security profiles to free resources.
AnswersB, C

Slow throughput often stems from resource exhaustion, since FortiGate inspection, NP offload and session handling all consume CPU and memory. Checking utilisation identifies whether the appliance itself is the bottleneck before investigating upstream or downstream causes.

Why this answer

Option B is correct because high CPU or memory utilization on the FortiGate can directly degrade throughput and cause slow connections, so checking resource usage via commands like 'get system performance status' or the dashboard is a standard first troubleshooting step. Option C is correct because an incorrect or missing next-hop entry in the routing table (verifiable with 'get router info routing-table all') can cause suboptimal paths, asymmetric routing, or packet drops that manifest as slow network performance. Option A is not appropriate because increasing session TTL does not reduce session setup overhead and can actually consume more session table resources.

Option D is wrong because disabling flow control on the WAN interface can worsen performance by allowing buffer overruns and packet loss rather than fixing slowness. Option E is wrong because disabling all security profiles is a drastic, security-compromising action that is not a legitimate troubleshooting step for slow connections.

Exam trap

The trap here is that candidates may assume disabling security features (Option E) or adjusting session timers (Option A) are quick fixes, but the NSE7 exam expects systematic troubleshooting starting with resource utilization and routing verification.

Practice this question →
70
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

Checking the session table reveals whether sessions are exhausting the FortiGate's session limits or hitting per-policy session thresholds during peak load, which directly explains intermittent timeouts despite a permit policy. This satisfies the stem's peak-hour congestion constraint, since session exhaustion manifests as dropped new connections rather than policy denials.

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 →
71
MCQhard

A FortiGate is configured with a VIP (virtual IP) for an internal web server. Users report that the web server is unreachable from the internet, but it works from the internal network. The administrator runs 'diagnose sniffer packet any "host 203.0.113.10 and port 80" 4' and sees incoming packets on the wan1 interface but no outgoing packets on the internal interface. What is the MOST likely cause?

A.The VIP is configured with port forwarding disabled.
B.The VIP is not configured with the correct external IP address.
C.The internal web server is down or not responding.
D.The firewall policy allowing traffic from wan1 to the internal server is missing or misconfigured.
AnswerD

The sniffer shows incoming packets on wan1 but no outgoing packets on the internal interface, indicating the FortiGate is dropping the traffic after ingress. This typically happens when no firewall policy matches the traffic from wan1 to the internal network, or the policy is misconfigured (e.g., wrong service, action deny). The VIP itself only performs DNAT; a policy is still required to permit the translated traffic.

Why this answer

When a VIP is used, the FortiGate performs destination NAT, but a firewall policy from the external interface to the internal interface (or the VIP's mapped interface) is still required to allow the translated traffic. The sniffer output indicates that packets arrive but are not forwarded, which is characteristic of a missing or incorrect policy. The VIP itself does not bypass policy checks.

Exam trap

The trap here is assuming that configuring a VIP automatically allows traffic, when in fact a firewall policy is still needed to permit the DNATed traffic.

Practice this question →
72
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

An Idle BGP state means the router cannot reach the neighbour, so the TCP session never opens. Verifying the neighbour IP is reachable in the routing table confirms whether a missing or incorrect route is blocking the peering, before checking timers or authentication.

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 →
73
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, the secondary FortiGate has no synchronised session table, so established TCP flows cannot be matched after failover and are dropped. Enabling session pickup replicates session state, preserving existing connections across the failover event.

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 →
74
MCQhard

A FortiGate is configured with a VIP (virtual IP) to publish an internal web server to the internet. External users report that they cannot access the web server, but internal users can access it using its private IP. The administrator runs 'diagnose debug flow' and sees that traffic from external users is being dropped with the message 'iprope_in_check() check failed, drop'. What is the most likely cause?

A.The firewall policy allowing access to the VIP does not have NAT enabled.
B.The firewall policy allowing access to the VIP is missing or placed after a deny policy.
C.There is an asymmetric routing issue or the return route is not via the FortiGate.
D.The VIP is not configured with the correct external interface.
AnswerB

The debug message 'iprope_in_check() check failed, drop' indicates that the traffic was dropped during the ingress policy check, often because no matching policy was found or a deny policy was matched. If the policy allowing access to the VIP is missing or is placed after a deny policy, external traffic would be dropped. This is a common cause when VIP access fails while internal access works. Therefore, this is the most likely cause.

Why this answer

The debug message 'iprope_in_check() check failed, drop' indicates that the traffic was dropped during the ingress policy check. This typically happens when no firewall policy matches the traffic or when a deny policy is matched before an allow policy. In this scenario, external users cannot access the VIP, but internal users can, suggesting the VIP itself is working.

The most likely cause is that the firewall policy allowing external access to the VIP is missing, disabled, or incorrectly ordered. The administrator should verify the policy configuration and order.

Exam trap

The trap here is interpreting the iprope_in_check failure as an RPF issue, but it often means no matching policy or a deny policy was hit first.

Practice this question →
75
MCQmedium

An administrator notices that a FortiGate's CPU is consistently high, and the performance dashboard shows the 'ipsengine' process consuming most CPU. The administrator suspects a specific traffic pattern is overwhelming the IPS engine. Which CLI command should be used to identify the top sessions by bandwidth that may be triggering the IPS engine?

A.diagnose sys session list
B.diagnose sys session top
C.diagnose netlink top
D.diagnose sys top
AnswerB

diagnose sys session top shows the top sessions sorted by bandwidth usage. This command is ideal for identifying which sessions are consuming the most traffic, which can help determine if a particular flow is causing high IPS engine CPU. It provides a concise list of top sessions with source, destination, and bandwidth.

Why this answer

High CPU on the IPS engine often results from a few heavy sessions. The diagnose sys session top command lists the top sessions by bandwidth, allowing the administrator to quickly identify the offending traffic. This is more direct than dumping all sessions or looking at interface statistics.

Exam trap

The trap here is confusing process monitoring commands (like diagnose sys top) with session monitoring commands that sort by bandwidth.

Practice this question →
Page 1 of 2 · 112 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Troubleshooting and Diagnostics questions.

Start 20-question session