NSE7 Troubleshooting and Diagnostics Practice Question
A FortiGate cluster (A-P) has a session that is not synchronizing to the secondary unit. The administrator runs 'diagnose sys ha session-sync status' and sees that the session count is different between primary and secondary. Which is the most likely cause?
⚠ Common exam trap
It's easy for candidates to assume all sessions are synchronized by default, but FortiGate explicitly excludes local-in traffic (management sessions) from HA synchronization, so a session count difference is normal and expected for those sessions.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The session was created by a local-in traffic (e.g., management traffic) which is not synchronized.
FortiGate A-P clusters synchronize sessions via the HA heartbeat interface, but local-in traffic (e.g., management sessions like HTTPS, SSH, or SNMP) is never synchronized because it is destined to the cluster IP itself and is inherently unit-specific. The 'diagnose sys ha session-sync status' command shows a session count mismatch because the primary unit has local-in sessions that the secondary does not replicate, making D the correct answer.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The session is using a custom application control profile that prevents synchronization.
Why it's wrong here
Application control profiles inspect traffic but do not prevent HA session synchronisation; sessions sync regardless of UTM inspection settings. It is tempting because application control can drop or reset sessions, and it would be the correct cause if sessions were being terminated rather than simply absent from the secondary's session table.
- ✗
The HA heartbeat interface is down.
Why it's wrong here
A failed heartbeat interface breaks HA failover and cluster health, but session synchronisation runs over the dedicated session-sync path, so a heartbeat outage alone does not explain a session-count mismatch. It is tempting because heartbeat failure is a common HA fault, and it would be correct if the cluster were splitting or failing to elect a primary.
- ✗
The secondary unit has insufficient memory to accept new sessions.
Why it's wrong here
Session synchronisation is not gated on the secondary's free memory; the secondary accepts synced sessions regardless of memory pressure, and memory exhaustion would affect forwarding, not sync counts. It is tempting because resource exhaustion is a plausible cluster fault, and it would be correct if the secondary were dropping traffic or failing to install sessions.
- ✓
The session was created by a local-in traffic (e.g., management traffic) which is not synchronized.
Why this is correct
Local-in traffic terminates on the FortiGate itself, so those sessions are never replicated to the secondary unit. This explains the count mismatch without indicating an HA failure, since session synchronisation only covers transit traffic passing through the cluster.
Go deeper
Related to this question
About these practice questions
One of 718 original NSE7 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This NSE7 practice question is part of Courseiva's free Fortinet certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the NSE7 exam.