NSE7 Troubleshooting and Diagnostics Practice Question
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?
⚠ Common exam trap
Many candidates 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.
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 HA heartbeat interface is down or misconfigured on one unit
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.
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 pickup feature is disabled
Why it's wrong here
Session pickup synchronises session state for failover continuity; it does not determine whether a unit participates in the cluster. Disabling it would cause dropped sessions after takeover, not standalone status. It is tempting because it is a common HA setting, and enabling it would be correct when seamless session preservation across failover is required.
- ✓
The HA heartbeat interface is down or misconfigured on one unit
Why this is correct
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.
- ✗
The cluster is running in active-active mode
Why it's wrong here
Active-active mode still forms a cluster with a primary and secondary; it would not report both units as standalone. The mode is tempting because it is a valid HA configuration, and it would be correct when load sharing across both units is desired rather than active-passive takeover.
- ✗
The HA override feature is disabled
Why it's wrong here
HA override governs whether a unit reclaims the primary role after recovering; it does not prevent cluster formation. Disabling it is tempting because it affects failover behaviour, and enabling override would be correct when a preferred unit must retake the primary role after rejoining.
Go deeper
Related to this question
About these practice questions
This NSE7 question is part of Courseiva's 718-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.