How many Troubleshooting Scenario Questions questions are on this page?

This page has 8 Troubleshooting Scenario Questions scenario questions for the FORTINET-NSE7-SPECIALTY exam, each with detailed explanations and wrong-answer analysis.

How should I approach FORTINET-NSE7-SPECIALTY scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Fortinet NSE7 Specialty Modules (SD-WAN and Enterprise Firewall tracks) (FORTINET-NSE7-SPECIALTY) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Fortinet NSE7 Specialty Modules (SD-WAN and Enterprise Firewall tracks) (FORTINET-NSE7-SPECIALTY) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

FORTINET-NSE7-SPECIALTY

exam code

Fortinet

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions 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.

Related FORTINET-NSE7-SPECIALTY topic practice pages

Scenario questions usually connect to one or more exam topics. Use these links to review the underlying concepts behind the scenario.

Nse7 SD Wan Security Profiles Routing And Ipsec practice questions

Nse7 SD Wan Security Profiles Routing And Ipsec practice questions for FORTINET-NSE7-SPECIALTY.

Nse7 Enterprise Firewall System Configuration practice questions

Sharpen your FORTINET-NSE7-SPECIALTY knowledge of Nse7 Enterprise Firewall System Configuration.

Nse7 Enterprise Firewall Central Management practice questions

Practise FORTINET-NSE7-SPECIALTY questions linked to Nse7 Enterprise Firewall Central Management.

Nse7 SD Wan System Configuration And Setup practice questions

Targeted FORTINET-NSE7-SPECIALTY practice covering Nse7 SD Wan System Configuration And Setup.

Nse7 SD Wan Central Management practice questions

Work through FORTINET-NSE7-SPECIALTY questions on Nse7 SD Wan Central Management.

Nse7 Enterprise Firewall Security And VPN practice questions

Nse7 Enterprise Firewall Security And VPN practice questions for FORTINET-NSE7-SPECIALTY.

FORTINET-NSE7-SPECIALTY fundamentals practice questions

Targeted FORTINET-NSE7-SPECIALTY practice covering FORTINET-NSE7-SPECIALTY fundamentals.

FORTINET-NSE7-SPECIALTY scenario practice questions

Targeted FORTINET-NSE7-SPECIALTY practice covering FORTINET-NSE7-SPECIALTY scenario.

FORTINET-NSE7-SPECIALTY troubleshooting practice questions

Practise FORTINET-NSE7-SPECIALTY questions linked to FORTINET-NSE7-SPECIALTY troubleshooting.

Practice set

Practice scenarios

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?

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 2mediummultiple choice

Read the full VPN explanation →

You are configuring an IPsec VPN tunnel between two FortiGates. Phase 2 fails to come up. What is the most likely cause?

A
Mismatched Phase 2 selectors
Phase 2 negotiates the IPsec SA using the configured proxy IDs or selectors; if the local and remote quick-mode selectors do not mirror each other, the tunnel proposal is rejected and Phase 2 never establishes, even though Phase 1 succeeds.
B
Incorrect IKE version
Why it fails: IKE version mismatch prevents Phase 1 from establishing, so Phase 2 never begins. Phase 2 failures stem from mismatched proxy IDs, encryption or authentication algorithms, or PFS settings. IKE version tempts because it is a common VPN misconfiguration, but it manifests as Phase 1 failure, not Phase 2.
C
Expired certificate
Why it fails: An expired certificate breaks Phase 1 authentication when certificate-based IKE is used; Phase 2 would not be reached. Phase 2 failures arise from proxy ID, encryption, authentication or PFS mismatches. Certificates tempt because they are a frequent VPN issue, but they affect Phase 1, not the Phase 2 quick mode negotiation.
D
Mismatched pre-shared key
Why it fails: A mismatched pre-shared key causes Phase 1 authentication to fail, so Phase 2 is never negotiated. Phase 2 failures come from proxy ID, encryption, authentication or PFS mismatches. The PSK tempts because it is the classic VPN misconfiguration, but its symptom is Phase 1 down, not Phase 2.

Full breakdown with real-world context →

Question 3hardmultiple 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?

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 4mediummultiple choice

Full question →

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

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 5hardmultiple 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?

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 6mediummulti 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)

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 7hardmulti select

Read the full MPLS explanation →

An administrator troubleshoots a scenario where traffic matching an application-based SD-WAN rule is bypassing the preferred high-speed MPLS tunnel and taking the backup broadband tunnel instead. Which THREE factors should the administrator check to resolve this routing discrepancy? (Choose three)

A
Verify the FortiGate factory default administrator password is changed
Why it fails: The default admin password has no bearing on which SD-WAN member an application-based rule selects. It is tempting because it is a genuine hardening step on the general FortiGate checklist, and it would be the correct answer to a question about initial device security configuration rather than traffic steering.
B
Check the physical layer OSI Model cable category connected to the FortiGate port
Why it fails: Cable category affects physical link negotiation, not SD-WAN member selection for application-based rules. It is tempting because cabling faults do cause link flaps that can trigger failover, and checking the cable category would be correct when diagnosing a port that fails to come up at the expected speed.
C
Inspect the member priorities and weights configured within the specific SD-WAN rule
Member priority and weight inside the SD-WAN rule determine which member the engine selects for matching traffic. If the MPLS member carries a lower priority or unsuitable weight, the rule steers traffic to broadband despite the preferred tunnel being available.
D
Verify whether the preferred MPLS member is failing the configured performance SLA thresholds, causing the SD-WAN engine to disqualify it
The SD-WAN engine continuously probes members against the rule's performance SLA. If the MPLS member breaches latency, jitter or packet-loss thresholds, it is disqualified and removed from selection, so traffic shifts to the backup broadband member until the SLA recovers.
E
Check the sequence order of the SD-WAN rules; an earlier rule might be matching the traffic first
SD-WAN rules are evaluated top-down, and the first match wins. An earlier rule matching the same application or subnet will steer traffic to broadband before the intended MPLS rule is reached, so sequence order must be verified.

Full breakdown with real-world context →

Question 8hardmultiple choice

Full question →

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?

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 →

These FORTINET-NSE7-SPECIALTY practice questions are part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style FORTINET-NSE7-SPECIALTY questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.