High Availability and Diagnostics practice questions

Remove the latency performance SLA and rely only on jitter.

Why wrong: Removing latency from the performance SLA leaves jitter as the only measured metric, so the SD-WAN health check will no longer flag the MPLS link when latency climbs. Since voice QoS is degraded by high one-way delay, the rule would keep sending traffic along the high-latency MPLS path and failover never triggers. That defeats the purpose of steering voice traffic away from an underperforming link.

Increase the jitter threshold to 15 ms to avoid SLA violations.

Why wrong: Raising the jitter threshold to 15 ms only makes the SLA more tolerant to jitter; it has no effect on the latency measurement that is causing the MPLS link to be down. If the latency metric is already part of the SLA, reducing the bar for a different metric won't prevent the violation. It could even mask genuine jitter problems, making voice quality worse while still failing over for latency only when latency itself reaches the threshold.

Disable SLA enforcement on the SD-WAN rule so voice traffic always uses the MPLS link.

Why wrong: Disabling SLA enforcement removes the link health check from the SD-WAN rule, so FortiGate will not evaluate MPLS latency and will never move traffic to the broadband link. The rule would unconditionally pin voice traffic to MPLS, including when latency is high, because there is no failure condition to trigger the secondary strategy. This is the opposite of what is needed for latency-sensitive VoIP.

The secondary unit has an override enabled.

Why wrong: 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 wrong: 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 wrong: 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.

HA priority

Why wrong: HA priority is a configurable value used to elect the primary unit in a cluster, but it does not need to match across peers. In active-active HA, both units handle traffic, yet the primary is determined by the higher priority (with tiebreakers); setting different priorities allows administrators to control which unit takes the lead. Therefore, priority can differ and is not a setting that must be identical.

Management IP address

Why wrong: Each FortiGate in an HA pair must have a unique management IP address so that it can be individually reached for administration and monitoring. The management IP addresses are typically configured differently on each unit; in fact, the HA management interface is often set to a standalone address or managed via the cluster's virtual IP. Thus, management IPs are not required to match, and forcing them to match would cause IP conflicts on the network.

Hostname

Why wrong: Hostname is simply a local, administrative label used for device identification in the CLI or GUI; it has no impact on HA functionality. Each unit can have a different hostname without affecting the cluster's operation, as FortiGate does not use hostname to identify cluster peers. Therefore, hostnames do not need to match in an active-active HA cluster.

Heartbeat interfaces must be in the same VDOM.

Why wrong: HA heartbeat interfaces are configured globally in the HA settings and are not tied to any specific VDOM. Even on FortiGates running multiple VDOMs, the same physical interface can carry heartbeat traffic while simultaneously being assigned to different VDOMs or even no VDOM at all. The heartbeat protocol operates below the VDOM layer, so VDOM membership has no effect on heartbeat communication.

Heartbeat interfaces must be dedicated management ports.

Why wrong: FortiGate HA heartbeat links are not required to use dedicated management ports; any physical data port can be designated as a heartbeat interface. Management ports such as the MGMT port are typically reserved for out-of-band administrative access and may not even be capable of carrying HA traffic on all models. For optimal reliability you should use a dedicated internal switch or a crossover cable on a regular interface, not the management port.

Only two heartbeat interfaces can be configured.

Why wrong: FortiGate supports multiple heartbeat interfaces, not just two; the exact maximum depends on the platform, but it is typically up to eight. You can configure several heartbeat links concurrently to provide redundancy and to increase session-synchronization bandwidth by setting them in override mode or as backup links. Limiting HA to two heartbeat interfaces is not a platform constraint, so this statement is false.

SD-WAN rules must use a 'load balancing' strategy.

Why wrong: The 'load balancing' strategy is only one of several selectable strategies within an SD-WAN rule. Administrators can also choose 'manual' to pin traffic to a specific member, or 'best quality' to dynamically select the member with the best measured quality, so a load balancing strategy is not a mandatory requirement for every rule.

Each SD-WAN rule can only contain one member.

Why wrong: A single SD-WAN rule can contain multiple members, which are the physical or tunnel interfaces participating in the SD-WAN zone. The rule's strategy determines how these members are utilized, such as distributing sessions across several interfaces for load balancing or selecting the best-performing member based on health-check probes, so restricting rules to a single member would defeat the purpose of SD-WAN.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Session pickup is not enabled on the new FortiGate.

Why wrong: Session pickup is a feature that preserves existing TCP/UDP sessions when a failover occurs, but its absence does not cause continuous interface-level traffic drops. Since the cluster is operational and session pickup is confirmed to be configured and working, the secondary already carries over active sessions without interruption. A disabled session pickup would only cause transient session loss during a failover, not the persistent, intermittent traffic drop described. Therefore, the problem is not related to session pickup.

The HA cluster is in split-brain state.

Why wrong: Split-brain is a condition where both HA units independently assume the primary role because heartbeat communication fails, causing both to process traffic and create IP conflicts. The cluster status explicitly shows one primary and one secondary, proving that heartbeat and role negotiation are functioning normally. Since split-brain would display as two primary units, not a distinct primary/secondary pair, it cannot be the cause of the reported instability. Thus, this option is incorrect.

The heartbeat interface is configured on the LAG, causing HA instability.

Why wrong: Configuring the HA heartbeat interface on a LAG (link aggregation group) is an unsupported and unstable design because heartbeat packets rely on a stable, dedicated physical link for timely failover detection. If the heartbeat were on a LAG, any member link flap or aggregation renegotiation could cause HA to misinterpret peer availability and trigger unnecessary failovers. The existing note that heartbeat should not be on a LAG indicates this is not the actual configuration, and the cluster status shows a consistent primary/secondary relationship. Hence, this is not the reason for the traffic drops.

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 wrong: 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 wrong: 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 wrong: 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.

Set HA override to enabled.

Why wrong: HA override is a preemption control that determines whether a previously failed primary unit can reclaim its role by forcing the current primary to relinquish it. This setting affects role selection during failover and recovery, but it has no impact on what session state is copied between cluster members. Enabling override could even trigger unnecessary switchovers, but it will not cause UDP session tables to be populated on the standby.

Enable configuration synchronization.

Why wrong: Configuration synchronization copies the FortiGate's policy, object, and system settings from the primary to the standby so that both units enforce identical rules. This is an automatic FGCP function, but it operates at the static configuration layer, not on the dynamic session table. Even with perfectly synchronized configurations, the standby unit still has no knowledge of existing UDP flows unless session synchronization and session pickup are explicitly enabled.

Set failover hold time to 1 second.

Why wrong: Failover hold time is the delay before a standby unit assumes the primary role after detecting a failure in the active unit. Lowering it to 1 second makes failover happen more quickly, but it does not affect whether any session data is synchronized prior to the failure. The standby's session table remains empty or stale if UDP session synchronization is disabled, so a fast failover still results in dropped UDP flows and broken application connections.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Static routing: routes learned via routing protocols

Why wrong: This statement is incorrect because 'routes learned via routing protocols' is the definition of dynamic routing, not static routing. Static routes are manually configured by an administrator and have no underlying protocol to discover or update routes automatically. The key distinction is that static routes are fixed and require manual intervention to change, whereas dynamic routes are automatically populated and updated by protocols like OSPF or BGP.

Dynamic routing: routing based on packet attributes

Why wrong: This statement is incorrect because dynamic routing bases path selection on network topology and protocol metrics, such as OSPF cost or BGP AS-path length, not on packet attributes. 'Routing based on packet attributes' is the definition of policy-based routing (PBR), which overrides normal destination-based routing for traffic matching specific conditions. Dynamic routing builds a global view of reachable networks and then forwards packets according to the best metric, not per-flow conditions.

Lower HA priority on the primary

Why wrong: Lowering HA priority on the primary only affects the election of which unit becomes active through the configured priority value; it does not trigger any transfer of firewall session state. In active-passive HA, the standby unit's session table is empty unless synchronous state replication is enabled, so changing priority would simply reselect a primary without providing session continuity. Since failover would still drop active connections, priority adjustment is an election mechanism, not a synchronization mechanism.

Set HA override to enabled

Why wrong: Setting HA override to enabled configures preemption, where a higher-priority unit will reclaim primary status after a failure is resolved, even if the current primary is healthy. This setting does not influence how or whether sessions are mirrored to the peer; it only changes the failover/rollback behavior. In fact, enabling override may cause additional failover events, which, without session pickup, would repeatedly interrupt traffic, so it is a management option rather than a session-continuity feature.

Increase the heartbeat interval

Why wrong: Increasing the heartbeat interval means the units will wait longer between heartbeat probes, which increases the time needed to detect a peer failure and delays any failover. This makes the HA cluster less responsive and does nothing to populate the standby's session table with active sessions. Since session synchronization is separate from heartbeat traffic, adjusting the interval cannot preserve connections; it only affects the failure-detection timer.

The maximum number of packets to capture

Why wrong: 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 wrong: There is no time duration parameter; the count parameter limits packets.

The interface index

Why wrong: Interface is the first parameter, not the number.

The heartbeat interface speed is mismatched

Why wrong: 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 wrong: 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 wrong: 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.

Check the routing table for the destination

Why wrong: The `diagnose debug flow` output explicitly showed the packet was received and then denied by policy; a routing-table lookup happens before policy evaluation, so if a route were missing the packet would have been dropped with a 'no route' message, not 'Deny by policy'. Verifying the routing table would only be relevant if the flow output indicated a routing failure or an implicit drop due to no route. Since the log already identifies policy as the enforcing component, investigating routing is irrelevant to this specific denial.

Restart the FortiGate to clear session table

Why wrong: Restarting the FortiGate to clear the session table is a blunt, non-surgical action that does not affect the policy definition, which is stored in configuration and reloaded unchanged after the reboot. The debug flow output shows a policy-based denial, not a stale or corrupted session entry; therefore clearing the session table would not change the outcome and would cause downtime for all traffic traversing the device. Only policies or policy objects (addresses, services, users) can be modified to resolve the denial, making a reboot both ineffective and unnecessarily disruptive.

Enable session helper for the protocol

Why wrong: Session helpers are protocol-agnostic kernel modules that handle ALG (Application Layer Gateway) tasks such as NAT64, RTSP, SIP, or FTP data-channel negotiation, and they only come into play after a session is allowed and created. A 'Deny by policy' event occurs during the initial policy lookup, before any session is established; thus enabling a session helper cannot override or bypass a firewall policy rejection. The debug flow would show a session-helper issue only if the packet was permitted but the ALG failed to parse payloads or open companion sessions, which is not the case here.

Configure syslog server

Why wrong: Configuring a syslog server is incorrect because syslog uses the standard IETF protocol (UDP/TCP port 514) with a plain text format, whereas FortiAnalyzer receives logs via a proprietary encrypted protocol that supports advanced indexing, correlation, and reporting. While FortiGate can send logs to any syslog server, a syslog server cannot replicate the automated event correlation, log aggregation, and FortiAnalyzer-specific queries available in a true FortiAnalyzer integration. The action to send logs to FortiAnalyzer is specifically performed under System > FortiAnalyzer, not by configuring a generic syslog destination.

Enable FortiCloud logging

Why wrong: Enabling FortiCloud logging is incorrect because FortiCloud is a separate cloud-based service used for FortiGate cloud management and basic logging, not an external FortiAnalyzer. When you enable FortiCloud logging, logs are sent to Fortinet's cloud infrastructure, not to your own FortiAnalyzer appliance or VM. The FortiCloud service also has different retention limits and analytics capabilities, so it does not satisfy a requirement to forward logs to an on-premises or remote FortiAnalyzer.

Enable disk logging on the FortiGate

Why wrong: Enabling disk logging on the FortiGate is incorrect because disk logging stores log entries locally on the FortiGate's internal storage, which only allows local review and does not forward logs to any external device. The purpose of sending logs to an external FortiAnalyzer is to offload storage and enable centralized log management; disk logging keeps everything on the FortiGate and can cause local log rotation or overwriting based on disk space. This option provides no network transmission of logs, so it fails the requirement to send logs to an external destination.

To synchronize session tables and configuration

Why wrong: While HA clusters must synchronize session tables and configuration, FortiGate treats this as a separate control-plane function that can use dedicated synchronization interfaces or a designated HA link. On FortiGate, heartbeat interfaces can also carry these control-plane synchronization messages, but this is secondary to their main role of monitoring peer health. Believing that synchronization is the purpose of the heartbeat interface confuses the HA control mechanisms with the liveness-detection function that actually drives failover decisions.

To provide out-of-band management access

Why wrong: Out-of-band management access is intentionally kept on a separate management interface, such as the dedicated MGMT port or an administrative VLAN, to allow administrators to reach a FortiGate even when the HA data plane is disrupted. Heartbeat interfaces are internal HA-only links and should never be used for administrative SSH, HTTPS, or SNMP traffic. Attributing management access to the heartbeat interface conflates administrative reachability with the cluster-internal liveness messaging.

To forward user traffic between cluster members

Why wrong: User traffic is forwarded through regular data interfaces—the same physical or VLAN ports that carry production traffic to and from the cluster—because those are the ports with forwarding policies, VLANs, and interface IPs. Heartbeat interfaces are isolated, non-routable HA links that exchange liveness messages and should not have user data forwarded across them. If user traffic traversed the heartbeat link, it would compete with HA monitoring and create a loop or security risk, so it is explicitly excluded from this link's role.

An antivirus profile and a routing policy

Why wrong: 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 wrong: 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 wrong: 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.