Two FTD appliances are being paired as an active/standby high availability set in the data center. Heartbeats and configuration synchronization must travel on a dedicated failover link, live connection and NAT state must survive a failover, and a flap on any single data interface must leave the active unit in charge. Which design and trigger behavior satisfies all three requirements?

The design must keep three separate concerns aligned: the dedicated failover link carries heartbeats and configuration synchronization, the state link replicates NAT and connection state, and failover triggers account for both peer health and monitored data interfaces. This preserves live sessions across a switchover while avoiding unnecessary role changes when one interface briefly flaps. Replicating NAT and most connection state but deliberately excluding selected flows is a valid optimization in some deployments, yet it cannot meet the requirement that live connection and NAT state survive failover for all relevant traffic; excluded sessions may be reset or require reconnection. Setting the monitored-interface threshold to one makes a single monitored-interface failure sufficient to trigger failover, directly violating the requirement that one flap leave the active appliance in charge. Triggering only on confirmed heartbeat loss omits data-interface monitoring, so a failed data path could leave the active unit in charge even after the configured interface-failure condition is met. Exam caveat: interface monitoring thresholds and supported state replication can vary with FTD release, platform, and HA configuration, so do not infer behavior from generic firewall conventions alone. Practical check: verify the failover and state link assignments, inspect the monitored-interface threshold and failure policy, then test a brief single-interface flap and a controlled peer-loss event while checking that representative NAT translations and connections persist.