FortiGate HA interview questions (FGCP, FortiOS 7.6)

Q1Fresher

What is FGCP, and how do active-passive and active-active clusters differ?

In active-passive mode, the primary forwards traffic while the secondary waits and can hold synchronised sessions. In active-active mode, the primary still receives all traffic but shares security-profile inspection with the secondaries.

Why it matters

FGCP is Fortinet’s clustering protocol. Identical units elect a primary, share one automatically synchronised configuration and fail over as one logical firewall. Lab 13 builds the active-passive mode.

Prove it in the lab

FGT-HQ # config system ha
    set group-name "PML-HA"
    set mode a-p
    set password PML@lab-2026
    set hbdev "port3" 50
    set session-pickup enable
    set override disable
    set priority 200
    set monitor "port1" "port2"
end
FGT-HQ # get system ha status

PML@lab-2026 is a lab-only password. Never reuse it in production.

Look for: In get system ha status: the mode (HA A-P), the group name and both members. Then the primary, the reason it was selected, and a configuration status of in-sync.

Common wrong answer

“In active-active, both units receive traffic as equal peers.” In FGCP the primary still receives all traffic; it shares the inspection work with the secondaries.

Likely follow-up

How does FGCP differ from FGSP? See Compare FGCP and FGSP.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q2Fresher

What must match before two FortiGates can form an FGCP cluster?

The units need the same model, firmware, hardware configuration, operating mode and licences. Their HA group ID, group name and password must match, and since February 2025 both must be registered to the same FortiCloud account.

Why it matters

A mismatch stops the cluster forming, so check these before you cable the second unit. Settings unique to each unit, such as the host name and HA priority, stay local; everything else syncs from the primary.

Prove it in the lab

FGT-HQ # get system status
FGT-HQ # show system ha

Look for: The same firmware version and a valid licence on both units, and identical group-name and mode lines.

Common wrong answer

“The host names and HA priorities must match.” Each unit keeps its own host name, and priority is set per unit because the election compares it.

Likely follow-up

Why can two permanent-trial VMs not form a cluster? The trial gives one FortiGate-VM per FortiCloud account, and cluster members must share an account.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q3Fresher

What does the HA heartbeat do, and why use two heartbeat links?

Heartbeat packets on the hbdev interfaces tell each unit that its peer is alive, and they carry the configuration and session synchronisation. Production clusters use two dedicated heartbeat links to avoid a split brain.

Why it matters

In a split brain, both units act as primary at the same time. Heartbeat links through a shared switch without isolation invite it. Each hbdev interface has a priority, and it needs no IP address.

Prove it in the lab

FGT-HQ # config system ha
    set hbdev "port3" 50
end
FGT-HQ # show system ha
FGT-HQ # diagnose sys ha history read

Look for: The hbdev line lists each heartbeat interface with its priority. The history lists HA events with their times.

Common wrong answer

“The heartbeat needs an IP address on each unit.” A heartbeat interface needs no IP address; it talks only to the other cluster member.

Likely follow-up

What changes in a public cloud? With no layer 2, FGCP uses a unicast heartbeat. See HA in a public cloud.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q4Fresher

How do you check that cluster members are in sync, and how do you reach the secondary?

get system ha status shows the members, roles, priorities and uptime, and diagnose sys ha checksum cluster compares their configuration checksums. From the primary, execute ha manage <index> <admin> opens the secondary’s CLI.

Why it matters

A secondary that is out of sync would take over with the wrong configuration. Matching checksums mean matching configurations.

Prove it in the lab

FGT-HQ # get system ha status
FGT-HQ # diagnose sys ha checksum cluster
FGT-HQ # execute ha manage ?
FGT-HQ # execute ha manage 1 admin

Look for: Every checksum line identical for both units, and a configuration status of in-sync. execute ha manage ? lists the member indexes.

Common wrong answer

“Log in to the secondary’s own IP address.” The members share the cluster’s interface addresses. For direct access to each unit, reserve an HA management interface with ha-mgmt-status enable and config ha-mgmt-interfaces.

Likely follow-up

Which settings are not synchronised? Per-unit settings such as the host name and HA priority. See what must match.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q5Fresher

What triggers an FGCP failover?

Heartbeat loss, or a monitored interface going down on the primary, triggers a new election. Remote link monitoring with ping servers does the same for upstream failures.

Why it matters

The cluster can only fail over for failures it notices. Monitored interfaces also matter in the election, which compares them first.

Prove it in the lab

FGT-HQ # config system ha
    set monitor "port1" "port2"
end
FGT-HQ # show system ha
FGT-HQ # diagnose sys ha history read

Look for: port1 and port2 on the monitor line, and each failover in the HA history with its time.

Common wrong answer

“Monitor every interface to be safe.” Monitoring an interface that is down on both units changes nothing, and monitoring an unused interface can cause a failover.

Likely follow-up

Which election step do monitored interfaces decide? The first one: the unit with the most monitored interfaces up wins. See the election order.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q6Experienced

How is the FGCP primary elected?

With override disabled, the default, the order is: most monitored interfaces up, highest HA uptime, highest priority, then highest serial number. With override enabled, priority moves ahead of HA uptime.

Why it matters

HA uptime counts only when the difference exceeds ha-uptime-diff-margin, 300 seconds by default. Without override, the unit that has run longest normally stays primary, which avoids needless failovers. With override, the preferred unit always takes the role back.

Prove it in the lab

FGT-HQ # get system ha status
FGT-HQ # show full-configuration system ha

Look for: The reason the current primary was selected, in get system ha status, and the override and priority values in the full configuration.

Common wrong answer

“The higher priority always wins.” With override disabled, HA uptime is compared before priority whenever the difference exceeds 300 seconds.

Likely follow-up

Is a higher or a lower priority number better? On FortiGate the higher value wins. Palo Alto HA is the opposite: the lower device priority number becomes active.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q7Experienced

What does session pickup do, and what are its limits?

With session-pickup enable, the primary synchronises its TCP sessions to the secondaries over the heartbeat links, so established TCP sessions survive a failover. session-pickup-connectionless adds UDP and ICMP.

Why it matters

Without session pickup, every session must be re-established after a failover. Synchronisation costs heartbeat bandwidth and CPU. Not every session survives, for example sessions being processed by the proxy, so test failover with the applications that matter.

Prove it in the lab

FGT-HQ # show system ha
FGT-HQ # execute ha manage 1 admin
FGT-HQ2 # diagnose sys session filter dst 192.0.2.100
FGT-HQ2 # diagnose sys session list

Look for: set session-pickup enable on the primary, and the synchronised sessions in the secondary’s session list.

Common wrong answer

“Session pickup works only in active-active mode.” It works in active-passive mode too; Lab 13 tests it on an active-passive cluster.

Likely follow-up

Why does a ping drop during a failover while a Telnet session survives? See UDP and ICMP after a failover.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q8Experienced

How does traffic find the new primary after a failover?

The cluster’s interfaces use FGCP virtual MAC addresses, owned by whichever unit is primary. The new primary sends gratuitous ARPs for those MACs, so switches learn the new port.

Why it matters

Routers upstream keep the same ARP entry; only the switch port behind the MAC changes. On FortiGate-VMs, the hypervisor must accept these MACs: on VMware ESXi, allow MAC address changes and forged transmits.

Prove it in the lab

ISP-R# show ip arp 203.0.113.2

Look for: A MAC address that starts with 0009.0f09, the cluster’s virtual MAC. After a failover, ISP-R still shows the same MAC.

Common wrong answer

“The new primary answers with its own MAC, so upstream routers must clear their ARP cache.” FGCP moves the virtual MAC, so the router’s ARP entry does not change.

Likely follow-up

Why does this not work in AWS or Azure? A public cloud has no layer 2 between instances, so there is no gratuitous ARP. See HA in a public cloud.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q9Experienced

Compare FGCP and FGSP.

FGCP elects a primary, synchronises one configuration and fails over as one logical firewall. FGSP links standalone FortiGates that keep their own configurations and addresses, and mainly synchronises sessions between them.

Why it matters

FGSP has no election; the network decides which unit receives traffic. It suits designs behind external load balancers, or where traffic may be asymmetric across two firewalls. It is configured under config system standalone-cluster.

Prove it in the lab

FGT-HQ # get system ha status
FGT-HQ # diagnose sys ha standalone-peers

Look for: FGCP members and roles from the first command. The second lists FGSP peers, and only on an FGSP setup.

Common wrong answer

“FGSP is FGCP in active-active mode.” Active-active is an FGCP mode with an elected primary and one shared configuration; FGSP has neither.

Likely follow-up

Which one would you put behind a pair of load balancers? FGSP, because the load balancers decide which unit receives each session.

Practise this in Lab 13 of the FortiOS 7.6 course. FGSP is covered in the Session 13 notes.

Q10Experienced

How do you upgrade firmware on an FGCP cluster with minimal disruption?

Use uninterruptible upgrade (set upgrade-mode uninterruptible, the 7.6 default) and upload the image once to the primary. The cluster upgrades the secondaries first, fails over to an upgraded unit, then upgrades the former primary.

Why it matters

Traffic keeps flowing apart from brief failovers. Before you start, back up, check the upgrade path, confirm the checksums match and enable session pickup. Releases before 7.4.1 used uninterruptible-upgrade enable instead.

Prove it in the lab

FGT-HQ # show full-configuration system ha | grep upgrade-mode
FGT-HQ # diagnose sys ha checksum cluster
FGT-HQ # get system status

Look for: upgrade-mode uninterruptible before you start. Afterwards, the new version on every member and matching checksums.

Common wrong answer

“The primary is still primary after the upgrade.” With override disabled, the former primary usually ends up secondary; with override enabled, the higher-priority unit takes the role back.

Likely follow-up

How do you hand the role back afterwards without a power cycle? Reset the current primary’s HA uptime, as in the priority scenario.

Practise this in Bonus Lab B2 and Lab 13 of the FortiOS 7.6 course.

Q11Experienced

How does FortiGate-VM HA differ in a public cloud such as AWS or Azure?

A public cloud has no layer 2 between instances, so FGCP uses a unicast heartbeat and cannot rely on gratuitous ARP. On failover, the new primary calls the cloud API to move the public address and update the route tables.

Why it matters

The route tables must send traffic to the FortiGate, because it cannot attract traffic by ARP. In AWS, disable the source/destination check on its network interfaces; in Azure, enable IP forwarding on its NICs.

Prove it in the lab

FGT-HQ # config system ha
FGT-HQ (ha) # set unicast-hb ?
FGT-HQ (ha) # end
FGT-HQ # config system sdn-connector
FGT-HQ (sdn-connector) # edit ?
FGT-HQ (sdn-connector) # end

Look for: The unicast heartbeat options and the SDN connector entries. Nothing is saved until you set a value.

Common wrong answer

“Cloud HA works like on-premises HA, with virtual MACs.” With no layer 2, failover depends on API calls, not on ARP.

Likely follow-up

Cloud HA failed over, but users are still down. Why? If the instances lack permission for those API calls, such as an AWS IAM role, the address and routes never move.

Practise this in Lab 17 of the FortiOS 7.6 course (a walkthrough).

Q12Scenario

You raised FGT-HQ2’s priority to 250, but it stays secondary. Why?

With override disabled, HA uptime is compared before priority. If FGT-HQ has more than 300 seconds more HA uptime, it stays primary whatever the priorities say.

Why it matters

Priority is set per unit and is not synchronised, so the change itself worked. The cluster is following its election order, and get system ha status shows which step decided.

Prove it in the lab

FGT-HQ # get system ha status
FGT-HQ # diagnose sys ha reset-uptime
FGT-HQ # get system ha status

Look for: The selection reason before and after the reset. FGT-HQ2 then wins on longer HA uptime or, under a 300-second gap, on priority.

Common wrong answer

“Priority is compared before uptime.” That is true only with override enabled.

Likely follow-up

How do you make priority decide every time? Enable override on both units, and accept that the preferred unit takes over again whenever it returns.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q13Scenario

After a failover, TCP downloads continue, but UDP calls and pings drop. Why?

session-pickup enable synchronises TCP sessions only. UDP and ICMP also need session-pickup-connectionless enable; without it, the new primary simply creates new sessions for them.

Why it matters

Calls that use UDP drop and must be restarted, even though TCP users notice nothing. Synchronising more sessions costs more heartbeat bandwidth and CPU, so enable it where the business needs it.

Prove it in the lab

FGT-HQ # show system ha

PS C:\> ping -t 192.0.2.100
PS C:\> dism /online /Enable-Feature /FeatureName:TelnetClient
PS C:\> telnet 192.0.2.100

Look for: set session-pickup enable with no connectionless line. In the Lab 13 test, the ping loses a few replies while the Telnet session survives.

Common wrong answer

“The new primary needs a higher priority to take over UDP sessions.” Priority decides the election, not which sessions survive it.

Likely follow-up

Do all TCP sessions survive? Not all; sessions being processed by the proxy, for example, do not. See session pickup.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q14Scenario

The old primary came back after a power failure and caused a second outage. What happened?

Override was enabled, so priority is compared before HA uptime. The higher-priority unit took the primary role back as soon as it returned, and that second change of primary was the second outage.

Why it matters

Override trades one extra interruption for a predictable primary. Keep override disabled unless the business prefers a predictable primary over one less interruption.

Prove it in the lab

FGT-HQ # show system ha
FGT-HQ # config system ha
    set override disable
end

Look for: set override enable in show system ha before the fix. In Lab 13, a ping from WIN-PC drops twice, once for each failover.

Common wrong answer

“The returning unit must have a fault.” Nothing failed the second time: with override enabled, the role returns to the higher-priority unit by design.

Likely follow-up

Where must you change override? On both units: FGT-HQ first, then FGT-HQ2 through execute ha manage.

Practise this in Lab 13 of the FortiOS 7.6 course.

Q15Scenario

You are adding a second FortiGate to a live one. How do you stop the new, empty unit from overwriting the configuration?

Take the new unit’s monitored data ports down, then enter matching HA settings with a lower priority. With its monitored interfaces down it cannot win the election, so it joins as secondary and receives the primary’s configuration.

Why it matters

The primary pushes its configuration to the other members, so the wrong winner could push an empty configuration over the good one. With its ports down, the new unit also stays silent on the production segments until it joins.

Prove it in the lab

FGT-HQ2 # config system interface
    edit "port1"
        set status down
    next
    edit "port2"
        set status down
    next
end
FGT-HQ2 # config system ha
    set group-name "PML-HA"
    set mode a-p
    set password PML@lab-2026
    set hbdev "port3" 50
    set session-pickup enable
    set override disable
    set priority 100
    set monitor "port1" "port2"
end

PML@lab-2026 is a lab-only password. Never reuse it in production.

Look for: After about a minute, get system ha status on FGT-HQ lists two members. FGT-HQ2 receives port1 and port2 in the up state through sync.

Common wrong answer

“A lower priority is enough.” Monitored interfaces and HA uptime are compared before priority, so priority alone does not decide.

Likely follow-up

Which settings stay local on the new unit? Only per-unit settings such as the host name and HA priority. See what must match.

Practise this in Lab 13 of the FortiOS 7.6 course.