PCSAE Security Automation Engineer Practice Questions
Prepare for PCSAE with more than an answer.
- Exam fee
- $175 USD
- Level
- Specialist
- Valid for
- 2 years
Domains covered on the exam 6
- Playbook Development27%
- Incident Objects13%
- Automations, Integrations, and Related Concepts18%
- Content Management and Solution Architecture17%
- UI Workflow, Dashboards, and Reports13%
- Threat Intel Management12%
- 1
What is the primary function of the 'auto-extract' feature in Cortex XSOAR's Threat Intel Management?
Show answer details
Correct answer: B
The core purpose of the 'auto-extract' feature is to scan unstructured text from incident fields (like email bodies) and attachments upon incident creation. It uses a system of regular expressions to identify patterns that match known indicator types (IPs, URLs, Hashes, etc.) and automatically extracts them, creating indicator objects linked to the incident. This automates a crucial first step in threat analysis.
- 2
A hospital is using Cortex XSOAR to manage incidents related to medical devices. They have a custom incident field named 'Device ID'. The security team wants to create a button on the incident layout that, when clicked, queries an external asset management database for the device's location and owner, and populates other incident fields with this information. Which XSOAR component is executed when an analyst clicks a custom button on an incident layout?
Show answer details
Correct answer: C
Custom buttons on incident layouts are configured to run a specific Automation Script. The script receives the current incident details as arguments, performs the required actions (like querying the external database using an integration command), and can then use built-in functions like
demisto.executeCommand('setIncident', ...)to update the incident fields with the retrieved information. This provides a way to trigger on-demand automation directly from the UI. - 3
An organization is using the XSOAR Threat Intel Management module and has configured a feed integration that pulls down a large number of indicators. They notice that after 90 days, many of these indicators are automatically deleted. What parameter controls this behavior?
Show answer details
Correct answer: B
The lifecycle of an indicator, including its automatic deletion, is governed by the 'Indicator Expiration Method' setting found in the configuration for each specific Indicator Type. This can be set to 'Never', 'By Interval', or 'By Timestamp'. If set to 'By Interval' (the likely scenario here), another field defines the duration (e.g., 90 days), after which the system's expiration job will mark the indicator as expired and eventually delete it.
- 4
Case Study:
A large e-commerce company, 'ShopSecure', has recently deployed Cortex XSOAR to automate their incident response processes. They have a multi-tiered SOC, with Tier 1 analysts performing initial triage and Tier 2 analysts conducting in-depth investigation and remediation. The company has a strict dev-prod lifecycle for all XSOAR content, using a central Git repository for version control.
The lead SOAR architect has been tasked with creating a robust solution for handling 'Credential Stuffing' alerts from their identity provider. The alert contains the targeted application, the source IP address, and a list of attempted usernames. The required workflow is as follows: 1) Enrich the source IP using three different threat intelligence tools. 2) If at least two tools mark the IP as malicious, automatically block it on the firewall. 3) For each attempted username, query the Active Directory to check if the account is valid. 4) Create a summary report of valid vs. invalid accounts attempted and add it as a note to the incident.
To ensure maintainability and reusability, the architect wants to break the logic into smaller components. Specifically, the IP enrichment and the Active Directory user checks should be reusable in other playbooks. All content must follow the dev-prod push/pull model for deployment.
Given this scenario, what is the most appropriate design for the 'Credential Stuffing' playbook?
Show answer details
Correct answer: C
This design is the most modular, reusable, and maintainable, aligning perfectly with XSOAR best practices. Creating separate sub-playbooks for IP enrichment and AD user validation makes those logical units reusable across any other scenario. The parent playbook acts as an orchestrator. Using a looped sub-playbook for the usernames is the correct way to process an array of inputs. This modular approach also fits perfectly with the dev-prod lifecycle, as each component (parent playbook, sub-playbooks) can be versioned and migrated independently.
- 5
What is the primary role of an XSOAR Engine in a distributed architecture?
graph TD subgraph Corporate Network XSOAR_Server[Cortex XSOAR Server] end subgraph DMZ Engine[XSOAR Engine] EDR_Console[EDR Management Console] end subgraph Internet Cloud_Service[Cloud API] end XSOAR_Server -- D2 Protocol --> Engine Engine -- API Call --> EDR_Console XSOAR_Server -- HTTPS --> Cloud_ServiceShow answer details
Correct answer: B
The primary role of an XSOAR Engine is to act as a secure proxy. It is deployed in network segments that the main XSOAR server cannot or should not reach directly (like a DMZ or a separate cloud VPC). The engine executes integration commands locally in its segment and communicates back to the main server over a secure, tunneled connection, enabling automation across network boundaries.
- 6
A Cortex XSOAR engineer is developing a playbook to process suspicious emails. A critical step involves parsing a proprietary, encrypted log file format attached to the emails. The standard 'Extract Indicators' automation fails on this format. The decryption key is available via a secure vault integration. Which approach provides the most efficient and scalable solution for handling this proprietary attachment within the playbook?
Show answer details
Correct answer: B
The most efficient and scalable solution is to encapsulate the entire custom logic within a single, reusable automation script. This script can handle fetching the key, decrypting the file, parsing the specific format, and outputting structured data to the context. This approach is superior because it is modular, easily versioned, testable, and can be reused across multiple playbooks. Manual intervention is inefficient. A pre-processing script is for ingestion, not in-playbook file handling. Developing a full integration is overly complex for a single file format.
- 7
A security architect is designing a multi-tenant Cortex XSOAR environment with a master account and several child tenants. A requirement is to push a core set of 'blessed' playbooks from the master to all tenants, but tenants must be prevented from modifying these blessed playbooks. However, tenants should be able to duplicate them to create their own custom versions. How can this be achieved using the remote repository (dev-prod) functionality?
Show answer details
Correct answer: A
This is the correct approach. The remote repository syncs the content from the master (prod) to the tenants (dev). By default, this content is locked. To enforce the 'no modification' rule while allowing duplication, you must combine this with Role-Based Access Control (RBAC). Setting the permissions for the blessed playbooks to read-only for tenant roles prevents modification, but XSOAR's core functionality still allows users to duplicate any playbook they can view, thus meeting all requirements. Pushing content to a local branch or using content packs does not enforce the modification restriction.
- 8
A playbook developer is using a sub-playbook that enriches a list of IP addresses. The sub-playbook is configured with looping enabled to iterate over an array of IPs from the parent context. A critical requirement is that if any single IP enrichment fails within the sub-playbook, the entire loop should terminate immediately, and the parent playbook should proceed down an error-handling path. Which configuration ensures this behavior?
Show answer details
Correct answer: B
This combination of settings is designed for this exact scenario. First, the task inside the sub-playbook must be configured to actually fail (by unchecking 'Continue on error'), which causes the sub-playbook itself to enter a failed state. Second, the looping task in the parent playbook must be configured with 'Exit loop on sub-playbook failure'. This tells the parent to monitor the execution state of each sub-playbook iteration and terminate the entire loop immediately upon the first failure, allowing the parent playbook to move to the next task, which would typically be an error handling path.
- 9
A SOC team is ingesting threat intel from multiple external feeds. They have discovered that two different feeds often provide conflicting reputation scores for the same URL indicator (e.g., Feed A says 'Malicious', Feed B says 'Suspicious'). The team's policy is to always use the most severe reputation. How should an engineer configure the indicator type for URLs to automate this policy?
Show answer details
Correct answer: B
The 'Reputation Calc Script' is the specific XSOAR feature designed to resolve reputation conflicts from multiple sources. By assigning a custom script to this field within the indicator type configuration, an engineer can define the logic for calculating the final score. The script can access the reputation from all sources ('dbot_scores'), compare their severity, and return the most severe one as the final verdict for the indicator. This is the intended, automated method for handling such conflicts.
- 10
During a playbook debugging session for a complex incident involving multiple artifacts, an engineer needs to inspect the full context data at a specific point after a data transformation task has run, but before a conditional task evaluates it. The playbook is long and running it to completion is time-consuming. What is the most direct way to achieve this using the playbook debugger?
Show answer details
Correct answer: C
The playbook debugger is specifically designed for this purpose. By setting a breakpoint on the task immediately following the point of interest (the conditional task), the engineer can run the playbook in debug mode. Execution will automatically pause before the task with the breakpoint runs. At this paused state, the debugger's 'Context Data' tab provides a complete, searchable snapshot of the entire context, reflecting all changes from previously executed tasks, including the transformation.
