Select Two (Multi-Select) Questions

Full memory core dump binary attachments

Why it fails: Memory core dumps are binary troubleshooting artefacts far too large for syslog, and they describe process crashes rather than connection events. It is tempting because core dumps support forensic analysis, but they are retrieved from the device directly, not attached to syslog messages.

FMC administrator SSH private keys

Why it fails: SSH private keys are authentication secrets for FMC administrators and are never emitted in syslog records; including them would expose credentials. It is tempting because administrator identity can aid investigation, but the syslog field carries the username or event user, not key material.

Raw packet captures (PCAP) of dropped connections embedded in syslog text

Why it fails: Syslog messages are text records with a size limit; embedding raw PCAP of dropped connections would bloat and truncate them, breaking SIEM parsing. It is tempting because packet data genuinely aids investigation, but it belongs in a separate capture or file export, not the syslog payload.

Decrypt - Resign (intercept and re-sign SSL certificate)

Why it fails: Decrypt - Resign is an SSL policy action, not a prefilter rule action; prefilters only Fastpath, Block, Trust, Monitor or Tunnel. It is tempting because SSL decryption rules genuinely offer Resign, but that belongs in an Access Control Policy with an SSL policy attached, not the prefilter stage.

Inspect with Snort 3 Intrusion Prevention

Why it fails: Prefilter rules act before deep inspection, choosing Trust, Block, Monitor, Fastpath or Tunnel; they cannot invoke Snort 3. Intrusion inspection is configured in the access control policy that processes traffic after prefiltering. Snort 3 inspection would be the correct choice when signature-based detection is required.

Log to Cloud

Why it fails: Access Control Rule logging writes events locally to the appliance's own log; there is no cloud logging destination in the Logging tab. It is tempting because cloud logging exists elsewhere in Firepower, but the tab's two settings are Log at Beginning and Log at End, governing connection events only.

Log every packet

Why it fails: Access Control Rule logging records connection events, not individual packets; packet-level capture belongs to the packet capture feature. It is tempting because 'Log every packet' sounds like maximum visibility, but the Logging tab's two settings are Log at Beginning and Log at End, which log connection start and close.

Log at Middle

Why it fails: Access Control Rule logging offers only 'Log at Beginning' and 'Log at End' connection events, so 'Log at Middle' does not exist. It is tempting because middle logging sounds like a granular midpoint, but the actual axis is connection setup versus teardown, with no intermediate position available.

Reduced latency.

Why it fails: A Port Channel aggregates links for redundancy and increased aggregate throughput; it does not reduce per-packet latency, which depends on path length and device processing. EtherChannel suits scenarios needing link resilience or bandwidth beyond one interface, not latency reduction.

Elimination of spanning tree.

Why it fails: Port Channels provide link redundancy and aggregated bandwidth, but spanning tree still runs on the member links and the bundle itself; it is not eliminated. The tempting benefit is loop prevention, which is what STP delivers, and Port Channels would be chosen when you need to combine multiple physical links into one logical interface.

Automatic NAT mapping.

Why it fails: Port Channels bundle links for increased bandwidth and redundancy; they operate at Layer 2 and have no bearing on address translation. Automatic NAT mapping is a separate FTD feature that translates addresses dynamically, and would be the answer if the question asked about NAT policy behaviour rather than interface aggregation.

Rely solely on local FTD disk storage and export logs via manual SCP once a week.

Why it fails: Weekly manual SCP from local disk storage is neither real-time nor reliable, and FTD local storage is limited and overwritten. It is tempting because local logging plus periodic transfer feels like a backup, but it suits archival retention, not continuous streaming to external analytics.

Disable the Snort engine to prevent log buffer congestion.

Why it fails: Disabling Snort stops the detection engine generating the very security events that must be exported, so nothing reaches the analytics tools. It is tempting as a crude way to relieve buffer pressure, but Snort is the source of the logs; the correct practice is tuning and offloading, not disabling inspection.

Configure SNMPv1 traps to poll event counters every 60 seconds.

Why it fails: SNMPv1 traps poll counters periodically and carry no event detail, so they cannot deliver real-time log records. It is tempting because SNMP is a familiar monitoring transport, and it would be correct for collecting interface and health statistics rather than security events.

/var/log/dhcpd.log

Why it fails: dhcpd.log records DHCP lease allocation on the FTD, which is unrelated to the sftunnel event channel between FTD and FMC. It is tempting because DHCP daemons do run on FTD interfaces, but transport troubleshooting requires sftunnel, the SFDataCorrelator, and the FMC's communication logs.

/var/log/samba/smb.log

Why it fails: smb.log captures Samba file-sharing activity, which no FTD or FMC component uses for event transport. It is tempting because Samba logs exist on Linux-based appliances, but the FTD-to-FMC path relies on the sftunnel daemon and the SFDataCorrelator process, not SMB services.

Configure the management interfaces to use DHCP so the standby unit can adopt the primary IP address.

Why it fails: HA peers require static, unique management IP addresses on the same subnet; DHCP cannot guarantee the fixed addressing that failover and state synchronisation depend on. DHCP suits standalone deployments where management addressing is assigned dynamically, not an Active/Standby pair sharing a virtual address.

Ensure both units are configured in different firewall modes (one routed, one transparent).

Why it fails: Both HA peers must run identical firewall modes; mismatched routed and transparent modes prevent configuration replication and failover. Different modes are chosen only when the two devices serve entirely separate, unrelated roles rather than forming a redundant pair.

Disable stateful synchronization to improve failover switching speed.

Why it fails: Stateful failover synchronisation must remain enabled so the standby retains connections and VPN state; disabling it forces session re-establishment after failover. It tempts as a latency reduction, but the required steps are configuring failover links and matching interface settings, not turning off state sharing.

Factory reset all FTD devices immediately after pushing the upgrade package.

Why it fails: A factory reset erases configuration, licences and registration, leaving the FTD unmanaged and unable to pass traffic until re-registered, which maximises downtime. Resetting is only appropriate when repurposing a device or recovering from a corrupted state, not during a planned upgrade.

Disable the sftunnel service permanently during the upgrade to prevent packet inspection.

Why it fails: sftunnel carries management and event traffic between FTD and FMC; disabling it permanently severs management, policy deployment and health monitoring. It is stopped only briefly during specific upgrade steps, then restarted, so permanent disablement is never a best practise.

NetFlow v5

Why it fails: NetFlow v5 exports IP traffic flow records for visibility and analysis; it carries no user identity or group data, so pxGrid and RADIUS-based identity sharing cannot ride on it. It is tempting because flow telemetry does feed firewall monitoring, but that is for traffic accounting, not ISE identity integration.

LDAP direct bind

Why it fails: LDAP direct bind authenticates users against a directory for login, but Threat Defense does not query ISE as an LDAP server to obtain user-to-IP mappings. It is tempting because ISE can itself connect to external LDAP stores, yet that is directory authentication, not the ISE-to-firewall identity integration.

SNMPv1

Why it fails: SNMPv1 polls device metrics and traps for monitoring; it transports no user-to-IP or group mappings, so it cannot convey ISE identity context to Threat Defense. It is tempting because SNMP is a standard management integration, but that role is device health monitoring, not identity-aware policy enforcement.

Manually delete all existing access rules

Why it fails: Access rules are preserved across an FTD upgrade, so deleting them is destructive and unnecessary; the workflow verifies compatibility and migrates policy instead. It is tempting because rule cleanup is legitimate housekeeping, but that is a separate change task, not an upgrade step.

Run a factory reset on the FTD

Why it fails: A factory reset wipes the FTD configuration and is reserved for recovery or redeployment, not routine upgrades, which preserve settings across the new image. It is tempting because resetting can resolve a failed upgrade, but that is a troubleshooting step after the workflow, not part of it.

The local NTP server stratum level must be exactly stratum 1.

Why it fails: NTP stratum level is not among Cisco's FMC/FTD upgrade compatibility checks; those cover FTD software version, FMC version, and hardware model. Stratum 1 is a timing-precision preference for appliances requiring accurate clock synchronisation, not a documented upgrade prerequisite.

The serial number of the external power supplies attached to the rack mount chassis.

Why it fails: Power supply serial numbers are hardware inventory details with no bearing on FMC-to-FTD software compatibility. Validation covers FTD and FMC software versions, managed device models and upgrade paths. The serial number is tempting because it uniquely identifies hardware, but compatibility depends on software releases and supported platforms, not PSU identifiers.

Real-time firmware updates pushed from the SecureX cloud console to the managed firewalls.

Why it fails: SecureX integration exchanges threat intelligence and observability data with FMC; it cannot push firmware images to managed Threat Defense devices, which is done through FMC device upgrades or Cisco Success Network. It is tempting because SecureX aggregates device health, but firmware distribution is a management-plane function, not a threat-intelligence action.

Replacement of local FMC policy administration with cloud-only RBAC management.

Why it fails: SecureX provides threat intelligence enrichment and casebook workflows; it does not replace FMC as the policy administration and RBAC authority for managed firewalls. It is tempting because SecureX offers a unified dashboard, but access control and policy authoring stay within FMC and its role-based configuration.

Direct deployment of Snort 3 custom intrusion rules compiled locally on the SecureX cloud platform.

Why it fails: SecureX correlates and shares threat intelligence; it has no Snort 3 rule compiler or deployment path to FTD. Custom intrusion rules are authored and compiled locally, then deployed via FMC policy. It is tempting because SecureX surfaces threat context that informs rule tuning, but compilation and enforcement remain on-premises management tasks.

Intrusion Policy Signatures

Why it fails: Intrusion policy signatures are inspected after a rule permits traffic, so they cannot match traffic within the rule itself. They tempt because intrusion policies are configured alongside access control, but matching occurs on source/destination, applications, ports and URLs instead.

Device Platform Settings

Why it fails: Device Platform Settings are endpoint attributes used in identity or posture policies, not match criteria in an FMC access control rule. They tempt because platform-based conditions exist elsewhere in Cisco security, but FMC rules match on zones, networks, ports, applications and URLs.

Convert all physical interfaces into switchports without IP addresses.

Why it fails: Converting routed interfaces to switchports without IP addresses removes Layer 3 processing but does not reduce Snort inspection load, since Snort still inspects the switched traffic. Mitigation targets rule sets, thresholds, and preprocessors. Switchport conversion suits Layer 2 segmentation designs, not Snort CPU reduction on an FTD.

Disable the FTD kernel entirely and run Snort in standalone user-space loopback mode.

Why it fails: FTD cannot disable its kernel or run Snort standalone; Snort integrates with the FTD data plane, so this breaks the appliance entirely. CPU mitigation uses Snort rule tuning, thresholding, and preprocessor configuration. Standalone Snort suits dedicated IPS deployments, not an FTD device requiring integrated inspection.

Automatic remediation of endpoint malware infections via direct quarantine commands sent from the firewall to Active Directory

Why it fails: The firewall cannot push quarantine commands to Active Directory; remediation is handled by ISE posture and ANC policies, not by the firewall. It is tempting because SGT integration with ISE enables dynamic policy changes based on identity and posture, which resembles automated quarantine in zero-trust deployments where endpoint compliance drives network access.

Replacement of traditional routing protocols with TrustSec matrix routing

Why it fails: TrustSec propagates SGT tags via inline tagging or SXP; it does not replace routing protocols, and no TrustSec matrix routing exists. It is tempting because the Security Group Tag matrix defines which group pairs may communicate, which resembles a routing or reachability policy in segmented environments where tag-based path control is desired.

Elimination of the need for access control rules on the firewall

Why it fails: TrustSec SGTs let the firewall enforce policy using security group tags, but access control rules still exist and are required to map SGT pairs to permit or deny actions. It is tempting because SGT-based enforcement reduces rule sprawl by replacing IP-based entries with tag-based ones, which suits dynamic environments where addresses change frequently.

An active eStreamer daemon listening on TCP port 8302 for SecureX incoming connection polls.

Why it fails: The eStreamer daemon pushes event data outbound from the FMC on TCP 8302; SecureX integration instead requires the cloud-registration settings and API access configured on the FMC. eStreamer suits sending events to a SIEM, not establishing the SecureX cloud connection.

A direct SSH tunnel between the FTD data plane and the SecureX cloud.

Why it fails: SecureX cloud integration uses outbound HTTPS (TCP 443) from the FMC to Cisco's cloud, not an SSH tunnel from the FTD data plane. An SSH tunnel is tempting as a generic secure transport for remote connectivity, but it is the wrong protocol and wrong endpoint for SecureX event and context ingestion.

An active pxGrid session client on every managed FTD device.

Why it fails: SecureX integration is brokered by the FMC itself via a cloud connector registration and pxGrid client on the FMC, not per-device. Requiring an active pxGrid session client on every managed FTD is tempting because pxGrid underpins identity and context sharing between Cisco platforms, but that role belongs to the FMC in this architecture.

SSL Handshake Latency

Why it fails: SSL Handshake Latency measures TLS negotiation timing for monitored connections, not CPU, memory or disk consumption, so it cannot satisfy the resource-utilisation requirement. It is tempting because it is a genuine out-of-the-box FMC health monitor, and would be correct if the question asked about encrypted-session performance degradation.

SNMP Trap Queue Depth

Why it fails: SNMP Trap Queue Depth measures outbound trap buffering, not CPU, memory or disk consumption, so it cannot satisfy the resource-utilisation requirement. It is tempting because it is a real out-of-the-box FMC health monitor, and would be correct if the question asked about SNMP trap delivery backlog instead.

BGP Peer Flap Counter

Why it fails: BGP Peer Flap Counter tracks routing adjacency instability, not CPU, memory or disk consumption, so it cannot satisfy the resource-utilisation requirement. It is tempting because it is a genuine out-of-the-box FMC health monitor, and would be the right pick when the question instead asks about monitoring routing protocol stability.

ARP

Why it fails: ARP operates at layer 2 and is not matched by Port objects, which define TCP and UDP port-based traffic in FMC. It is tempting because ARP appears in network troubleshooting, but Port objects exist for transport-layer protocols such as TCP and UDP, not link-layer resolution traffic.

IGMP

Why it fails: IGMP is a multicast group-management protocol, not one of the TCP/UDP application protocols (HTTP, FTP, SMTP, DNS, SSH) that FMC Port objects reference by port number. It is tempting because IGMP traffic does traverse firewall interfaces, but that is handled by access control policies and multicast configuration, not Port objects.

ICMP

Why it fails: ICMP is handled by access control rules and prefilter policies, not Port objects, which define TCP and UDP port-based traffic. It is tempting because ICMP appears in access rules, but Port objects exist specifically for transport-layer protocols such as TCP and UDP used by common services.

Configure an eStreamer server instance on the ISE policy service node.

Why it fails: eStreamer is an FMC-side service that sends event data to external clients; it is not configured on ISE for pxGrid. It is tempting because eStreamer also concerns FMC-to-external-system integration, but the pxGrid direction requires ISE-side client certificates and pxGrid persona enablement.

Enable SNMPv2c traps on the ISE administration node.

Why it fails: pxGrid integration relies on certificate exchange and client registration, not SNMP traps, which are for monitoring and alerting. It is tempting because SNMP is commonly enabled on ISE nodes for health monitoring, but it does not establish the pxGrid session with FMC.

Export the ISE TACACS+ shared secret to the FTD CLI.

Why it fails: pxGrid integration uses certificate-based authentication between ISE and FMC, not TACACS+ shared secrets, which serve device administration. It is tempting because TACACS+ secrets are configured on ISE for network device access, but they play no part in the pxGrid certificate exchange.

Object Description

Why it fails: A description is optional metadata; FMC requires a name plus at least one member object or network to form the group. It is tempting because descriptions aid administration and are mandatory fields on many other FMC object types, but they add no functional membership.

SNMP Traps

Why it fails: SNMP traps are monitoring settings configured elsewhere in FMC, unrelated to defining group membership. It is tempting because SNMP appears throughout FMC device and platform configuration, yet a Network Object group needs only a name and its member objects.

Routing Table

Why it fails: Routing tables belong to routers and virtual routers, not to FMC object definitions; groups contain network or object members. It is tempting because routing context matters when placing objects in policies, but the group itself requires only a name and members.