Which Command Should the Administrator Use Practice Questions

The SXP secret password does not match between ISE and the firewall.

Why it fails: SXP carries SGT-to-IP mappings over a shared secret; it plays no part in certificate enrolment or trust. A mismatched SXP secret would break identity mapping propagation between ISE and the firewall, which is the correct diagnosis when mappings fail to appear rather than when the pxGrid certificate chain is rejected.

The pxGrid subscriber profile on ISE was not approved within 24 hours.

Why it fails: Certificate trust depends on the ISE pxGrid node's certificate being issued by a CA the firewall trusts, not on subscriber approval state. The 24-hour approval window governs pxGrid subscriber registration, so it would be the correct concern when a subscriber's account remains pending rather than when certificate validation fails.

RADIUS shared secrets are mismatched on the Policy Service Nodes.

Why it fails: RADIUS shared secrets authenticate RADIUS requests and have no bearing on pxGrid certificate trust. Mismatched secrets are the correct diagnosis when RADIUS authentications fail, not when the firewall rejects the ISE pxGrid node's certificate chain.

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.

Prefilter FastPath Rate Cap

Why it fails: Prefilter FastPath Rate Cap sets an early, pre-filter throughput ceiling for offloaded flows; it does not enforce a QoS policing rate within a policy map. Policing requires configuring the maximum-rate parameter on the policer itself. FastPath caps suit early traffic suppression, not per-class bandwidth enforcement.

Access Control Rate Limiting action

Why it fails: Access control rate limiting throttles connections matching an access control rule, operating before QoS policy evaluation and applying per-rule rather than per-class. Policing enforces a maximum bandwidth within a QoS policy map. Access control rate limiting suits blocking abusive connection rates, not interface bandwidth policing.

Random Early Detection (RED) drop threshold

Why it fails: RED is a congestion-avoidance mechanism that probabilistically drops packets as a queue approaches its threshold; it does not cap bandwidth. Policing needs a configured maximum rate with conform/exceed actions. RED would be chosen to smooth bursty TCP traffic and avoid tail drop, not to enforce a bandwidth limit.

Disable SSL/TLS verification in the FMC Platform Settings under the eStreamer daemon parameters.

Why it fails: No FMC Platform Setting disables eStreamer certificate verification; the client application performs that validation, so the toggle does not exist there. It is tempting because disabling verification is a common quick fix, and would be correct only as a temporary client-side workaround while importing the FMC certificate.

Restart the Snort inspection engine on all managed FTD devices.

Why it fails: Snort handles packet inspection on managed FTD devices and has no role in the FMC's eStreamer TLS handshake, so restarting it cannot resolve certificate validation. It is tempting because restarting services is a habitual fix, and would be correct when inspection engines stall or rules fail to load.

Change the eStreamer listening port from 8302 to 443 in the FMC System Preferences.

Why it fails: The eStreamer daemon listens on TCP 8302 by design, and moving it to 443 does not alter the certificate chain the client validates. It is tempting because 443 is the familiar TLS port, and would be correct when a firewall blocks 8302 and a permitted port must be chosen.

Objects > Object Management > Network > Routes

Why it fails: Objects > Object Management holds reusable network objects such as hosts and ranges, not per-device routing tables, so static and dynamic routes cannot be viewed or edited there. It is tempting because it is the obvious network-related menu, and would be correct for defining address objects reused in policies.

System > Configuration > Network Settings

Why it fails: System > Configuration covers FMC appliance settings such as time, licensing and backups, not managed FTD routing tables. It is tempting because it is where platform-level network settings live, and would be correct for configuring the FMC's own management interface rather than device routes.

Policies > Access Control > Routing

Why it fails: Routing configuration lives under Devices > Device Management, per-device Routing tab; the Policies > Access Control section holds access control policies, not routing tables. It tempts administrators because FMC groups most device policy under Policies, but static and dynamic routes are edited in the device's own platform settings.

Run 'debug syslog all' from the FTD expert mode.

Why it fails: 'debug syslog all' is not a valid FTD expert-mode command; FTD's syslog path is inspected via the CLI's system support trace or packet-tracer utilities. Debug commands suit classic ASA troubleshooting, not the FTD containerised architecture where such debugging is unsupported.

Use 'system support reset-logging'.

Why it fails: 'system support reset-logging' clears logging state rather than showing whether the syslog process is transmitting out the management or data interface. It would suit recovering a stuck logging daemon, but the stem needs visibility into egress interface selection, which this command does not provide.

Check the FMC dashboard under System > Logging > Syslog status.

Why it fails: The FMC dashboard reports configured logging destinations and status, not which interface the FTD's syslog process actually egresses. It would suit centralised policy verification, but the stem asks for CLI-level confirmation of packet egress path, which FMC cannot show.

/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.

The Port Channel must be configured in static mode (ON) regardless of the upstream switch settings to avoid LACP PDUs dropping.

Why it fails: Static ON mode disables LACP entirely, so no PDUs are exchanged and negotiation with an LACP-configured switch fails. It is tempting because static EtherChannels avoid protocol overhead, but that mode suits switches deliberately configured without LACP, not the 802.3ad negotiation this scenario requires.

The EtherChannel must use Source-Destination IP hashing exclusively, as MAC-based hashing is unsupported on FTD.

Why it fails: FTD port channels support multiple hash algorithms, including source-destination IP and MAC-based options, so mandating IP hashing exclusively is false. It is tempting because load-balancing hash selection matters for throughput, but LACP negotiation depends on matching rates, modes and channel-group membership, not on a single mandatory hash.

LACP fast rate (1-second timer) is mandatory for FTD clustering but optional for standalone firewalls.

Why it fails: LACP fast rate is a configurable timer option, not a clustering prerequisite; slow rate (30-second) works in both standalone and clustered deployments. It is tempting because faster failure detection aids convergence, but the actual requirement is consistent rate and mode settings on both channel endpoints.

In Objects > Object Management > Access Control > SGT Objects.

Why it fails: SGT Objects under Object Management only define and name Security Group Tags; they do not attach an SGT condition to a rule. It is tempting because SGTs are the correct matching criterion, but that object page is for creating reusable tag definitions, not for placing the condition in the rule wizard.

In the Platform Settings policy under Identity Sources.

Why it fails: Platform Settings configures device-level options such as identity source integration, not per-rule matching conditions, so it cannot block traffic for the Contractors SGT. It is tempting because pxGrid identity sources are configured there, but the SGT condition belongs in the Access Control rule's Users tab.

In the Access Control Rule, navigate to the Networks tab and select Security Groups.

Why it fails: The Networks tab matches source and destination IP addresses, not Security Group Tags, so selecting Security Groups there does not filter by the Contractors SGT. It is tempting because SGTs are carried in the packet, but the correct location is the rule's Users tab.

Insufficient license.

Why it fails: Licensing gates feature availability, not LACP negotiation; an unlicensed FTD still forms bundles, so the Up/Down state persists regardless. Licence checks apply when features such as malware inspection are unavailable, not when member interfaces fail to join.

The FTD is in transparent mode.

Why it fails: Transparent mode changes addressing and routing behaviour, but port channels form in both routed and transparent deployments, so the mode does not cause Up/Down. Transparent mode is chosen when the FTD must act as a bump-in-the-wire without IP re-addressing.

Physical cable damage.

Why it fails: Cable damage would drop the member interface to down/down, not leave the bundle Up/Down with a link that is physically up. Cable testing is the correct step when an individual interface shows no link, not when the port channel reports a member mismatch.

The Cluster Control Link (CCL)

Why it fails: The Cluster Control Link is used for inter-chassis clustering, not Active/Standby failover. It is tempting because both are dedicated peer links, but the CCL carries cluster heartbeats and data replication, whereas stateful failover synchronisation uses the dedicated failover interface, so this misidentifies the required link.

The Management Interface (eth0)

Why it fails: The management interface carries administrative access and management-plane traffic, not stateful failover synchronisation. It is tempting because management connectivity must be healthy for the pair, but failover state is exchanged over the dedicated failover link, so verifying eth0 leaves the actual fault unchecked.

The Diagnostic Interface

Why it fails: The diagnostic interface carries diagnostic logging and packet capture traffic, not failover state synchronisation. It is tempting because it is a dedicated physical port on the appliance, but stateful failover requires the dedicated failover link between peers, so checking the diagnostic port would not restore synchronisation.

Transparent mode with inline bypass enabled

Why it fails: Transparent mode with inline bypass still places the firewall physically inline, so traffic traverses it; bypass only preserves forwarding when the device fails, not under high load, and it is not out-of-band. It would suit an inline IPS needing failure resilience, not passive monitoring.

Inline deployment mode with fail-open enabled

Why it fails: Inline deployment places the firewall directly in the traffic path; fail-open only covers device failure, and high load can still drop packets, so it cannot guarantee zero production impact. It would be correct for an inline IPS where blocking is required, not passive out-of-band monitoring.

Routed mode with asymmetric routing tolerance

Why it fails: Routed mode requires the firewall to be a Layer 3 hop in the forwarding path, so production traffic must pass through it and asymmetric flows may be dropped. It would be correct for a routed, in-path firewall performing NAT and routing, not for out-of-band inspection.

Static NAT

Why it fails: Static NAT maps one internal address to one external address, so a /24 cannot collapse to the single IP 203.0.113.50. It is tempting for inbound publishing of a specific server, which is exactly where static NAT belongs, not for many-to-one subnet translation.

Static Identity NAT

Why it fails: Static identity NAT maps each inside address to itself, preserving 10.10.10.x on the outside, so 10.10.10.0/24 is never translated to 203.0.113.50. It is tempting because identity NAT genuinely suits exempting traffic from translation, such as VPN or site-to-site flows, but that is not this requirement.

Dynamic NAT

Why it fails: Dynamic NAT with a single mapped address cannot translate a /24 subnet, since it requires a pool at least as large as the source range. It is tempting for outbound translation, but PAT (dynamic NAT with port address translation) is the type that maps many hosts to one IP.

The FTD must be able to resolve the FMC's hostname via DNS.

Why it fails: While DNS resolution can be used if the FMC is specified by hostname, the registration process typically uses the IP address. If the IP is provided, DNS is not required. However, if the FMC is referenced by hostname, DNS must work. But the question states the FMC IP address is configured, so DNS is not the missing piece.

The FTD must be configured with the same NAT ID as the FMC.

Why it fails: The NAT ID is used when multiple FTDs are behind a NAT device; it must match the NAT ID configured on FMC for that device. However, the question states the NAT ID is already configured correctly. Therefore, this is not the missing setting. The NAT ID is not the same as the FMC's NAT ID; it is a unique identifier for the FTD.

The FTD must have the same time zone as the FMC.

Why it fails: Time zone mismatch does not prevent registration; it may affect log timestamps but not the registration process. NTP synchronization is important for certificate validation, but time zone alone is not a requirement. Registration relies on network connectivity and correct credentials, not time zone settings.

Within the Access Control Policy rules

Why it fails: Access control rules match and allow or block traffic by zone, network, and application; they contain no bandwidth or rate-limiting parameters. QoS shaping lives in the QoS policy, which is bound to an interface via FlexConfig or the platform's QoS settings. Access control is correct when the requirement is permitting or denying specific flows.

Under the Platform Settings

Why it fails: Platform Settings hold interface-level options such as fragmentation, ICMP, and timeout behaviour, not traffic-shaping classes or rate limits. QoS requires a dedicated QoS policy applied to the egress interface. Platform Settings would be the right location for adjusting how the device itself handles packets, such as MTU or ICMP responses.

In the Prefilter Policy

Why it fails: Prefilter policies perform early fast-path actions like tunnel and SSL decryption bypass before access control; they carry no bandwidth-limiting parameters. QoS needs a QoS policy bound to the interface. Prefilter is correct when the goal is excluding traffic from deeper inspection, not shaping throughput.