300-720 Practice Questions

The most direct method to view the complete contents of the local safelist and blocklist on a Cisco Email Security Appliance (ESA) is by exporting the list. Within the ESA's web interface, under Mail Policies > Safelist/Blocklist, administrators can use the "Export" function. This action generates a comma-separated value (.csv) file containing all the sender entries currently in the list. This provides a complete, static, and easily reviewable copy of the SLBL database for auditing, backup, or analysis, directly fulfilling the requirement to "view" the list.

A: The slblstatus CLI command shows the operational status and cache summary (e.g., number of entries, server connectivity) of the SLBL service, not the actual list of senders.

B: Monitoring listeners provides real-time data on mail connections and flow, showing the effect of the SLBL, but it does not display the configured list of senders.

D: Debugging mail flow policies, such as using the trace command, shows how rules are applied to a specific message, not the entire contents of the safelist/blocklist.

1. Cisco Email Security Appliance Configuration Guide

14.0: In the chapter "Managing Sender and Recipient Domains

" the section on "Managing the Safelist and Blocklist (SLBL)" describes the user interface. It explicitly mentions the functionality to "Import List..." and "Export List..." from the Safelist/Blocklist page (Mail Policies > Safelist/Blocklist). Exporting is the direct action to obtain a viewable file of the list's contents.

2. Cisco AsyncOS 14.0 for Email Security CLI Reference Guide: The description for the slblstatus command states it is used to "Check the status of the Sender/IP Reputation Service." The output shown in the guide includes connection status

cache size

and update times

confirming it does not display the list entries.

3. Cisco Email Security Appliance Configuration Guide

13.0: The chapter "Controlling Sender and Recipient Domains

" section "Safelist/Blocklist Overview

" details that the lists are managed on the Mail Policies > Safelist/Blocklist page

where the export function resides. This function is the primary mechanism for extracting the list for external viewing.

The "Spam Quarantine End-User Authentication Query" is the specific LDAP query type configured on the Cisco Email Security Appliance (ESA) to validate an end-user's credentials (username and password) during the login process to the End-User Quarantine. When external authentication for the Spam Quarantine is enabled via LDAP, this query is defined to check the submitted credentials against the LDAP directory server, granting or denying access accordingly. This is the direct mechanism for the action described in the question.

A. Enabling the End-User Safelist/Blocklist feature: This is a feature that allows authenticated users to manage their own lists; it is not the mechanism that performs the initial login authentication.

B. Spam Quarantine External Authentication Query: This is a general term. The "End-User Authentication Query" is the specific type of external authentication query used for this precise purpose, making option C more accurate.

D. Spam Quarantine Alias Consolidation Query: This query is used after successful authentication to group messages from a user's various email aliases into a single quarantine view, not for validating login credentials.

1. Cisco Secure Email and Web Manager 14.2 Configuration Guide

Chapter: Centralizing Services on a Security Management Appliance

Section: Configuring the Spam Quarantine to Authenticate End Users Against an LDAP Server.

This section explicitly states

"End-User Authentication Query: This query validates the end-user’s credentials when they log in to the Spam Quarantine." It also defines the Alias Consolidation Query separately

confirming its different purpose.

2. Cisco AsyncOS 14.0 for Email Security User Guide

Chapter: Using the Spam Quarantine

Section: Accessing the Spam Quarantine.

This guide describes the end-user login process

which relies on the authentication method configured by the administrator. The configuration of this method is detailed in the corresponding Configuration Guide

which specifies the "End-User Authentication Query" for LDAP.

The configuration shows that for files pending analysis by the sandbox (potential zero-day malware), the action is "Deliver As Is." This means the email and its attachment are delivered to the recipient before the analysis is complete. To stop the delivery of potential zero-day attacks, the "File Analysis Pending" action must be changed to "Quarantine." This holds the message until the file analysis service returns a verdict, preventing the user from accessing a potentially malicious file. This is the most direct and proactive method to prevent the initial delivery of such threats.

A. Change Unscannable Action from Deliver As Is to Quarantine.

This applies to files the engine cannot scan (e.g., corrupted, encrypted), not specifically to unknown files sent for zero-day analysis.

C. Configure mailbox auto-remediation.

This is a reactive, post-delivery feature that removes a threat from an inbox after it has been delivered and later identified as malicious. It does not stop the initial delivery.

D. Apply Prepend on Modify Message Subject under Malware Attachments.

This action applies to attachments already confirmed as malware by reputation or signature scanning, not to unknown files pending analysis for zero-day threats.

1. Cisco Email Security Appliance End-User Guides

"Protecting Against Viruses and Malware Using Advanced Malware Protection" chapter. The documentation details the mail policy settings for Advanced Malware Protection (AMP). It specifies that the "File Analysis Pending" setting determines the action for messages with attachments sent for analysis. The default action is to deliver the message

but it can be changed to Quarantine to hold the message until a verdict is available. (Reference: User Guide for Cisco Email Security Appliance

AsyncOS 14.0

Chapter: Protecting Against Viruses and Malware Using Advanced Malware Protection

Section: File Handling in Mail Policies).

2. Cisco Email Security Appliance End-User Guides

"Mailbox Auto-Remediation" section. This documentation describes Mailbox Auto-Remediation (MAR) as a feature that acts on messages after they have been delivered to user mailboxes

based on retrospective verdicts from Threat Grid. This confirms it is a post-delivery action. (Reference: User Guide for Cisco Email Security Appliance

AsyncOS 14.0

Chapter: System Administration

Section: Configuring Mailbox Auto-Remediation).

3. Cisco Content Security Management Appliance Configuration Guides

"Configuring Mail Policies to Enforce Email Security" chapter. This guide explains the various verdicts within mail policies. It differentiates between "Malware" (known threats)

"Unscannable" (files that cannot be processed)

and files sent for "File Analysis" (unknown threats)

clarifying that each setting targets a different scenario. (Reference: Configuration Guide for Cisco Content Security Management Appliance

AsyncOS 13.5

Chapter: Centralized Management

Section: Configuring Mail Policies to Enforce Email Security).

According to official Cisco documentation, when a new Cisco Secure Email Virtual Gateway is deployed on a network segment without a DHCP server, it automatically assigns a default static IP address to its Management interface. This default address is 192.168.42.42. An administrator can then connect a computer to the same network, configure a static IP on the same subnet (e.g., 192.168.42.43), and access the gateway's web interface or SSH at 192.168.42.42 to perform the initial configuration. This behavior provides a reliable fallback mechanism for initial access.

A: This is incorrect because a virtual appliance does not have a physical serial port; it uses a virtual console provided by the hypervisor.

B: This is incorrect as the question explicitly states that a DHCP server is not available, making this option a contradiction to the scenario's premise.

D: While manual configuration via the hypervisor console is possible using the systemsetup command, it is not the default method. The default behavior is the automatic assignment of the fallback IP.

1. Cisco Content Security Virtual Appliance Installation Guide

Release 14.2.

Section: Initial Configuration of the Virtual Appliance > How the Virtual Appliance Obtains an IP Address

Quote: "If a DHCP server is not available on the network

the virtual appliance assigns a default IP address of 192.168.42.42 to the Management interface." This document explicitly states the default fallback IP address used for initial access when DHCP fails.

Reference: Cisco Content Security Virtual Appliance Installation Guide

2. Cisco Secure Email Gateway Installation Guide

Release 15.0.

Section: Initial Configuration > How the Appliance Obtains an IP Address

Quote: "If a DHCP server is not available on the network

the appliance assigns a default IP address of 192.168.42.42 to the Management interface." This confirms the same default behavior in a more recent version

reinforcing it as a standard procedure.

Reference: Cisco Secure Email Gateway Installation Guide

The Cisco Secure Email Encryption Service (CRES) large file attachment feature has specific operational requirements and delivery mechanisms. First, for the feature to be enabled on an encryption profile, the "Read from Message" feature must also be enabled as a prerequisite. This allows the system to correctly process the message for large file handling. Second, the delivery method for any CRES-encrypted email, including those with large attachments, involves sending the recipient a notification email containing a securedoc.html attachment. This HTML file is the secure gateway through which the recipient authenticates and accesses the encrypted message body and the links to download the large files from the CRES portal.

A. Large file attachments can only be sent using the websafe portal: This is incorrect. The Cisco Secure Email Add-In for Outlook is a primary tool for users to send large encrypted files directly from their email client.

B. This feature allows users to send up to 50MB of attachments in a secure email: This is incorrect. The feature supports significantly larger files, with a maximum size of up to 2 GB per attachment.

D. Large file attachments can only be sent using the Cisco Secure Email Add-In: This is incorrect. While the Add-In is a common method, users can also compose and send secure messages with attachments directly from the CRES websafe portal.

1. Cisco Secure Email and Web Manager 15.0 User Guide: In the chapter "Using Email Encryption

" the section "Configuring Encryption Profiles to Use the Cisco Secure Email Encryption Service" explicitly states the prerequisite for enabling large file attachments: "To enable this feature

you must also enable the Read from Message feature." This directly supports option E.

2. Cisco Secure Email and Web Manager 15.0 User Guide: The same section details the size limit: "The maximum size of a large file attachment is 2 GB." This proves option B is incorrect.

3. Cisco Secure Email Encryption Service End-User Guide: This guide describes the recipient's experience

stating

"To open the secure message

open the attachment (securedoc.html) and follow the instructions on the screen." This confirms that the securedoc attachment is the standard mechanism for accessing any CRES-encrypted content

which supports option C.

4. Cisco Secure Email Plug-In 8.1 for Microsoft Outlook User Guide: This document details how users can "send a large encrypted attachment" directly from Outlook

which invalidates the exclusivity claims in options A and D.

After creating a DKIM signing profile on a Cisco Secure Email Gateway (SEG), the system generates a public/private key pair. The private key is used to sign outbound emails. The corresponding public key must be published in the public DNS of the sending domain. This allows receiving mail servers to retrieve the public key and verify the DKIM signature. Therefore, the immediate and necessary next step is to export the generated DNS TXT record containing the public key and provide it to the DNS administrator for publication.

A. Enable the DKIM service checker: The DKIM service checker is used for verifying DKIM signatures on inbound email, not for enabling outbound signing.

C. Import the DNS record of the service provider into the Cisco Secure Email Gateway: This action is incorrect; for outbound DKIM, you export/publish your own public key to your DNS, not import a record from a service provider.

D. Configure the Trusted Sender Group message authenticity policy: This policy is typically used for evaluating the authenticity of inbound mail from trusted senders, not for applying an outbound signing profile.

1. Cisco Secure Email and Web Manager User Guide

15.0

"Email Security Manager > Email Policies > DomainKeys Identified Mail (DKIM)" section.

The guide outlines the configuration workflow. After creating a signing profile and generating keys

the next step is: "Publish the public key for the signing key to the DNS server for the signing domain." It further states

"You can view the public key and the DNS record that you must create... Copy the text for the DNS record and provide it to your DNS administrator." This directly supports option B as the correct next step.

2. Cisco Secure Email Gateway Configuration Guides

"Configuring the Email Gateway to Sign Outgoing Messages Using DKIM" chapter.

The procedural steps confirm that after creating the signing key and profile (Step 2 and 3)

the administrator must perform Step 4: "Publish the Public Key to DNS." The guide explicitly details that the appliance provides the TXT record to be published

which must be given to the DNS provider. Applying the signing profile to an outgoing mail policy is the final step (Step 5)

which can only be effective after the public key is published.

The primary benefit of enabling the external spam quarantine on a Cisco Security Management Appliance (SMA) is to centralize and consolidate spam quarantine data from multiple Email Security Appliances (ESAs). In an environment with several ESAs, each appliance would otherwise maintain its own separate quarantine. The SMA provides a single, unified repository for all quarantined messages, which simplifies administration and provides a single point of access for end-users to manage their messages, regardless of which ESA initially processed the email.

A: "Backup" is an inaccurate term. The SMA provides a live, active, and consolidated quarantine for ongoing management, not a passive copy for disaster recovery. "Consolidate" is the more precise term.

B: This describes the general functionality of a spam quarantine interface, which is available on a local ESA quarantine as well. It is not a specific benefit of using the external SMA quarantine.

C: The use of dual anti-spam scanning engines is a feature of the Cisco Email Security Appliance (ESA) itself to improve catch rates, not a function or benefit of the SMA's quarantine feature.

1. Cisco Content Security Management Appliance AsyncOS 14.0 User Guide: In the chapter "Centralizing Services on the Security Management Appliance

" the section "Centralized Spam Quarantine" explicitly states

"You can configure your Email Security appliances to use a Spam Quarantine on a Security Management appliance. This allows you to consolidate the quarantines from multiple appliances to a single

centralized location." This directly supports the correct answer (D) and the concept of consolidation over backup (A).

2. Cisco Content Security Management Appliance AsyncOS 14.0 User Guide: The same section

"Centralized Spam Quarantine

" further explains the benefit: "Centralizing the Spam Quarantine provides a single location for end-users to check their quarantined messages." This highlights that the core benefit is centralization

not the basic UI functions described in option (B).

3. Cisco Email Security Appliance AsyncOS 14.0 User Guide: The chapter "Controlling Spam" details the anti-spam scanning engines (Cisco Anti-Spam and Cisco Intelligent Multi-Scan). This confirms that scanning (C) is an ESA function

separate from the SMA's role in centralizing the quarantine.

A custom quarantine is considered "in use" when it is configured as the action for one or more message or content filters. To maintain policy integrity, the system prevents the deletion of any quarantine that is actively referenced by a filter. Therefore, before the quarantine can be deleted, it must first be disassociated from all filters that use it. This is accomplished by editing the message action of each relevant filter and selecting a different action (such as another quarantine, deliver, or drop). Once the quarantine is no longer referenced by any filter, it is considered unused and can be deleted.

A: This describes the action you are trying to perform but cannot because the quarantine is still assigned to a filter.

B: This applies to a quarantine that is not in use, which contradicts the scenario presented in the question.

C: This also refers to deleting an unused quarantine, which is not the situation described in the question.

1. Cisco Email Security Appliance AsyncOS 14.0 User Guide

Chapter: "Centralized Policy

Virus

and Outbreak Quarantines"

Section: "Managing Quarantines".

The guide states

"You cannot delete a quarantine if it is being used by a message or content filter. You must first remove the quarantine from the message action of the filter." This directly validates that removing the quarantine from the filter's action is the required prerequisite.

2. Cisco Content Security Management Appliance AsyncOS 14.0 User Guide

Chapter: "Centralized Policy

Virus

and Outbreak Quarantines"

Section: "Managing Quarantines on the Management Appliance".

This document reiterates the same principle for centrally managed quarantines: "You cannot delete a quarantine if it is being used by a message or content filter. You must first remove the quarantine from the message action of the filter."

To provide differentiated email filtering for a specific group like executives, an administrator must perform two primary actions on a Cisco Email Security Appliance (ESA). First, the target group ("executives") must be identified and defined. Using an LDAP group query (A) is a standard, dynamic, and scalable method to create a recipient group based on an existing directory structure (e.g., Active Directory). Second, the specific filtering rules and corresponding actions (e.g., quarantine, drop, notify) must be created. This is accomplished by creating content filters (B) that inspect message attributes. These two components—the user group and the content filter—are then applied to a dedicated mail policy.

C: While uploading a CSV file is a valid method to create a user list, an LDAP query is a more robust and dynamic enterprise solution for managing group membership.

D: Enabling content-scanning features is a global, prerequisite system configuration. It is not a direct step in creating a specific, differentiated mail policy for a particular user group.

E: Defining default mail policies creates a baseline for all users. The task requires creating a specific, non-default policy that applies only to the executive group, which typically precedes the default policy.

1. Cisco Secure Email and Web Manager 15.0 Configuration Guide:

For Answer A: In the chapter "System Administration

" the section "LDAP" describes how to configure LDAP profiles and queries. Specifically

the subsection "Using LDAP Group Queries to Populate Recipient Groups" details how to create recipient groups based on LDAP directory group queries

which is the action described in option A.

For Answer B: In the chapter "Mail Policies

" the section "Content Filters" explains their function: "Content filters are rules you can create to take action on messages based on their contents...". This directly supports creating specific rules as described in option B.

General Workflow: The chapter "Mail Policies

" section "Configuring Mail Policies

" outlines the process of creating a new mail policy and associating it with specific user groups (defined via LDAP or other means) and content filters. This confirms that actions A and B are the core steps.

On a Cisco Email Security Appliance (ESA), Virtual Gateways are configured to manage and separate outgoing email traffic, which is crucial for sender reputation management. Each Virtual Gateway is fundamentally defined by two key attributes: a unique IP address assigned to one of the appliance's network interfaces, and an association with one or more sender domains. The ESA's Mail Flow Policies use the sender's domain to determine which Virtual Gateway (and therefore which IP address) should be used to send a particular message. This allows an organization to use different IP addresses for different types of mail (e.g., transactional vs. marketing).

C. DNS server address: DNS server settings are configured globally for the entire appliance, not on a per-virtual gateway basis.

D. DHCP server address: The appliance acts as a DHCP client to obtain an IP address; it does not have a "DHCP server address" as a configurable attribute for a gateway.

E. external spam quarantine: A spam quarantine is a policy destination for unwanted mail, not a core network attribute of a virtual gateway's identity.

1. Cisco Content Security Management Appliance Configuration Guide

14.0: In the section "Email > Outgoing Mail

" the concept of Virtual Gateways is explained. The configuration involves creating a gateway and associating it with an IP interface. The guide states

"Virtual Gateways allow you to assign a dedicated IP address...to a group of senders. You can group senders by domain..." This directly links the IP address and domain as the core attributes. (Reference: "Configuring Centralized Outgoing Mail Policies" chapter).

2. AsyncOS 15.0 for Cisco Email Security Appliances - User Guide: The chapter "Configuring the Email Pipeline

" under the section "Managing Mail Delivery

" details the setup of Virtual Gateways. The process explicitly requires selecting an IP interface for the gateway and then using Mail Flow Policies to route mail from specific sender groups (often defined by domain) through that gateway. This confirms that the IP address and the domain association are the defining characteristics. (Reference: Chapter "Configuring the Email Pipeline

" Section "Virtual Gateways").

3. Cisco Email Security Appliance (ESA) Best Practices

Tips

and Tricks: This document emphasizes the primary use case for Virtual Gateways: "The main reason for using Virtual Gateways is for IP reputation." It details how to create a new IP interface and then a Virtual Gateway that uses that IP

and subsequently create a Mail Flow Policy that matches on a sender domain to use the new Virtual Gateway. (Reference: Section "Virtual Gateways").