How should I use these Troubleshooting practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Troubleshooting questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Troubleshooting domain.

FORTINET-NSE7-SPECIALTY · topic practice

Troubleshooting practice questions

Practise Fortinet NSE7 Specialty Modules (SD-WAN and Enterprise Firewall tracks) (FORTINET-NSE7-SPECIALTY) Troubleshooting practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

7 questionsDomain: Troubleshooting

Practice 10 questions Browse domain →

What the exam tests

What to know about Troubleshooting

Troubleshooting questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Troubleshooting exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Troubleshooting questions

7 questions · select your answer, then reveal the explanation

Question 1easymultiple choice

Study the full SD-WAN breakdown →

When troubleshooting SD-WAN performance SLA packet loss, an administrator wants to view real-time latency, jitter, and packet loss statistics for individual health check members. Which CLI command should be executed?

Trap 1: get system interface physical

Displays physical interface link state, speed, duplex and error counters, not health-check probe metrics. Tempting because interface faults can cause packet loss, so it is the right command when verifying cabling or NIC errors, but it exposes no latency, jitter or SLA data.

Trap 2: execute ping-server status

Reports FortiGate ping-server daemon status, not per-health-check-member SLA statistics. Tempting because it references ping and server reachability, so it fits confirming whether the ping server process is running, but it returns no latency, jitter or packet-loss figures for members.

Trap 3: show system sdwan

Prints the SD-WAN configuration itself — members, zones, SLA targets and rules — rather than live probe results. Tempting because it is SD-WAN-specific, so it is correct when auditing configuration, but it shows no real-time latency, jitter or packet loss per health check member.

Study all Troubleshooting common traps →

A
diagnose sys sdwan health-check
`diagnose sys sdwan health-check` reports per-member SLA metrics, including latency, jitter and packet loss, for each configured health check. It directly satisfies the stem's requirement for real-time statistics on individual health check members, unlike interface-level or session-level diagnostics that aggregate or omit SLA measurements.
B
get system interface physical
Why it fails: Displays physical interface link state, speed, duplex and error counters, not health-check probe metrics. Tempting because interface faults can cause packet loss, so it is the right command when verifying cabling or NIC errors, but it exposes no latency, jitter or SLA data.
C
execute ping-server status
Why it fails: Reports FortiGate ping-server daemon status, not per-health-check-member SLA statistics. Tempting because it references ping and server reachability, so it fits confirming whether the ping server process is running, but it returns no latency, jitter or packet-loss figures for members.
D
show system sdwan
Why it fails: Prints the SD-WAN configuration itself — members, zones, SLA targets and rules — rather than live probe results. Tempting because it is SD-WAN-specific, so it is correct when auditing configuration, but it shows no real-time latency, jitter or packet loss per health check member.

Full breakdown with real-world context →

Question 2hardmultiple choice

Study the full SD-WAN breakdown →

An administrator is troubleshooting an SD-WAN deployment where traffic matching an SD-WAN rule with a destination service object (e.g., HTTPS) is not being steered according to the SLA priority. Instead, it is always taking the default static route member. Upon checking the firewall policies, what is the most common reason why an SD-WAN rule fails to process application or service-based traffic matching?

Trap 1: IPsec VPN phase 2 selectors must be set to 0.0.0.0/0 for…

Phase 2 selectors govern which subnets traverse the IPsec tunnel, not whether an SD-WAN rule evaluates service objects. The rule is skipped because the firewall policy lacks the SD-WAN rule's service object in its matching criteria, so traffic falls through to the static route. Narrow selectors are tempting when tunnels drop traffic, but that is a routing issue.

Trap 2: The firewall policy containing the traffic has SSL inspection…

SSL inspection decrypts traffic for application control and threat inspection; it is not required for SD-WAN service objects such as HTTPS, which match on port and protocol. The rule is bypassed because the firewall policy does not reference the SD-WAN rule's service object, so the static route wins. SSL inspection would matter for application-based rules.

Trap 3: The FortiGate kernel requires hardware acceleration (NP7) to be…

NP7 offload is unrelated to SD-WAN rule evaluation; service-based rules function with hardware acceleration enabled. The rule fails because the firewall policy does not include the SD-WAN rule's service object, so matching traffic takes the default static route. Disabling acceleration is tempting when offload interferes with inspection, but not here.

Study all Troubleshooting common traps →

A
IPsec VPN phase 2 selectors must be set to 0.0.0.0/0 for service-based rules to evaluate
Why it fails: Phase 2 selectors govern which subnets traverse the IPsec tunnel, not whether an SD-WAN rule evaluates service objects. The rule is skipped because the firewall policy lacks the SD-WAN rule's service object in its matching criteria, so traffic falls through to the static route. Narrow selectors are tempting when tunnels drop traffic, but that is a routing issue.
B
The SD-WAN rules are evaluated sequentially from top to bottom; an earlier broad SD-WAN rule with matching source/destination IP addresses is intercepting the traffic before the service-specific rule is reached
SD-WAN rules are evaluated top-down, so a broader earlier rule matching the same source and destination IPs captures the traffic first. The service-specific rule is never reached, and traffic follows the default static route member instead.
C
The firewall policy containing the traffic has SSL inspection disabled, preventing service-based identification
Why it fails: SSL inspection decrypts traffic for application control and threat inspection; it is not required for SD-WAN service objects such as HTTPS, which match on port and protocol. The rule is bypassed because the firewall policy does not reference the SD-WAN rule's service object, so the static route wins. SSL inspection would matter for application-based rules.
D
The FortiGate kernel requires hardware acceleration (NP7) to be disabled for service-based SD-WAN rules to function
Why it fails: NP7 offload is unrelated to SD-WAN rule evaluation; service-based rules function with hardware acceleration enabled. The rule fails because the firewall policy does not include the SD-WAN rule's service object, so matching traffic takes the default static route. Disabling acceleration is tempting when offload interferes with inspection, but not here.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full Troubleshooting explanation →

You are troubleshooting high CPU usage on a FortiGate. Which process would you check to see if the IPS engine is the cause?

Trap 1: get system status

get system status displays firmware version, uptime, HA state and licence information; it reports no per-process CPU consumption, so it cannot show whether the IPS engine is causing high CPU. It is tempting because it is a quick health snapshot, which suits confirming build and uptime rather than attributing load to a specific daemon.

Trap 2: diagnose hardware status

Hardware status reports sensors, fans and voltages, not per-process CPU consumption, so it cannot attribute load to the IPS engine. It is tempting because it is a genuine diagnostic command, and it would be the right choice when investigating thermal or PSU faults rather than process-level CPU.

Trap 3: show sys resource

show sys resource displays overall CPU, memory and session totals, not per-daemon breakdown, so it cannot confirm the IPS engine specifically. It is tempting as a quick health snapshot, and would be correct for a first-pass check of general system load before drilling into individual processes.

Study all Troubleshooting common traps →

A
diag sys top
'diag sys top' lists running processes with their CPU consumption, letting you identify whether the IPS engine (ipsengine) is consuming excessive CPU. This directly confirms or rules out the IPS engine as the cause of the high utilisation.
B
get system status
Why it fails: get system status displays firmware version, uptime, HA state and licence information; it reports no per-process CPU consumption, so it cannot show whether the IPS engine is causing high CPU. It is tempting because it is a quick health snapshot, which suits confirming build and uptime rather than attributing load to a specific daemon.
C
diagnose hardware status
Why it fails: Hardware status reports sensors, fans and voltages, not per-process CPU consumption, so it cannot attribute load to the IPS engine. It is tempting because it is a genuine diagnostic command, and it would be the right choice when investigating thermal or PSU faults rather than process-level CPU.
D
show sys resource
Why it fails: show sys resource displays overall CPU, memory and session totals, not per-daemon breakdown, so it cannot confirm the IPS engine specifically. It is tempting as a quick health snapshot, and would be correct for a first-pass check of general system load before drilling into individual processes.

Full breakdown with real-world context →

Question 4hardmultiple choice

Study the full SD-WAN breakdown →

You are troubleshooting an issue where traffic is not using an SD-WAN rule despite meeting criteria. What is the most likely cause?

Trap 1: The SD-WAN rule is disabled.

A disabled rule simply is not evaluated, so traffic would never match it — but the scenario states criteria are met and the rule still is not applied, pointing to a member or health-check issue instead. Disabling is the obvious first check, which is why it is tempting.

Trap 2: The Performance SLA has timed out.

A timed-out Performance SLA marks the member as failing, but the rule still evaluates and simply excludes that member; it does not stop the rule matching. Traffic bypasses an SD-WAN rule when no matching rule exists or the rule is disabled or ordered after a conflicting policy. SLA timeouts are expected during link degradation.

Trap 3: The interface is not in an SD-WAN zone.

An interface outside an SD-WAN zone cannot be referenced by an SD-WAN rule, so the rule would fail to apply — but this is a configuration prerequisite, not the typical cause when criteria appear satisfied. It is tempting because zone membership is required for SD-WAN participation.

Study all Troubleshooting common traps →

A
A higher-priority SD-WAN rule is matching the traffic first.
SD-WAN rules are evaluated in sequence order, and the first matching rule wins. If a higher-priority rule's criteria also match the traffic, it is applied instead, so the intended lower-priority rule never executes despite its own criteria being met.
B
The SD-WAN rule is disabled.
Why it fails: A disabled rule simply is not evaluated, so traffic would never match it — but the scenario states criteria are met and the rule still is not applied, pointing to a member or health-check issue instead. Disabling is the obvious first check, which is why it is tempting.
C
The Performance SLA has timed out.
Why it fails: A timed-out Performance SLA marks the member as failing, but the rule still evaluates and simply excludes that member; it does not stop the rule matching. Traffic bypasses an SD-WAN rule when no matching rule exists or the rule is disabled or ordered after a conflicting policy. SLA timeouts are expected during link degradation.
D
The interface is not in an SD-WAN zone.
Why it fails: An interface outside an SD-WAN zone cannot be referenced by an SD-WAN rule, so the rule would fail to apply — but this is a configuration prerequisite, not the typical cause when criteria appear satisfied. It is tempting because zone membership is required for SD-WAN participation.

Full breakdown with real-world context →

Question 5mediummulti select

Open the full BGP breakdown →

An administrator is troubleshooting BGP route propagation over SD-WAN IPsec tunnels where a branch office is not receiving specific routes from the datacenter hub. Which TWO CLI commands on the FortiGate are most useful for diagnosing BGP peering and advertised route issues? (Choose two)

Trap 1: execute ipsec tunnel list

This lists active IPsec tunnels and their selectors, revealing nothing about BGP neighbour state or advertised prefixes. It is useful for confirming a tunnel is established before deeper troubleshooting, but diagnosing missing route propagation requires BGP-specific commands such as get router info bgp neighbours and summary.

Trap 2: diagnose sys sdwan member

This command shows SD-WAN member status, link health and SLA measurements, not BGP peering state or advertised prefixes. It is tempting when tunnel performance is suspected, but route propagation faults require BGP neighbour and routing-table commands to inspect received and advertised routes.

Trap 3: get system interface physical

Interface physical output shows link state, speed and MAC details, not BGP neighbour state or the Adj-RIB-Out, so it cannot reveal why specific prefixes are missing. It is tempting because physical-layer faults do break IPsec tunnels, and this command would be the right starting point when a tunnel is down rather than when routes are absent.

Study all Troubleshooting common traps →

A
execute ipsec tunnel list
Why it fails: This lists active IPsec tunnels and their selectors, revealing nothing about BGP neighbour state or advertised prefixes. It is useful for confirming a tunnel is established before deeper troubleshooting, but diagnosing missing route propagation requires BGP-specific commands such as get router info bgp neighbours and summary.
B
diagnose sys sdwan member
Why it fails: This command shows SD-WAN member status, link health and SLA measurements, not BGP peering state or advertised prefixes. It is tempting when tunnel performance is suspected, but route propagation faults require BGP neighbour and routing-table commands to inspect received and advertised routes.
C
get system interface physical
Why it fails: Interface physical output shows link state, speed and MAC details, not BGP neighbour state or the Adj-RIB-Out, so it cannot reveal why specific prefixes are missing. It is tempting because physical-layer faults do break IPsec tunnels, and this command would be the right starting point when a tunnel is down rather than when routes are absent.
D
get router info bgp neighbors advertised-routes
This command displays the routes the local FortiGate is advertising to a specific BGP neighbour. If the branch is missing routes, checking advertised-routes on the datacenter hub confirms whether those prefixes are actually being sent across the SD-WAN IPsec tunnel.
E
get router info bgp summary
The `get router info bgp summary` command displays each BGP neighbour's state, uptime, and prefix counts, confirming whether the branch-to-hub peering is Established. A non-Established or idle peer explains missing routes before any advertisement analysis, directly satisfying the stem's requirement to diagnose BGP peering issues over the SD-WAN IPsec tunnels.

Full breakdown with real-world context →

Question 6mediummultiple choice

Review the full routing breakdown →

Which command allows you to view the current routing table for a specific VDOM?

Trap 1: get system routing

'get system routing' is not a valid FortiOS command, so it returns nothing useful. It is tempting because 'get' commands display configuration and status, but the routing table is viewed with 'get router info routing-table all' executed within the target VDOM.

Trap 2: diag ip route

'diag ip route' is not a valid FortiOS syntax; the diagnostic command is 'diagnose ip route list', which shows the kernel routing table. It is tempting because 'diag ip' commands exist for other lookups, but the correct command for the current routing table is 'get router info routing-table'.

Trap 3: show router table

'show router table' is not valid FortiOS syntax; 'show' displays configuration, not the live routing table. It is tempting because 'show' commands reveal settings, but the current routing table requires 'get router info routing-table all' within the specific VDOM context.

Study all Troubleshooting common traps →

A
get router info routing-table all
The command get router info routing-table all displays the complete routing table, and within a specific VDOM context it shows only that VDOM's routes. This satisfies the requirement to view the current routing table for a chosen VDOM.
B
get system routing
Why it fails: 'get system routing' is not a valid FortiOS command, so it returns nothing useful. It is tempting because 'get' commands display configuration and status, but the routing table is viewed with 'get router info routing-table all' executed within the target VDOM.
C
diag ip route
Why it fails: 'diag ip route' is not a valid FortiOS syntax; the diagnostic command is 'diagnose ip route list', which shows the kernel routing table. It is tempting because 'diag ip' commands exist for other lookups, but the correct command for the current routing table is 'get router info routing-table'.
D
show router table
Why it fails: 'show router table' is not valid FortiOS syntax; 'show' displays configuration, not the live routing table. It is tempting because 'show' commands reveal settings, but the current routing table requires 'get router info routing-table all' within the specific VDOM context.

Full breakdown with real-world context →

Question 7hardmultiple choice

Read the full Troubleshooting explanation →

You are troubleshooting a policy installation failure where the FortiManager reports a 'Configuration conflict'. Which action should you perform to identify the root cause of the mismatch?

Trap 1: Force an 'Import Policy' operation

Import Policy overwrites FortiManager's database with the device's configuration, potentially destroying the conflicting objects needed for diagnosis. It is tempting because it resynchronises a drifted device, but that scenario requires identifying the mismatch, which the policy-diff or revision-comparison tool reveals.

Trap 2: Reboot the FortiManager

Rebooting discards volatile state and interrupts every managed device's tunnel, yet the conflict persists because it lives in the policy package and device-level object database, not in runtime memory. It is tempting as a generic first-line fix, and would be reasonable for a hung daemon or memory leak, not for object mismatch diagnosis.

Trap 3: Disable the policy package entirely

Disabling the package removes it from installation scope, so the conflicting objects are never compared and the mismatch stays unidentified. It is tempting because it stops the failed install and restores service, and would be valid when you deliberately want to halt all policy pushes to affected FortiGates during maintenance.

Study all Troubleshooting common traps →

A
Force an 'Import Policy' operation
Why it fails: Import Policy overwrites FortiManager's database with the device's configuration, potentially destroying the conflicting objects needed for diagnosis. It is tempting because it resynchronises a drifted device, but that scenario requires identifying the mismatch, which the policy-diff or revision-comparison tool reveals.
B
Reboot the FortiManager
Why it fails: Rebooting discards volatile state and interrupts every managed device's tunnel, yet the conflict persists because it lives in the policy package and device-level object database, not in runtime memory. It is tempting as a generic first-line fix, and would be reasonable for a hung daemon or memory leak, not for object mismatch diagnosis.
C
Disable the policy package entirely
Why it fails: Disabling the package removes it from installation scope, so the conflicting objects are never compared and the mismatch stays unidentified. It is tempting because it stops the failed install and restores service, and would be valid when you deliberately want to halt all policy pushes to affected FortiGates during maintenance.
D
Use the 'Diff' feature in the Policy & Objects tab to compare the database and device config
The 'Diff' feature compares FortiManager's policy database against the managed device's running configuration, exposing exactly which objects or rules diverge. This directly satisfies the stem's need to identify the root cause of the 'Configuration conflict' mismatch before remediation, rather than guessing or reinstalling blindly.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Troubleshooting sessions

Start a Troubleshooting only practice session

Every question in these sessions is drawn from the Troubleshooting domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Troubleshooting questions →Mixed FORTINET-NSE7-SPECIALTY session

Related FORTINET-NSE7-SPECIALTY topic practice pages

Move into related areas when this topic feels solid.

Frequently asked questions

What does the FORTINET-NSE7-SPECIALTY exam test about Troubleshooting?: Troubleshooting questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Troubleshooting questions in a focused session?: Yes — the session launcher on this page draws every question from the Troubleshooting domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other FORTINET-NSE7-SPECIALTY topics?: Use the topic links above to move to related areas, or go back to the FORTINET-NSE7-SPECIALTY question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the FORTINET-NSE7-SPECIALTY exam covers. They are not copied from any real exam or dump site.

Troubleshooting only

10 questions 20 questions 30 questions 50 questions

Mixed FORTINET-NSE7-SPECIALTY session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All FORTINET-NSE7-SPECIALTY questions Troubleshooting domain overview FORTINET-NSE7-SPECIALTY exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Troubleshooting practice questions

What to know about Troubleshooting

Common Troubleshooting exam traps

Troubleshooting questions

When troubleshooting SD-WAN performance SLA packet loss, an administrator wants to view real-time latency, jitter, and packet loss statistics for individual health check members. Which CLI command should be executed?

You are troubleshooting high CPU usage on a FortiGate. Which process would you check to see if the IPS engine is the cause?

You are troubleshooting an issue where traffic is not using an SD-WAN rule despite meeting criteria. What is the most likely cause?

An administrator is troubleshooting BGP route propagation over SD-WAN IPsec tunnels where a branch office is not receiving specific routes from the datacenter hub. Which TWO CLI commands on the FortiGate are most useful for diagnosing BGP peering and advertised route issues? (Choose two)

Which command allows you to view the current routing table for a specific VDOM?

You are troubleshooting a policy installation failure where the FortiManager reports a 'Configuration conflict'. Which action should you perform to identify the root cause of the mismatch?

Track your progress over time

Start a Troubleshooting only practice session

Related FORTINET-NSE7-SPECIALTY topic practice pages

Nse7 SD Wan Security Profiles Routing And Ipsec practice questions

Nse7 Enterprise Firewall System Configuration practice questions

Nse7 Enterprise Firewall Central Management practice questions

Nse7 SD Wan System Configuration And Setup practice questions

Nse7 SD Wan Central Management practice questions

Nse7 Enterprise Firewall Security And VPN practice questions

FORTINET-NSE7-SPECIALTY fundamentals practice questions

FORTINET-NSE7-SPECIALTY scenario practice questions

FORTINET-NSE7-SPECIALTY troubleshooting practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid