Scenario practice questions

In an FTD cluster, what happens if the cluster control link fails?

Trap 1: The FMC takes over the cluster.

FMC is the management plane and holds no data-path role in an FTD cluster; it cannot assume forwarding when the control link drops. It is tempting because FMC configures and monitors the cluster, but cluster failover is decided by the units themselves, not the manager.

Trap 2: The cluster continues to operate normally.

Loss of the cluster control link breaks unit-to-unit state synchronisation and health messaging, so the cluster cannot keep operating unchanged. It is tempting because data interfaces and established flows may briefly persist, but the control link is what maintains cluster cohesion, so normal operation ceases.

Trap 3: The entire cluster reboots.

A control link failure does not trigger a reboot; units remain powered and keep forwarding per their failover configuration. It is tempting because loss of cluster communication sounds catastrophic, but the actual behaviour is unit isolation or failover, not a restart of every node.

A
The FMC takes over the cluster.
Why it fails: FMC is the management plane and holds no data-path role in an FTD cluster; it cannot assume forwarding when the control link drops. It is tempting because FMC configures and monitors the cluster, but cluster failover is decided by the units themselves, not the manager.
B
The cluster nodes may disable themselves to avoid split-brain.
Without the cluster control link, nodes cannot exchange heartbeat and state information, so each may assume the others have failed. To prevent a split-brain condition where both segments actively process traffic, nodes disable their data interfaces, preserving cluster integrity.
C
The cluster continues to operate normally.
Why it fails: Loss of the cluster control link breaks unit-to-unit state synchronisation and health messaging, so the cluster cannot keep operating unchanged. It is tempting because data interfaces and established flows may briefly persist, but the control link is what maintains cluster cohesion, so normal operation ceases.
D
The entire cluster reboots.
Why it fails: A control link failure does not trigger a reboot; units remain powered and keep forwarding per their failover configuration. It is tempting because loss of cluster communication sounds catastrophic, but the actual behaviour is unit isolation or failover, not a restart of every node.

Read the full NAT/PAT explanation →

Question 2hardmultiple choice

An administrator is troubleshooting an FTD device that is failing to register with FMC. The FTD has been configured with the correct FMC IP address, registration key, and NAT ID. Which additional setting must be verified on the FTD to allow successful registration?

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

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.

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

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.

Trap 3: The FTD must have the same time zone as the FMC.

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.

A
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.
B
The FTD must have a default route to reach the FMC.
For the FTD to initiate communication with FMC, it needs a route to the FMC's IP address. If FMC is on a different subnet, a default gateway or specific static route must be configured on the management interface. Without a route, the FTD cannot send registration packets to FMC, and registration will fail even if all other settings are correct.
C
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.
D
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.

Study the full Python automation breakdown →

Question 3hardmulti select

An administrator is troubleshooting an eStreamer connection between the FMC and a custom Python SIEM script. The connection is established, but no intrusion events appear in the SIEM. Which TWO potential reasons could explain why intrusion events are missing from the stream? (Choose two)

Trap 1: The SIEM script is using UDP instead of TCP for eStreamer…

eStreamer is a TCP-only protocol, so a UDP-based script could never establish the connection described in the stem. It is tempting because transport-protocol mismatches genuinely cause silent data loss in other logging integrations, and would be correct if the connection had failed to establish at all.

Trap 2: The FMC eStreamer listening port was changed from 8302 to 443.

Changing the FMC listening port does not stop events, provided the Python script connects to the new port; the connection is already established. It is tempting because port mismatches commonly break eStreamer, and would be correct if the client still targeted the default 8302 while the server moved.

Trap 3: The FTD management interface IP address is blocked by an Access…

An Access Control rule blocking the FTD management IP would halt the FMC-to-FTD management channel, not eStreamer event export, which flows from the FMC itself. It is tempting because Access Control rules do govern traffic, and blocking a management address would indeed break other FMC communications.

A
The SIEM script is using UDP instead of TCP for eStreamer communication.
Why it fails: eStreamer is a TCP-only protocol, so a UDP-based script could never establish the connection described in the stem. It is tempting because transport-protocol mismatches genuinely cause silent data loss in other logging integrations, and would be correct if the connection had failed to establish at all.
B
The FMC eStreamer listening port was changed from 8302 to 443.
Why it fails: Changing the FMC listening port does not stop events, provided the Python script connects to the new port; the connection is already established. It is tempting because port mismatches commonly break eStreamer, and would be correct if the client still targeted the default 8302 while the server moved.
C
The Access Control policy applied to the FTD devices does not have an Intrusion Policy assigned to inspect and generate events.
Without an intrusion policy bound to the access control rule, the FTD performs no intrusion inspection, so no intrusion events are generated for eStreamer to forward. The connection succeeds, but the event stream stays empty because the missing policy assignment, not transport, is the constraint.
D
The eStreamer client script failed to subscribe to intrusion event record types during the initial handshake request.
eStreamer streams only the record types the client explicitly requests during the handshake; without subscribing to intrusion event records, the connection succeeds but those events are never sent, matching the symptom of a live session with no intrusion data.
E
The FTD management interface IP address is blocked by an Access Control rule.
Why it fails: An Access Control rule blocking the FTD management IP would halt the FMC-to-FTD management channel, not eStreamer event export, which flows from the FMC itself. It is tempting because Access Control rules do govern traffic, and blocking a management address would indeed break other FMC communications.

Read the full NAT/PAT explanation →

Question 4hardmultiple choice

An FMC administrator is troubleshooting a scenario where device registration between an FTD and FMC fails immediately with a registration key mismatch error. The administrator verified the NAT ID and registration key. What underlying protocol handshake fails during this registration process, and how can it be debugged?

Trap 1: The HTTPS REST API (TCP 443) handshake fails; debug using 'debug…

FTD-FMC registration uses the SFTunnel protocol over TCP 8305, not HTTPS REST on 443; a key mismatch fails that tunnel, so 'debug rest-api' shows nothing. REST API debugging is tempting because FMC exposes it, but it governs configuration, not registration.

Trap 2: The SNMP trap receiver fails; debug using 'system support…

SNMP traps carry device telemetry and alerts, not the FTD-to-FMC registration exchange, so no trap receiver is involved when the key is rejected. It would be the right area to investigate only if the failure were a missing or malformed event notification reaching a monitoring platform.

Trap 3: The SSH tunnel (TCP 22) fails; debug using 'tail -f…

Registration between FTD and FMC runs over a TLS tunnel on TCP 8305, not SSH on TCP 22; /var/log/secure records SSH authentication events only. SSH troubleshooting would be correct if the administrator could not log into the FTD CLI itself.

A
The sftunnel (TCP 8305) handshake fails; debug using 'sftunnel status' and examining /var/log/sftunnel.log.
Device registration relies on the sftunnel daemon over TCP 8305; a key mismatch aborts that handshake before registration completes. Checking 'sftunnel status' and /var/log/sftunnel.log on the FTD reveals the negotiation failure, confirming the key or NAT ID mismatch.
B
The HTTPS REST API (TCP 443) handshake fails; debug using 'debug rest-api'.
Why it fails: FTD-FMC registration uses the SFTunnel protocol over TCP 8305, not HTTPS REST on 443; a key mismatch fails that tunnel, so 'debug rest-api' shows nothing. REST API debugging is tempting because FMC exposes it, but it governs configuration, not registration.
C
The SNMP trap receiver fails; debug using 'system support snmp-debug'.
Why it fails: SNMP traps carry device telemetry and alerts, not the FTD-to-FMC registration exchange, so no trap receiver is involved when the key is rejected. It would be the right area to investigate only if the failure were a missing or malformed event notification reaching a monitoring platform.
D
The SSH tunnel (TCP 22) fails; debug using 'tail -f /var/log/secure'.
Why it fails: Registration between FTD and FMC runs over a TLS tunnel on TCP 8305, not SSH on TCP 22; /var/log/secure records SSH authentication events only. SSH troubleshooting would be correct if the administrator could not log into the FTD CLI itself.

Question 5hardmulti select

An engineer is troubleshooting a scenario where an FTD device fails its pre-upgrade health check during an upgrade initiated from the FMC. Which THREE common pre-check failures must be resolved before proceeding? (Choose three)

Trap 1: Active SSH sessions logged into the FTD CLI.

Active SSH sessions logged into the FTD CLI do not block the pre-upgrade health check; the FMC only verifies disk space, database integrity and configuration compatibility. This option tempts because concurrent CLI access genuinely disrupts some FTD operations, such as applying certain deployments, so it would be the right answer if the question asked what prevents a configuration deployment.

Trap 2: Configured static routing tables with default gateways.

Static routes with default gateways are a normal, supported configuration and do not by themselves fail a pre-upgrade health check. Pre-check failures concern concrete blockers such as insufficient disk space, disabled management access, or failed database replication. Static routing would be relevant when verifying traffic paths, not upgrade readiness.

A
Active SSH sessions logged into the FTD CLI.
Why it fails: Active SSH sessions logged into the FTD CLI do not block the pre-upgrade health check; the FMC only verifies disk space, database integrity and configuration compatibility. This option tempts because concurrent CLI access genuinely disrupts some FTD operations, such as applying certain deployments, so it would be the right answer if the question asked what prevents a configuration deployment.
B
Unapplied pending configuration deployments between FMC and FTD.
Pending configuration changes not yet deployed from FMC to the FTD block the upgrade, because the health check requires the device's running configuration to match the FMC-managed policy. Deploying pending changes clears this pre-check failure before the upgrade proceeds.
C
Insufficient disk space on the target upgrade partition (/var or /CiscoMFT).
The upgrade process stages packages on the FTD's local partition, so inadequate free space in /var or /CiscoMFT causes the health check to fail. Freeing space or removing old images resolves this pre-check before the upgrade can continue.
D
Active critical health monitor alarms on the device.
Active critical health monitor alarms indicate the FTD is already in a degraded state, so the FMC pre-upgrade check blocks the upgrade until they clear. Resolving them satisfies the stem's requirement to pass the pre-check before proceeding.
E
Configured static routing tables with default gateways.
Why it fails: Static routes with default gateways are a normal, supported configuration and do not by themselves fail a pre-upgrade health check. Pre-check failures concern concrete blockers such as insufficient disk space, disabled management access, or failed database replication. Static routing would be relevant when verifying traffic paths, not upgrade readiness.

Review the full routing breakdown →

Question 6hardmulti select

Which THREE factors affect the choice between deploying FTD in Routed vs Transparent mode?

Trap 1: The brand of the upstream switch.

Upstream switch vendor is irrelevant: routed mode forwards on IP addressing while transparent mode bridges at Layer 2, so the deciding factors are addressing, routing participation and existing network topology. It is tempting because switch compatibility matters for inline link aggregation and spanning-tree behaviour, but brand alone never dictates the mode.

Trap 2: The number of users.

User count is handled by hardware capacity, not mode.

A
Layer 2 vs Layer 3 placement.
Routed mode operates at Layer 3, requiring IP addressing and acting as a gateway, whereas transparent mode is a Layer 2 bump-in-the-wire. This directly satisfies the stem's factor, since the required placement determines which mode fits the network design.
B
Existing network IP constraints.
Existing IP addressing schemes dictate the deployment mode. Transparent mode permits FTD to bridge traffic without re-addressing subnets, preserving the current IP topology. Routed mode requires distinct subnets on each interface, forcing re-ip addressing where overlapping or fixed addressing exists. This constraint directly determines viability.
C
The brand of the upstream switch.
Why it fails: Upstream switch vendor is irrelevant: routed mode forwards on IP addressing while transparent mode bridges at Layer 2, so the deciding factors are addressing, routing participation and existing network topology. It is tempting because switch compatibility matters for inline link aggregation and spanning-tree behaviour, but brand alone never dictates the mode.
D
The number of users.
Why it fails: User count is handled by hardware capacity, not mode.
E
Requirement for NAT or dynamic routing.
Routed mode supports NAT and dynamic routing protocols such as OSPF and BGP, whereas transparent mode operates as a Layer 2 bridge and cannot perform these functions. A requirement for either capability therefore forces routed deployment, directly satisfying the stem's constraint.

Read the full NAT/PAT explanation →

Question 7easymultiple choice

An administrator is configuring a Network Address Translation (NAT) rule on a Cisco FMC managed Threat Defense device. The requirement is to translate the source IP address of traffic coming from the inside zone going to the outside zone, but only for a specific internal subnet. Which NAT type must the administrator select in the FMC NAT rule configuration?

Trap 1: Twice NAT (Destination NAT)

Twice NAT, also called manual NAT, can translate source, destination or both, and is used when translation depends on the destination, for example policy NAT or overlapping networks. Translating only the destination, as this option describes, does not meet the requirement, which is to translate the source addresses of one internal subnet. Plain source translation for one subnet is exactly what auto NAT on a network object is designed for.

Trap 2: Prefilter NAT

There is no 'Prefilter NAT' type in Cisco Secure Firewall Threat Defense. Prefilter policies are a separate feature that decides early whether traffic is fast-pathed, blocked or passed on to full inspection, and they do not translate addresses. NAT rules are either auto NAT, defined on a network object, or manual NAT, and for one subnet's source translation, auto NAT is the right choice.

Trap 3: Manual NAT (Identity NAT)

Identity NAT translates an address to itself, so the internal subnet's traffic would leave with its real addresses unchanged. It is used to exempt traffic from other NAT rules, most commonly site-to-site VPN traffic that must keep its original addresses. The requirement here is to translate the source addresses, so identity NAT does the opposite of what is needed.

A
Twice NAT (Destination NAT)
Why it fails: Twice NAT, also called manual NAT, can translate source, destination or both, and is used when translation depends on the destination, for example policy NAT or overlapping networks. Translating only the destination, as this option describes, does not meet the requirement, which is to translate the source addresses of one internal subnet. Plain source translation for one subnet is exactly what auto NAT on a network object is designed for.
B
Prefilter NAT
Why it fails: There is no 'Prefilter NAT' type in Cisco Secure Firewall Threat Defense. Prefilter policies are a separate feature that decides early whether traffic is fast-pathed, blocked or passed on to full inspection, and they do not translate addresses. NAT rules are either auto NAT, defined on a network object, or manual NAT, and for one subnet's source translation, auto NAT is the right choice.
C
Auto NAT (Object NAT)
Auto NAT, or object NAT, is defined on a single network object, here the internal subnet, and translates only that object's source address between the chosen interfaces or zones. For outbound internet access it is usually dynamic PAT to the outside interface address. It is the simplest and recommended way to do ordinary source NAT, while manual NAT is reserved for translations that depend on the destination or need precise ordering.
D
Manual NAT (Identity NAT)
Why it fails: Identity NAT translates an address to itself, so the internal subnet's traffic would leave with its real addresses unchanged. It is used to exempt traffic from other NAT rules, most commonly site-to-site VPN traffic that must keep its original addresses. The requirement here is to translate the source addresses, so identity NAT does the opposite of what is needed.

Question 8hardmulti select

Which THREE features are critical for maintaining a stable FTD cluster?

Trap 1: Individual IP addresses for every member on every network.

The cluster uses a virtual IP for the network.

Trap 2: External load balancer for traffic scrubbing.

The cluster is self-contained.

A
Individual IP addresses for every member on every network.
Why it fails: The cluster uses a virtual IP for the network.
B
Synchronized FMC management.
Cluster stability depends on all nodes being managed consistently, so synchronised FMC management ensures uniform policy and configuration across every unit. This satisfies the stem's requirement for a critical feature, since divergent management causes inconsistent cluster behaviour and node instability.
C
EtherChannel (Port Channel) for data traffic.
An EtherChannel bundles the data interfaces across cluster nodes, providing the redundant, high-bandwidth transport that carries traffic through the cluster. This satisfies the stem's requirement for a critical feature, as the data path must survive individual link or node failure.
D
External load balancer for traffic scrubbing.
Why it fails: The cluster is self-contained.
E
Dedicated cluster control link.
The cluster control link carries heartbeat, state replication and director election traffic between nodes. A dedicated CCL isolates this control plane from data traffic, satisfying the stem's requirement for a critical feature, since a shared or congested link destabilises the cluster.

Question 9easymultiple choice

Which deployment scenario represents the correct use case for deploying a Cisco Secure Firewall Threat Defense in passive NGIPS mode?

Trap 1: Acting as the default Layer 3 gateway and DHCP server for guest…

A passive NGIPS does not forward packets, so it cannot serve as a Layer 3 gateway or DHCP server for guest clients. Those roles require a routed firewall interface with an IP address; passive mode is correct for monitoring mirrored traffic without affecting forwarding.

Trap 2: Terminating remote access AnyConnect VPN tunnels for mobile…

Passive NGIPS only copies traffic for detection and cannot terminate VPN tunnels, which require an inline device holding the session state. It is tempting because the firewall appliance does support AnyConnect termination when deployed inline in routed or transparent mode, which is the scenario where that use case belongs.

Trap 3: Inline inspection of all core data center traffic where blocking…

Passive NGIPS only detects and alerts on a traffic copy; it cannot drop malicious packets because it sits outside the forwarding path. Inline inspection is correct when blocking is mandatory, as the sensor must be in the packet path to enforce verdicts.

A
Out-of-band monitoring of core switch traffic using a SPAN port to detect threats without impacting production latency.
Passive NGIPS receives a copy of traffic from a SPAN port, so it inspects and alerts without sitting inline. This satisfies the out-of-band requirement, since no packets traverse the sensor and production latency and throughput remain unaffected.
B
Acting as the default Layer 3 gateway and DHCP server for guest Wi-Fi users.
Why it fails: A passive NGIPS does not forward packets, so it cannot serve as a Layer 3 gateway or DHCP server for guest clients. Those roles require a routed firewall interface with an IP address; passive mode is correct for monitoring mirrored traffic without affecting forwarding.
C
Terminating remote access AnyConnect VPN tunnels for mobile employees.
Why it fails: Passive NGIPS only copies traffic for detection and cannot terminate VPN tunnels, which require an inline device holding the session state. It is tempting because the firewall appliance does support AnyConnect termination when deployed inline in routed or transparent mode, which is the scenario where that use case belongs.
D
Inline inspection of all core data center traffic where blocking malicious packets is mandatory.
Why it fails: Passive NGIPS only detects and alerts on a traffic copy; it cannot drop malicious packets because it sits outside the forwarding path. Inline inspection is correct when blocking is mandatory, as the sensor must be in the packet path to enforce verdicts.

Question 10hardmultiple choice

An engineer is configuring a Cisco Secure Firewall Threat Defense cluster in a data center. To ensure high availability and prevent split-brain scenarios, what is the specific function of the cluster control link (CCL)?

Trap 1: It serves as the dedicated data forwarding path for all east-west…

Data traffic traverses the cluster's data interfaces and is distributed by the load-balancing algorithm; the CCL only forwards traffic when a flow must reach another node. It is tempting because the CCL does carry redirected packets, but it is not the primary east-west forwarding path.

Trap 2: It offloads all Snort inspection processing from data nodes to the…

Snort inspection runs distributed across all data nodes in the cluster; the control node handles cluster membership and synchronisation, not inspection offload. The CCL transports state updates and heartbeats, so it cannot serve as an inspection pipeline.

Trap 3: It connects the cluster directly to the Cisco FMC management cloud…

The CCL carries cluster control and state synchronisation traffic between nodes, not management-plane connectivity to the FMC, which uses a separate management interface. Confusing the two is tempting because both are dedicated links, but FMC communication never traverses the CCL.

A
It serves as the dedicated data forwarding path for all east-west traffic between different subnets.
Why it fails: Data traffic traverses the cluster's data interfaces and is distributed by the load-balancing algorithm; the CCL only forwards traffic when a flow must reach another node. It is tempting because the CCL does carry redirected packets, but it is not the primary east-west forwarding path.
B
It synchronizes configuration, connection state tables, and heartbeat health checks between cluster members.
The cluster control link carries heartbeat health checks plus stateful failover traffic — connection state tables and configuration synchronisation — between cluster members. Continuous heartbeats over this dedicated link let each unit detect peer failure, so a node cannot unilaterally assume active status and cause a split-brain condition.
C
It offloads all Snort inspection processing from data nodes to the control node.
Why it fails: Snort inspection runs distributed across all data nodes in the cluster; the control node handles cluster membership and synchronisation, not inspection offload. The CCL transports state updates and heartbeats, so it cannot serve as an inspection pipeline.
D
It connects the cluster directly to the Cisco FMC management cloud over an encrypted TLS tunnel.
Why it fails: The CCL carries cluster control and state synchronisation traffic between nodes, not management-plane connectivity to the FMC, which uses a separate management interface. Confusing the two is tempting because both are dedicated links, but FMC communication never traverses the CCL.

Question 11hardmulti select

An administrator is analyzing a troubleshooting scenario involving Snort inspection crashes on an FTD device. Which THREE locations or tools should the administrator check to diagnose why the Snort process restarted or crashed? (Choose three)

Trap 1: Check the Cisco Smart Software Manager portal for license…

Licence expiry in Cisco Smart Software Manager affects feature entitlement, not Snort process stability, so it cannot explain a crash or restart. It is tempting because licensing alerts do cause inspection outages on some platforms, and would be correct when traffic fails after a registration or entitlement lapse rather than the Snort engine restarting.

Trap 2: Inspect the DHCP lease logs in /var/log/dhcpd.log.

DHCP lease logs record address assignment, containing no Snort engine, inspector or crash data, so they cannot explain the restart. It is tempting because DHCP faults can break traffic flow, and would be correct when diagnosing clients failing to obtain addresses or duplicate-IP conflicts rather than an inspection process crash.

A
Check the Cisco Smart Software Manager portal for license expiration alerts.
Why it fails: Licence expiry in Cisco Smart Software Manager affects feature entitlement, not Snort process stability, so it cannot explain a crash or restart. It is tempting because licensing alerts do cause inspection outages on some platforms, and would be correct when traffic fails after a registration or entitlement lapse rather than the Snort engine restarting.
B
Inspect the DHCP lease logs in /var/log/dhcpd.log.
Why it fails: DHCP lease logs record address assignment, containing no Snort engine, inspector or crash data, so they cannot explain the restart. It is tempting because DHCP faults can break traffic flow, and would be correct when diagnosing clients failing to obtain addresses or duplicate-IP conflicts rather than an inspection process crash.
C
Examine /var/log/messages and system log files for Out-Of-Memory (OOM) killer events targeting Snort.
Examining /var/log/messages reveals kernel-level OOM killer events that terminate the Snort process when memory is exhausted, directly addressing the crash diagnosis. This log records the specific process killed and memory pressure at the time, confirming whether resource exhaustion, rather than a configuration fault, caused the restart.
D
Review Snort runtime error logs located in /var/log/snort/ or via FMC health alerts.
Snort runtime error logs in /var/log/snort/, plus FMC health alerts, capture inspection-engine faults and crash notifications specific to the Snort process. This satisfies the stem's requirement to diagnose the cause of Snort restarts or crashes.
E
Check for core dump files generated in the crash directories using 'system support clean-core' or expert mode listing.
Core dumps preserve the crashed Snort process memory image, enabling backtrace analysis of the faulting instruction. Checking crash directories via expert mode or 'system support clean-core' satisfies the stem's need to determine why Snort crashed.

Question 12hardmulti select

An engineer is troubleshooting a scenario where Security Group Tags (SGTs) are not being enforced by FTD access control rules despite an active pxGrid connection between ISE and FMC. Which TWO potential causes should the engineer investigate? (Choose two)

Trap 1: The FTD management interface IP address is not registered in Active…

Active Directory registration of the FTD management address is irrelevant to SGT enforcement; tags arrive via pxGrid from ISE, not LDAP. It is tempting because AD integration is often suspected in identity-based troubleshooting. The actual dependency is the pxGrid subscription and SGT metadata reaching FMC, which AD registration does not affect.

Trap 2: The FMC eStreamer service is disabled, blocking SGT updates.

eStreamer streams event data from FMC to external collectors; it does not carry SGT metadata to FTD. It is tempting because eStreamer is an FMC service engineers associate with identity data flows. SGT propagation relies on the pxGrid session and FMC's identity source configuration, so disabling eStreamer would not stop tag enforcement.

Trap 3: Syslog facility local0 is not configured on the switch.

Syslog facility local0 governs logging destination on the switch, not SGT propagation or enforcement. It is tempting because syslog configuration is commonly checked when device telemetry appears missing. SGT enforcement depends on tag metadata reaching FTD through pxGrid and the identity policy, so logging facility settings cannot cause rules to ignore tags.

A
The FTD management interface IP address is not registered in Active Directory.
Why it fails: Active Directory registration of the FTD management address is irrelevant to SGT enforcement; tags arrive via pxGrid from ISE, not LDAP. It is tempting because AD integration is often suspected in identity-based troubleshooting. The actual dependency is the pxGrid subscription and SGT metadata reaching FMC, which AD registration does not affect.
B
The FMC eStreamer service is disabled, blocking SGT updates.
Why it fails: eStreamer streams event data from FMC to external collectors; it does not carry SGT metadata to FTD. It is tempting because eStreamer is an FMC service engineers associate with identity data flows. SGT propagation relies on the pxGrid session and FMC's identity source configuration, so disabling eStreamer would not stop tag enforcement.
C
SXP peering or inline TrustSec header propagation is missing along the data path between the endpoint and the FTD interface.
SGT enforcement requires the tag to survive transit, not merely reach FMC via pxGrid. Without SXP peering or inline TrustSec header propagation, the FTD interface receives untagged traffic, so access control rules matching SGTs cannot evaluate the endpoint's group.
D
Syslog facility local0 is not configured on the switch.
Why it fails: Syslog facility local0 governs logging destination on the switch, not SGT propagation or enforcement. It is tempting because syslog configuration is commonly checked when device telemetry appears missing. SGT enforcement depends on tag metadata reaching FTD through pxGrid and the identity policy, so logging facility settings cannot cause rules to ignore tags.
E
The Access Control policy rules do not have the corresponding Security Group Tags selected under the Users/SGT tab.
Even with pxGrid delivering SGT metadata, enforcement fails if the access control rule itself lacks the matching SGT object selected under the Users/SGT tab. The rule then matches no tagged identity, so traffic bypasses the intended SGT-based action.

Question 13mediummultiple choice

An administrator is troubleshooting a scenario where configuration deployment from FMC to an FTD device fails with a 'Deployment Validation Error'. Where can the administrator view the detailed validation messages and deployment task history?

Trap 1: Objects > Object Management > History

Object Management History tracks changes made to reusable objects such as network and port objects, not deployment tasks. Validation messages from a failed FMC-to-FTD push appear under the device's deployment history. Object history suits auditing who edited a shared object.

Trap 2: Analysis > Intrusions > Events

Intrusion Events displays IPS and Snort alert data generated by traffic inspection, not configuration deployment records. Validation messages from a failed FMC-to-FTD deployment appear in the device's deployment history. Intrusion Events suits investigating detected threats.

Trap 3: Devices > Platform Settings > Deployment Log

Platform Settings holds device-level configuration such as access lists and syslog, not deployment task records. Validation errors from a failed push are surfaced in the device's deployment history in FMC. Platform Settings suits configuring device behaviour, not reviewing deployment outcomes.

A
Objects > Object Management > History
Why it fails: Object Management History tracks changes made to reusable objects such as network and port objects, not deployment tasks. Validation messages from a failed FMC-to-FTD push appear under the device's deployment history. Object history suits auditing who edited a shared object.
B
System > Monitoring > Task Manager
The Task Manager records every deployment attempt and its validation messages, so it satisfies the need to view detailed failure reasons and task history. Deployment Validation Errors surface here rather than in FMC health monitors or device logs.
C
Analysis > Intrusions > Events
Why it fails: Intrusion Events displays IPS and Snort alert data generated by traffic inspection, not configuration deployment records. Validation messages from a failed FMC-to-FTD deployment appear in the device's deployment history. Intrusion Events suits investigating detected threats.
D
Devices > Platform Settings > Deployment Log
Why it fails: Platform Settings holds device-level configuration such as access lists and syslog, not deployment task records. Validation errors from a failed push are surfaced in the device's deployment history in FMC. Platform Settings suits configuring device behaviour, not reviewing deployment outcomes.