Free 300-710 Practice Test

Cisco Firepower Threat Defense (FTD) devices in a High Availability (HA) pair use a dedicated failover link to exchange state information, health monitoring messages, and configuration data. To secure this communication in sensitive environments, FTD employs IPsec to encrypt the traffic traversing the failover and stateful failover links. This is configured by defining a shared secret key on both units. This key is then used to establish IPsec security associations (SAs) between the peers, ensuring the confidentiality and integrity of all synchronization traffic.

B. SSH: SSH is a protocol used for secure remote command-line administration and is not utilized for the high-speed, stateful synchronization required for a firewall failover link.
C. SSL: SSL (and its successor, TLS) is primarily used for securing application-layer traffic, such as HTTPS, or for remote access VPNs, not for inter-appliance stateful failover communication.
D. MACsec: MACsec (IEEE 802.1AE) provides Layer 2 encryption for Ethernet links but is not the protocol implemented by Cisco FTD for securing its specific HA failover link traffic.

1. Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager

Version 7.2

High Availability for Firepower Threat Defense

Section: "Configure the Failover Link".

The documentation states

"To encrypt failover and state link communication

you can configure an IPsec encryption key... The key is used to create IPsec security associations (SAs) for the failover link."

2. Cisco Secure Firewall Management Center (FMC) Configuration Guide

Version 7.4

High Availability for Secure Firewall Threat Defense

Section: "Failover Link".

This guide confirms the mechanism

stating

"To encrypt failover and state link communication

you can configure an IPsec encryption key. We recommend that you configure a key. The key is a shared secret that is used to create IPsec security associations (SAs) for the failover link."

Cisco AMP for Endpoints (now Cisco Secure Endpoint) provides administrators with granular control to block specific files. The two primary features for this are 'Application Blocking' and 'Simple Custom Detection'.
1. Application Blocking: This feature is part of the Application Control settings within an endpoint policy. Administrators can create custom lists of applications to block, identifying them by their SHA-256 hash, path, or name. This directly prevents the execution of a specific file.
2. Simple Custom Detection: Located under Outbreak Control, this feature allows an administrator to add a file's SHA-256 hash to a global list and assign a 'Block' or 'Quarantine' disposition. This provides a rapid way to block a malicious file across the entire organization, independent of specific policies.

C. file repository: The file repository is a storage and analysis tool for files submitted from endpoints; it does not directly enforce blocking actions.
D. exclusions: Exclusions are used to prevent AMP from blocking or detecting trusted files, which is the opposite of the required action.
E. application whitelisting: This is a restrictive policy that blocks all applications not explicitly allowed, rather than a feature for blocking a specific, targeted file.

1. Cisco Secure Endpoint User Guide: In the "Policies" chapter, the "Application Control" section details the creation of block lists. It states, "Application Control allows you to create custom lists of applications to be blocked in your organization... You can add applications to a list by SHA-256, by path and file name, or by name." This directly supports option A.

2. Cisco Secure Endpoint User Guide: The "Outbreak Control" chapter, under the "Custom Detections" section, describes Simple Custom Detections. It specifies, "You can create simple custom detections for your organization based on SHA-256s. You can add individual SHA-256s to a simple custom detection list with a Block or Quarantine disposition." This directly supports option B.

3. Cisco Secure Endpoint User Guide: The "Analysis" chapter, in the "File Repository" section, describes its function: "The File Repository allows you to search for and manage files that have been submitted for analysis from your organization's hosts." This confirms the repository is for analysis, not blocking, making option C incorrect.

The issue described, where only .exe files have a disposition other than "unknown," points to a specific configuration within an active file policy. The Cisco Firepower system uses different engines for file analysis. Local Malware Analysis (historically known as Spero) is an engine that performs heuristic analysis on Portable Executable (PE) files, which includes .exe files. If a file policy is configured to enable only Local Malware Analysis but not AMP cloud lookups, the system will analyze .exe files locally. However, other file types like PDFs or documents cannot be analyzed by this engine and, without a cloud lookup to determine their reputation, will be assigned an "unknown" disposition.

A. The malware license has not been applied to the Cisco FTD. A missing malware (AMP) license would disable all file inspection and malware analysis features, meaning no files, including .exe, would be analyzed.
B. The Cisco FMC cannot reach the Internet to analyze files. Lack of internet connectivity would prevent AMP cloud lookups for all file types. This would result in all new, unseen files (including .exe) having an "unknown" disposition.
C. A file policy has not been applied to the access policy. If no file policy is applied to the matching access control rule, the system will not perform any file inspection, and therefore no file events or dispositions would be generated for any file type.

1. Cisco Firepower Management Center Configuration Guide

Version 7.0

Chapter: File Policies and Advanced Malware Protection

Section: Actions in File Rules.

Reference for Correct Answer (D): This section details the "Local Malware Analysis" action

stating

"Local malware analysis allows the system to inspect PE (Portable Executable) files for malware in an attempt to determine a file's disposition." This confirms the engine is specific to PE files like .exe. The guide also presents cloud lookups and dynamic analysis as separate

configurable options

supporting the scenario where only local analysis is enabled.

Reference for Incorrect Answer (C): The introduction to the "File Policies and Advanced Malware Protection" chapter states

"To perform any kind of file control or malware detection

you must associate a file policy with one or more access control rules." This confirms that without an applied policy

no file events would be generated

making option C incorrect.

2. Cisco Press

CCNP Security Identity

Management

and Automation SISE 300-715 and Securing Networks with Cisco Firepower SNCF 300-710 Official Cert Guide

1st Edition

Chapter 10: Advanced Malware Protection (AMP).

Reference for Correct Answer (D): The section on "File Disposition" explains

"The Firepower system can perform a local analysis of certain files to determine the likelihood that a file is malware. This feature is called local malware analysis (formerly Spero analysis). This feature applies only to PE files." This directly links the specific analysis type to .exe files

explaining the behavior noted in the question.

The requirement for the Cisco Firepower device to act as a "bump in the wire" explicitly calls for a transparent, Layer 2 deployment. In this mode, the device is inserted into a network segment without being a routed hop, meaning no IP addressing or default gateway changes are needed on adjacent devices. To achieve this, interfaces are configured into a bridge group, which allows the device to pass traffic between the interfaces at Layer 2 while still inspecting it for threats. This configuration fulfills the requirement to analyze traffic transparently.

A. Specify the BVl IP address as the default gateway for connected devices. A Bridge Virtual Interface (BVI) is used for management in transparent mode, not for routing user traffic. Making it a default gateway implies Layer 3 functionality, which contradicts the "bump in the wire" model.
B. Enable routing on the Cisco Firepower. Enabling routing places the device in Routed Mode (Layer 3), where it acts as a router hop. This is the opposite of a transparent, "bump in the wire" deployment.
C. Add an IP address to the physical Cisco Firepower interfaces. Assigning IP addresses to physical data interfaces is characteristic of Routed Mode. In Transparent Mode, only the management BVI has an IP address; the bridged physical interfaces do not.

1. Cisco Secure Firewall Management Center Device Configuration Guide

Version 7.2

Chapter: "Transparent or Routed Firewall Mode for Secure Firewall Threat Defense".

Section: "Transparent Firewall Mode"

Quote: "When you configure a transparent firewall

you are placing a Layer 2 firewall in the path of network traffic... Because the firewall is not a routed hop

you can easily introduce a transparent firewall into an existing network."

Quote: "You must configure a bridge group for a transparent firewall. A bridge group is a group of interfaces that the security appliance bridges."

2. Cisco Firepower Threat Defense Configuration Guide for Firepower Device Manager

Version 6.4

Chapter: "Interfaces".

Section: "Transparent Mode"

Quote: "In transparent mode

the Firepower Threat Defense device acts as a 'bump in the wire

' or a 'stealth firewall

' and is not seen as a router hop to connected devices. You must group the inside and outside interfaces together in a bridge group."

In a Cisco Firepower Management Center (FMC) multidomain deployment, objects created in an ancestor (parent) domain are inherited by descendant (child) domains. These inherited objects, including report templates, are read-only in the descendant domains to maintain hierarchical consistency. To edit an inherited report template, an administrator must first copy the template to the current descendant domain. This action creates a new, independent object owned by the current domain, which can then be modified without affecting the original template in the ancestor domain.

A. Adding it as a separate widget is for displaying report data on a dashboard, not for editing the structure of the report template itself.
C. Ownership is determined by the domain in which an object is created. An engineer in a descendant domain cannot take ownership of an object from an ancestor domain.
D. Changing "document attributes" is a vague action. The specific, required procedure to make an inherited, read-only template editable is to copy it to the local domain.

1. Cisco Secure Firewall Management Center Configuration Guide

7.2

Chapter: Reporting

Section: Report Templates

Subsection: Managing Report Templates.

The documentation states: "If you are in a descendant domain

you can copy a report template from an ancestor domain to the current domain. You can then edit the copy." This directly supports the correct answer.

2. Cisco Secure Firewall Management Center Configuration Guide

7.2

Chapter: Multidomain Deployments

Section: Domain Inheritance.

This section explains the core concept: "Objects you create in the current domain are available for use in the current domain and in any descendant domains... In a descendant domain

you cannot edit or delete objects inherited from an ancestor domain." This clarifies why direct editing is not possible and a different action is required.

In a switched (or transparent) deployment, the Firepower device operates at Layer 2, acting as a "bump in the wire." This mode is used to seamlessly integrate the firewall into an existing network segment. Network redundancy in such a Layer 2 topology is established using Spanning Tree Protocol (STP). STP prevents switching loops, which can occur when multiple paths exist between switches, by logically blocking redundant paths. The Firepower device, by default, forwards STP Bridge Protocol Data Units (BPDUs), allowing the surrounding switches to build a loop-free, redundant topology.

HSRP: This is a Cisco-proprietary Layer 3 protocol used to provide default gateway redundancy, which is not the function of a firewall in a switched/transparent deployment. GLBP: This is a Cisco-proprietary Layer 3 protocol for gateway redundancy and load balancing, which is irrelevant for a Layer 2 firewall implementation. VRRP: This is an IETF standard Layer 3 protocol for first-hop gateway redundancy, which does not apply to a device operating at Layer 2.

1. Cisco Secure Firewall Management Center Device Configuration Guide

7.2

Section: Transparent or Routed Firewall Mode for Firepower Threat Defense > How Transparent Firewall Mode Works

Content: This section explains that in transparent mode

the device acts as a Layer 2 firewall

connecting the same network on its interfaces. This establishes the Layer 2 context where STP operates.

2. Cisco Secure Firewall Management Center Device Configuration Guide

7.2

Section: Transparent or Routed Firewall Mode for Firepower Threat Defense > Guidelines and Limitations for Transparent Firewall Mode > Spanning Tree Protocol

Content: "The FTD in transparent mode forwards Spanning Tree Protocol (STP) BPDUs through the device by default. This allows STP to detect and prevent loops in your network. If you do not want to allow STP to pass through

you can create an access rule to deny BPDUs (destination MAC address 0180.c200.0000)." This directly confirms that STP is the expected protocol for managing the redundant switched topology where the Firepower device is deployed.

Cisco Rapid Threat Containment (RTC) is a framework that integrates various Cisco security products to automate threat response. When a threat is detected by a sensor like Cisco Firepower, it shares this context with the Cisco Identity Services Engine (ISE) via the Platform Exchange Grid (pxGrid). ISE then acts as the policy enforcement point. A primary method of containment is to dynamically change the Security Group Tag (SGT) of the compromised endpoint. This action leverages Cisco TrustSec to apply a more restrictive policy (quarantine or limited access), effectively segmenting the endpoint from the rest of the network and containing the threat.

A. change of authentication: This is imprecise. RTC triggers a change in authorization status (e.g., assigning a quarantine SGT), not necessarily a new authentication event itself.
B. share context data: Sharing context data via pxGrid is the mechanism that enables containment but is not the containment action itself. It is a prerequisite step.
C. TACACS+: TACACS+ is a protocol primarily used for device administration (AAA for network devices like routers and switches), not for endpoint access control or threat containment.

1. Cisco Identity Services Engine Administrator Guide, Release 3.1, "Rapid Threat Containment" Chapter: "Cisco ISE can change the authorization state of an endpoint when it receives a high-level threat alert from the monitoring device... Cisco ISE uses the following methods to contain threats: Quarantine: Assigns the endpoint to a Security Group Tag (SGT) or VLAN that has a very restrictive access."

2. Cisco Press, "31 Days Before Your CCNP and CCIE Security Core SCOR 350-701 Exam," Day 28: Cisco ISE Posture and Quarantine: "When a threat is detected, the sensor can publish information about the threat through pxGrid. ISE can subscribe to this information and take an action, such as quarantining the endpoint by assigning it a different SGT or VLAN." (Note: While this is from a SCOR book, the technology is identical and directly applicable to the 300-710 exam domain).

3. Cisco.com, "Cisco TrustSec," Solution Overview: "Cisco TrustSec technology uses software-defined segmentation to simplify the provisioning of network access, accelerate security operations, and consistently enforce policy across the network... When integrated with Cisco ISE, it can dynamically quarantine suspicious devices." This document explains the foundational technology (TrustSec) that RTC leverages for containment.

Thresholding settings in Cisco Firepower are used to control the rate at which events are generated, preventing event floods from noisy rules or detecting rate-based attacks. These settings can be configured in two distinct locations:
1. On each IPS rule: Within an intrusion policy, you can configure a threshold for a specific Snort rule. This limits the number of events logged for that rule over a specific time period, which is useful for tuning rules that may generate excessive false positives.
2. Per preprocessor, within the network analysis policy: The Network Analysis Policy (NAP) contains settings for rate-based attack prevention. This feature, managed by preprocessors, acts as a thresholding mechanism to detect and block anomalous traffic patterns, such as a host initiating too many connections, which could indicate a scan or a worm.

B. Thresholding is not a single global setting within the network analysis policy; it is configured on specific preprocessors within that policy.
C. Thresholding is a granular setting applied to individual rules within an intrusion policy, not as a single global setting for the entire policy.
D. Access control rules determine traffic handling (allow, block, inspect), while thresholding is a parameter of the intrusion inspection process itself.

1. Cisco Secure Firewall Management Center Snort 3 Configuration Guide

7.2

"Intrusion Rules" chapter

"Thresholding Intrusion Events" section.

This section states

"You can set a threshold on an intrusion rule to control the number of events that the rule generates in a specified time interval. For example

you can configure a rule to generate only one event when a specific type of attack is detected 100 times in one minute." This directly supports option A.

2. Cisco Secure Firewall Management Center Snort 3 Configuration Guide

7.2

"Network Analysis Policies" chapter

"Rate-Based Attack Prevention" section.

This section explains

"Rate-based attack prevention is a network analysis policy (NAP) feature that allows you to configure the system to take action on traffic that exceeds a defined rate." It further details that this is configured for specific preprocessors (Host

Responder

All). This directly supports option E.

3. Cisco Firepower Management Center Configuration Guide

Version 6.4

"Intrusion Policy Settings" chapter

"Rule Thresholding" section.

This document states

"You can set a threshold on an intrusion rule to control the number of events that the rule generates in a specified time interval." This provides further evidence for option A.

4. Cisco Firepower Management Center Configuration Guide

Version 6.4

"Network Analysis and Intrusion Policies" chapter

"Configuring Rate-Based Attack Prevention" section.

This guide states

"You can configure the system to apply rate-based prevention

which allows you to configure the system to take action on traffic that exceeds a defined rate... You configure rate-based attack prevention as part of a network analysis policy." This confirms that a form of thresholding is configured within the NAP

specifically on its preprocessor components

supporting option E.

Quality of Service (QoS) on Cisco Firepower Threat Defense (FTD) is a feature that is exclusively supported on routed interfaces (Layer 3). When an FTD device is deployed in transparent mode, it functions as a Layer 2 firewall, and its interfaces are not capable of performing the routing functions necessary for QoS policy enforcement. Consequently, when an administrator attempts to apply a QoS policy to destination interfaces on a transparent-mode FTD, no interfaces will appear as available for selection because none meet the prerequisite of being a routed interface.

A. Resource exhaustion would typically manifest as a deployment failure or system performance degradation, not as a complete absence of interfaces in the configuration UI.
B. The IP addressing scheme (contiguous or not) of network segments is irrelevant to an interface's eligibility for a QoS policy.
D. The term "conflict" is too vague; the issue is a fundamental feature incompatibility with the device's operational mode, not a conflict between specific interface types.

1. Cisco Firepower Management Center Configuration Guide, Version 7.0, "Quality of Service" Chapter, "Guidelines and Limitations for QoS" section: "QoS is supported only on routed interfaces. It is not supported on transparent or inline interfaces, nor on passive or ERSPAN interfaces." This statement directly confirms that transparent mode interfaces are ineligible for QoS.

2. Cisco Firepower Threat Defense (FTD) Configuration Guide for Firepower Device Manager, Version 7.2, "Quality of Service" Chapter, "Prerequisites for QoS" section: This guide reiterates the requirement for routed interfaces, stating, "You can apply QoS policies only to the egress traffic on routed interfaces." This explains why no interfaces would be available on a device operating in transparent mode.

In a Cisco Firepower Management Center (FMC) multidomain environment, dashboards are treated as domain-specific configurations. This means a dashboard created in an ancestor domain is completely isolated and not inherited by any descendant (child) domains. Consequently, users in a child domain cannot see, access, or use dashboards that were created in a parent domain. Each domain must have its own dashboards created and managed locally within that domain, ensuring a strict separation of operational views and data for multitenancy purposes.

A. Child domains cannot view dashboards from an ancestor domain at all, so the concept of viewing but not editing is inapplicable.
B. The limitation is not on a subset of widgets but on the entire dashboard's visibility; dashboards are not inherited.
C. Administrators of any domain can view dashboards, but only those created within their own specific domain, not just the top ancestor.

1. Cisco Firepower Management Center Configuration Guide

Version 7.2

Chapter: Multidomain Deployments

Section: Domain-Specific Configurations.

The documentation explicitly states: "The following configurations are specific to the current domain and are not inherited by descendant domains: ... Dashboards and dashboard widgets..." This confirms that dashboards are not shared from ancestor to child domains.

2. Cisco Firepower Management Center Configuration Guide

Version 6.7

Chapter: Multidomain Deployments

Section: Domain-Specific Configurations.

This earlier version of the guide provides the same information

listing "Dashboards and dashboard widgets" as configurations that are not inherited by descendant domains

reinforcing this as a fundamental design principle of FMC multidomain architecture.