High Availability and Diagnostics practice questions

The secondary unit has an override enabled.

Why it fails: Override is a priority option that tells FortiGate which unit should become primary in an HA cluster. Configuring override on the secondary would actually make it more likely to become primary, not less, because it forces that unit to take the primary role whenever it is healthy. It does not affect heartbeat-based failover detection; a unit can still fail over when the active unit's heartbeats stop. Therefore, override cannot prevent failover and is not the cause of a failure to fail over.

Session pickup is disabled on the cluster.

Why it fails: Session pickup is a feature that synchronizes the state of TCP/UDP sessions from the active unit to the standby unit, so that sessions survive a failover. It is not involved in detecting a failure or deciding to fail over; heartbeat monitoring handles that decision. Disabling session pickup will cause existing sessions to be dropped during a failover, but the failover itself will still occur normally. Thus, session pickup being disabled explains session loss, not why no failover happens.

The HA uptime on the secondary is less than the primary.

Why it fails: HA uptime is a numeric value that is only used in priority calculations when the HA configuration includes the 'priority' setting or when overriding is used to choose a preferred unit at cluster startup. Once the cluster is up, failover decisions are made solely based on heartbeat loss, not on comparing uptimes. A lower uptime on the secondary would only matter if the cluster was in a tie-breaking situation at boot time, because uptime can influence which unit becomes primary. It does not block or delay failover when the active unit fails.

Set the strategy to 'volume' and configure MPLS as preferred.

Why it fails: Incorrect; volume strategy is for load balancing, not failover.

Use 'load balancing' strategy and assign MPLS a higher weight.

Why it fails: Incorrect; weight does not guarantee exclusive use.

Set the strategy to 'best quality' and set MPLS with highest priority.

Why it fails: Incorrect; best quality uses dynamic metrics, not fixed priority.

Session pickup is enabled but session-pickup-connectionless is also enabled, causing conflict.

Why it fails: Enabling session pickup together with session-pickup-connectionless does not create a conflict; they are complementary settings. Session pickup synchronizes stateful TCP sessions, while session-pickup-connectionless extends the same functionality to connectionless protocols like UDP and ICMP. In fact, enabling both is often a best practice for ensuring seamless failover of all traffic types. Therefore, this combination cannot be the reason the secondary unit fails to become primary.

Override is disabled, so the secondary cannot become primary.

Why it fails: The override setting controls whether a device with a higher priority can reclaim the primary role after a failover event has occurred. It does not prevent a secondary from becoming primary during an actual failure; when the primary goes down, the secondary will automatically take over as long as it is healthy and has heartbeat connectivity. Disabling override simply means that the original primary will not preempt the new primary later, so this is not the cause of the failure.

The priority on the secondary is set to a higher value than the primary.

Why it fails: In FortiGate HA, the priority value is only used to elect the initial primary, with a higher priority being preferred. However, priority does not influence failover behavior: if the current primary becomes unavailable, the secondary will still be promoted regardless of whether its priority is lower or higher. A secondary set to a higher priority would actually cause it to be the initial primary, not prevent it from taking over. Thus, a higher priority on the secondary cannot explain why failover is not occurring.

Neither link, because both fail jitter?

Why it fails: This is incorrect because the exhibit shows that both WAN links have jitter values below the configured jitter threshold, so neither link fails due to jitter. The real issue is latency: wan2 exceeds the latency threshold, while wan1 remains within all SLA thresholds. Therefore the rule should not discard both links.

Both links, because sla-match-mode 'any' allows any link that meets SLA.

Why it fails: This is wrong because sla-match-mode 'any' means a link is considered acceptable if it meets any of the configured SLA metrics (or in some interpretations, if at least one threshold is satisfied), but it does not ignore failed metrics. The exhibit shows wan2 fails the latency threshold, so even with 'any' mode wan2 is not a qualifying link. Only wan1 meets the SLA requirements, so 'both links' is not a valid outcome.

wan2, because it has lower jitter.

Why it fails: Choosing wan2 solely because it exhibits lower jitter ignores the latency threshold, which it fails according to the exhibit. In Fortinet SD-WAN, meeting one metric does not excuse failing another—the SLA definition requires all configured metrics to be within threshold unless a different match mode is explicitly used. Since wan2 does not meet the latency SLA, the SD-WAN rule must not route voice traffic over it, despite its jitter being lower than wan1's.

Create an SD-WAN rule for VoIP traffic with strategy 'best quality' and set the SLA target for latency to 10ms on the MPLS link.

Why it fails: Best quality SD-WAN links dynamically select the member with the lowest measured latency and jitter against SLA targets, not the link with administrative priority. Even if MPLS is healthy, an occasional latency spike above the 10 ms threshold would cause VoIP traffic to fail over to the Internet link, breaking the required MPLS-only policy. This strategy is designed for performance optimization, not strict preferred-member control, so it cannot guarantee MPLS usage.

Create an SD-WAN rule for VoIP traffic with strategy 'load balancing' and assign equal weight to both links.

Why it fails: Load balance SD-WAN distributes flows across the member links according to configured weights, so assigning equal weight to MPLS and Internet would actively send roughly half the VoIP sessions over the Internet. This defeats the requirement for MPLS-only transport and can expose voice traffic to inconsistent path quality. Load balancing is meant for capacity aggregation, not for maintaining a primary/backup relationship between links.

Create an SD-WAN rule for VoIP traffic with strategy 'best quality' and set the SLA target to prefer the Internet link.

Why it fails: Best quality with an SLA target configured to prefer the Internet link would cause the FortiGate to select the Internet path whenever it satisfies the latency, jitter, and packet-loss thresholds. This is the inverse of the design goal because it would route VoIP over the Internet as the first choice, relegating MPLS to backup only if Internet performance degrades. As a performance-based strategy, it cannot enforce a persistent administrative preference for MPLS.

The secondary unit will become primary, but all existing sessions will be dropped.

Why it fails: The secondary unit will become primary, but all existing sessions will be dropped. This is incorrect because synchronized sessions (UDP) are maintained upon failover.

The cluster will remain without a primary until the original unit is restored.

Why it fails: The cluster will remain without a primary until the original unit is restored. This is incorrect; the secondary unit will immediately take over as primary.

The secondary unit will become primary and maintain only TCP sessions.

Why it fails: The secondary unit will become primary and maintain only TCP sessions. This is incorrect because TCP sessions are not synchronized by default; only UDP sessions are maintained.

Connect HA interfaces physically, then configure interface monitoring, then configure HA settings, then reboot.

Why it fails: Placing interface monitoring before HA settings is invalid because interface monitoring rules are tied to the HA virtual cluster and group ID, which are defined only after you set the HA mode and password. Without those settings, the FortiGate cannot validate the interfaces you are trying to monitor, often resulting in an error like 'HA not configured' or the monitor simply being ignored. Even if the attempt seems to save, the monitor has no context to act on, so the cluster would later fail to trigger a failover for a down link.

Configure HA settings first, then connect HA interfaces physically, then configure interface monitoring, then reboot.

Why it fails: Configuring HA settings while the HA interfaces are not physically connected breaks the fundamental prerequisite of a live heartbeat link. FortiGate HA requires the peer to be reachable before it can exchange configuration changes and establish the cluster, and enabling HA without a link can cause the unit to behave as stand-alone or reject the cluster settings entirely. This order risks split‑brain if the link comes up later with mismatched states, whereas having the cable connected first lets the initial HA negotiation complete synchronously.

Connect HA interfaces physically, then configure HA settings, then reboot, then configure interface monitoring.

Why it fails: Rebooting immediately after HA settings but before interface monitoring is a common mistake because the system enters a fully operational HA mode without the link‑failure detection that monitoring provides. Once the unit reboots, it will form or join the cluster using only the defaults, and adding monitoring afterward forces an additional configuration sync that may briefly interrupt HA services or leave a window during which a failed interface would not be detected. A reboot should always be the final step, after all HA‑related parameters—including interface monitors—are already staged.

The maximum number of packets to capture

Why it fails: Incorrect. The fourth parameter does not set the maximum number of packets. The capture continues until manually stopped or until a specified count in the second parameter (interface) but actually the count is not a parameter; the command captures indefinitely unless stopped.

The time duration in seconds

Why it fails: There is no time duration parameter; the count parameter limits packets.

The interface index

Why it fails: Interface is the first parameter, not the number.

The heartbeat interface speed is mismatched

Why it fails: Heartbeat interfaces are used exclusively for cluster control communication, including state synchronization, weighted priority exchange, and link failover detection. The speed of those interfaces affects how quickly configuration and session state are replicated, but it has no bearing on which FortiGate unit receives new traffic. A mismatch would generate interface status warnings, but it cannot cause the primary unit to monopolize traffic in a properly configured active-active cluster.

The load balance method is set to 'source-ip' which naturally causes imbalance

Why it fails: The 'source-ip' load-balance method creates a hash of the source IP address and assigns each new session to a cluster unit based on that hash. This method does distribute sessions across the cluster; however, when all traffic originates from a very small number of IPs, the distribution can appear skewed. Even so, the symptom of one unit handling all traffic is unlikely because source-ip yields at least some sessions to the secondary unit; the more likely explanation is that no load-balance method ('none') was configured.

The cluster is using active-passive mode

Why it fails: The question explicitly states the cluster operates in active-active mode, so the cluster type itself cannot be the cause of the symptom. In active-passive mode, all traffic would indeed pass through the primary unit, but that behavior is by design and outside this scenario. Since the configuration is already active-active, assuming active-passive is contradictory to the given facts rather than a plausible explanation.

An antivirus profile and a routing policy

Why it fails: An antivirus profile scans files and data stream for malware signatures (e.g., viruses, ransomware) and the routing policy decides the next-hop path for packets—neither can classify or block a specific application. Application identification is done by FortiGuard application signatures, not by antivirus engines, and security profiles only take effect when they are attached to a firewall policy that is matched by traffic. Thus, without an application control profile and a firewall policy referencing it, the FortiGate cannot selectively block an app by name.

A URL filter profile and a NAT policy

Why it fails: A URL filter profile categorizes and blocks web URLs and domains based on FortiGuard Web Filtering, which is focused on web content categories like 'Social Networking' or 'Gambling', but it does not identify application protocol signatures (e.g., it cannot distinguish Facebook Messenger from the main Facebook site). A NAT policy only performs source/destination address translation to change IP addresses and ports; it has no inspection or enforcement capability to apply security profiles to traffic. Therefore, these two components cannot block a specific application—they would neither recognize the app nor be able to attach an application control profile to a traffic rule.

A web filter profile and an SSL inspection profile

Why it fails: A web filter profile is designed for web content categories and URL access policies, while an SSL inspection profile merely intercepts and decrypts encrypted traffic so other security profiles can see inside—neither one natively identifies or blocks applications at the protocol level. Even if SSL inspection decrypts traffic, the FortiGate still needs an application control profile to classify the decrypted session as a specific application and enforce an action on it. Without an application control profile and a firewall policy, these two profiles might decrypt traffic but they have no mechanism to block a named application, making this combination insufficient for the requirement.

show full-configuration vpn ipsec

Why it fails: This command outputs the current IPsec VPN configuration, including phase1 and phase2 parameters such as encryption algorithms, authentication methods, and peer addresses. However, it is a static configuration dump and does not provide any real-time diagnostics about the IKE negotiation process or the reason the tunnel fails. It is useful for verifying configured settings, but not for observing live protocol interactions that would reveal the failure point.

execute ping-options source

Why it fails: This command configures the source IP address or interface used for ICMP ping packets, which is a network connectivity tool rather than a VPN diagnostic utility. It does not interact with the IKE daemon or the IPsec kernel modules, so it cannot expose negotiation errors, SA proposal mismatches, or phase2 traffic selector issues. While you may ping the remote gateway to test transport reachability, this command alone gives no insight into why the VPN tunnel is not established.

get system performance status

Why it fails: This command displays system-level metrics such as CPU load, memory usage, and current session count, which give a broad health overview of the FortiGate unit. It does not expose any details about IKE/IPsec negotiation, tunnel phase states, or error counters specific to VPN sessions. Unless the failure is caused by resource exhaustion, this command will not show the reason for a particular tunnel's failure, making it an unlikely source of useful diagnostics.

Syslog server

Why it fails: Syslog server is external but not managed by FortiGate; the question asks for options that provide persistent log storage from FortiGate's perspective, but syslog is a protocol, not a FortiGate storage option. However, many would consider it persistent; but in Fortinet context, the three official persistent storage options are local disk, FortiAnalyzer, and FortiCloud.

Memory buffer logs

Why it fails: Memory buffer logs are held in RAM, which is volatile, so they are lost immediately when the FortiGate reboots, loses power, or receives a clear command. They serve as a high-speed, temporary logging mechanism to minimize flash wear or as a short-term buffer for pending transport, not as a durable archive. Contents can be manually exported to an external host, but there is no automatic persistence.

The sessions are for UDP traffic

Why it fails: Although UDP and TCP sessions in FortiGate have different idle timeout values and different protocol state fields, `expire=0` is interpreted identically across all protocols: the session has a zero remaining lifetime. The protocol being UDP would be indicated by other columns such as the protocol number (17) or the proto_state value, not by the timer. Since UDP sessions are likewise removed as soon as their idle timer reaches zero, this answer cannot explain the observation.

The sessions are in the process of being established

Why it fails: During session establishment, TCP sessions appear in a SYN state with a finite startup timer, typically a few seconds, while the handshake is expected to complete. A session showing `expire=0` has already consumed its full idle-timeout window and is in the final cleanup stage, not in the middle of a handshake. For UDP, there is no connection-establishment phase at all, so the notion of being 'in the process of being established' fails to account for a zero expiry.

The sessions are fully established and active

Why it fails: An active, fully established session continuously refreshes its kernel timer as packets traverse the firewall, so the `expire` number remains positive and counts down only when traffic is idle. Observing `expire=0` specifically means the idle timeout has elapsed with no matching packets, which is the opposite of an active flow. If the session were truly established and carrying traffic, the output would show a larger positive value and a proto_state consistent with normal data transfer.

Check the traffic log for the session

Why it fails: Traffic logs record the ultimate verdict—allow or deny—along with session metadata, but they never expose the real-time sequence of firewall processing. They lack the granularity to identify which internal check rejected the packet or whether the drop occurred in the forwarding path versus the control plane. For a packet that is silently discarded, the log often only shows a generic 'deny' action, without the detailed stage-by-stage trace that debug flow provides.

Check the session table for the packet

Why it fails: The session table is a snapshot of already-established flows; a packet that gets dropped before session creation never appears in it, leaving you without any diagnostic clue. Even if a session was created and later deleted, the table simply shows its current state—it does not store the historical sequence of checks that led to the drop. To see the drop reason in real time, you need a packet-level tracer like debug flow, not a static session listing.

Run 'diagnose sniffer packet' to capture the packet

Why it fails: A packet sniffer on the FortiGate interface only displays the raw Ethernet/IP headers and payload as they pass through; it has zero visibility into the internal firewall logic that processes that packet. It will confirm a packet arrived or left, but it cannot show why the packet was dropped, whether due to a policy rule, a session limit, or an invalid state. The drop often occurs after the packet is sniffed, inside the kernel's forwarding module, so the capture never sees the reason.

Configure a dedicated heartbeat interface

Why it fails: A dedicated heartbeat interface is used solely for cluster state synchronization and health monitoring between HA units, not for management access. While using a dedicated heartbeat link is a recommended best practice to avoid competition with data traffic, it does not substitute for a management IP configuration. The management IP can be enabled on any interface (including a heartbeat interface) but requires the separate ha-mgmt-status and ha-mgmt-interface settings; therefore, configuring a heartbeat interface alone is not a sufficient or correct step for management access.

Assign a virtual MAC address to the management interface

Why it fails: Virtual MAC addresses are automatically assigned to all HA-monitored interfaces to support link-layer failover, but they are not a separate configuration step for management. The cluster uses the same virtual MAC for the management interface as it does for other interfaces, so there is no need to manually assign one. Trying to assign a virtual MAC separately to the management interface is unnecessary and could cause MAC conflicts within the HA cluster, so this action is not part of the correct configuration.

The HA override setting is disabled

Why it fails: Incorrect. The override setting controls preemption, not the initial failover on primary failure. Even with override disabled, failover should occur if the primary fails and heartbeat is functional.

The HA mode is set to active-active instead of active-passive

Why it fails: Incorrect. The command shows active-passive mode, and the issue is about failover, not mode. Active-active mode would show different behavior.

The session pickup feature is enabled

Why it fails: Incorrect. Session pickup is about synchronizing sessions, not directly causing failover to fail.

diagnose sys session list port2 10

Why it fails: 'diagnose sys session list' lists sessions, not packet captures.

diagnose debug flow port2 10

Why it fails: 'diagnose debug flow' is for flow tracing, not packet capture.

execute sniffer port2 10

Why it fails: The `execute sniffer` command displays packets in real-time on the console, making it unsuitable for *capturing* them to a file or buffer for later diagnosis as the scenario requires. This command is tempting because it offers immediate, live network traffic visibility, which is useful for quick, interactive troubleshooting where a saved capture file is not needed. However, the `10` in this command specifies a packet count to display, not a duration in seconds.

The session is using UDP protocol

Why it fails: In the FortiOS session dump, the Proto field is an IP protocol number, not a transport name. A value of 6 unambiguously identifies TCP, whereas UDP would be protocol 17. Furthermore, the proto_state=01 field is tied to the TCP state machine, so interpreting this session as UDP would contradict the protocol metadata.

The session has expired and is being removed

Why it fails: The expire value shown is 3599 seconds, a countdown of idle time remaining before the session is purged. If the session had expired, the expire counter would be at or near zero and the entry would be entering a teardown state such as FIN_WAIT or TIME_WAIT. A large remaining timer indicates the session is still active in the stateful conntrack table, not currently being removed.

The session has completed the three-way handshake and is established

Why it fails: The claim that the three-way handshake is complete is contradicted by the proto_state value. After a successful handshake, the TCP session would show an ESTABLISHED state, typically proto_state=02 depending on the FortiOS version, not 01. Because the state is 01 (SYN_SENT), only the initial SYN has been transmitted, so the session is still mid-handshake rather than established.

The users are bypassing the FortiGate

Why it fails: Bypass would mean traffic never reaches the FortiGate, so the administrator would see no policy hits, no web-filter logs, and no sessions for the affected users—all pages would simply work. The observed symptom is selective incorrect filtering, which still requires traffic to be traversing the FortiGate and being actively inspected. If users were bypassing, there would be no filtering at all, not just stale or misapplied categories.

The FortiGuard subscription has expired

Why it fails: The administrator explicitly checked and confirmed the FortiGuard subscription is valid and up to date. An expired subscription typically triggers a clear alert in the FortiGate GUI and disables live FortiGuard lookups, but it does not selectively cause some sites to be misclassified. Even with a valid subscription, the FortiGate must be able to connect to FortiGuard distribution servers over the network to receive current ratings, so the subscription alone is not the root cause.

The web filter profile is not applied to the firewall policy

Why it fails: If the web filter profile were not applied to the firewall policy, the FortiGate would perform no web filtering at all—traffic would pass according to the policy's allow/deny actions, with zero filter logs generated. That would result in all web pages being accessible, not a mix of wrongly blocked and wrongly allowed sites. The administrator already confirmed the profile is configured and applied, so the problem lies in the FortiGuard rating source, not in policy assignment.

Enable 'set ha-mgmt-interface' on the management interface

Why it fails: The 'ha-mgmt-interface' is for out-of-band management and still uses a floating IP; it does not provide a dedicated non-failover IP.

Set the management interface to be part of the HA cluster management IP

Why it fails: The cluster management IP is a floating IP that fails over; the goal is a non-failover IP.