Cortex XSOAR And Automation practice questions

Layout

Why it fails: Layouts define the UI view of the data.

Transformer

Why it fails: Transformers modify data, they do not map structures.

Playbook

Why it fails: Playbooks automate processes, not structural data mapping.

Hard-code the value in the integration parameters

Why it fails: Integration parameters are global and cannot handle dynamic task-level nulls.

Delete the task from the playbook

Why it fails: Deleting the task removes the functionality entirely.

Change the integration instance timeout settings

Why it fails: Timeout settings address latency, not empty data fields.

Integration Instance Parameters

Why it fails: These parameters control connectivity to the source, not internal processing limits.

Playbook Task Timeout

Why it fails: This controls the runtime of a single task, not the volume of indicators.

Global System Settings

Why it fails: Global settings control system-wide behavior, not individual enrichment limits.

Incident Type Settings

Why it fails: This triggers playbooks for incidents, not indicators.

Playbook Inputs

Why it fails: Playbook inputs supply parameter values passed into a playbook at run time; they do not define the automation rule that fires it. This is tempting because inputs are configured on the playbook itself, but the trigger for a new indicator of a given type is set in the automation rule conditions.

Global Search

Why it fails: Global Search locates entities such as incidents and indicators; it holds no automation rule configuration, so it cannot trigger playbooks on indicator creation. It is tempting because indicators are found there, and it would be correct for locating an existing indicator rather than defining its automated response.

Incident fields

Why it fails: Fields are tied to specific incidents.

Workplan

Why it fails: A workplan is a playbook structure, not a data storage object.

Indicators

Why it fails: Indicators hold threat-intelligence artefacts such as IP addresses, domains and file hashes for matching during investigations, not arbitrary configuration values. They cannot store the key-value settings that a global variable or similar shared object provides across playbooks, so lookups would fail. Choose Indicators when you need to correlate observed activity against known malicious observables.

The script is not set to 'Public'

Why it fails: Script visibility controls who can view or run a script in the playbook designer; it does not affect whether the runtime resolves an integration dependency. The error concerns the integration reference itself, such as a mismatched instance name or missing configuration. Public visibility is tempting because sharing scripts across teams requires it, but that is unrelated to resolution.

The Python version is unsupported

Why it fails: An unsupported Python version would raise a syntax or interpreter error, not 'Integration not found'. Integration resolution depends on the integration instance name and its configuration, not the interpreter version. Python version is tempting because compatibility issues do break scripts, but the specific error points to the integration reference being unresolvable.

The playbook is not set to 'Active'

Why it fails: Playbook activation status controls whether the playbook triggers automatically on incidents; it has no bearing on integration resolution inside a running script. The error arises from the integration instance name or configuration being unresolvable. Active status is tempting because inactive playbooks do not execute, but the script is already running and failing.

Delete

Why it fails: Delete removes data.

Append

Why it fails: Append adds items, it does not extract them based on conditions.

Set

Why it fails: Set is for assigning values, not filtering lists.

Manually open each incident and assign the playbook

Why it fails: Opening each incident individually consumes analyst time proportional to incident count and introduces delay and inconsistency across a large backlog. It is tempting because manual assignment gives precise control for small volumes or exceptional cases, but bulk processing demands automated assignment rules or batch operations that apply the playbook at scale.

Restart the server

Why it fails: Restarting the server does not assign incidents to a playbook; it disrupts the Logic Apps runtime and any in-flight automation. It is tempting because restarting can clear stuck runs or refresh connections, and that would be the right action when a playbook execution hangs, not when bulk incidents need routing.

Wait for the user to trigger it

Why it fails: Waiting for user-triggered execution leaves incidents unprocessed and depends on unpredictable human action, which cannot scale to a large backlog. It is tempting because user-initiated runs suit ad-hoc, self-service scenarios, but bulk processing requires automated assignment rules or batch execution rather than passive waiting.

Rename the incidents

Why it fails: Renaming incidents changes only their titles, leaving ownership and playbook association untouched, so none of the incidents get processed. Renaming is genuinely useful for labelling or grouping incidents during triage, but it does not trigger or assign the playbook run.

System boot-up

Why it fails: Boot-up is a host lifecycle event, not an alert, incident or enrichment condition that a SOAR platform evaluates against playbook trigger criteria. It is tempting because endpoint agents do report boot events, but those feed asset inventory or compliance checks, not automated response workflows.

Setting a cron schedule

Why it fails: A cron schedule fires on elapsed time regardless of whether any security event occurred, so it cannot initiate event-driven response. It is tempting because scheduled jobs suit recurring hygiene tasks such as report generation, yet playbooks require a detection, alert or case trigger to act on an incident.

Browser refresh

Why it fails: A browser refresh is a client-side UI action with no security telemetry behind it, so no detection or case event reaches the orchestration engine. It is tempting because analysts do refresh dashboards, but playbooks trigger on alerts, incidents or webhooks, not on a user reloading a page.

Delete an incident

Why it fails: Conditions are for branching, not destructive actions.

Change the task owner

Why it fails: Task ownership is handled in the task settings, not the condition logic.

Playbook Trigger

Why it fails: Playbook triggers are for execution, not indicator extraction.

Integration command mapping

Why it fails: Command mapping dictates how output is parsed but is not the primary mechanism for indicator enrichment.

Incident Type mapping

Why it fails: Incident mapping defines the category, not the enrichment logic.

System Logs

Why it fails: System Logs capture platform-level events such as user actions, licence changes and service errors, not the per-task JSON payloads produced during playbook execution. They are the correct place to audit administrative activity or diagnose platform-wide faults.

Indicator dashboard

Why it fails: The indicator dashboard aggregates playbook and case metrics, not per-task execution payloads, so it cannot show the raw JSON of a single integration step. It is the right place for monitoring overall playbook health and success rates.

Integration Instance Logs

Why it fails: Integration Instance Logs record connectivity and configuration events for the integration instance itself, not the JSON output returned by a specific task within a playbook run. They are used when an integration fails to authenticate or reach its target service.

Playbook Versioning

Why it fails: Versioning tracks changes, not runtime collisions.

Role-Based Access Control

Why it fails: RBAC manages permissions, not internal logic execution.

DB Indexing

Why it fails: Indexing is for search performance, not concurrency control.

Global Incident field permissions

Why it fails: This controls field visibility, not integration interaction.

User Roles

Why it fails: User roles define analyst access, not automated process access.

Playbook permissions

Why it fails: Playbooks are triggered by incidents, but instance-level access is set in the integration configuration.

Generating a final management report

Why it fails: Reporting happens post-incident closure.

Modifying the XSOAR server configuration

Why it fails: System configuration is not part of incident ingestion.

Executing a manual investigation

Why it fails: Manual investigation occurs after incident creation.

Database trigger in PostgreSQL

Why it fails: Cortex XSOAR playbooks are triggered by integrations, incidents, indicators, or manual execution, not by database events. A PostgreSQL trigger would be the correct mechanism when application logic must fire automatically on row inserts or updates inside a database, which is unrelated to SOAR orchestration.

Indicator reputation change

Why it fails: Indicator reputation changes update threat intel records but do not themselves launch playbooks; triggers are events such as incident creation, alert ingestion, or manual and scheduled invocation. Reputation data feeds enrichment inside a playbook rather than initiating one.

Add a 'Conditional' task immediately after the command that checks whether the context path is populated, and loop back if it is not.

Why it fails: A conditional gate with a loop-back is a valid pattern for polling, but it is a manual, fragile workaround rather than the built-in mechanism the scenario asks for. It also risks infinite loops if the enrichment never populates, and it does not tell the engine to await the command's own return. The scenario specifically requires the engine to wait for the command output before advancing, which this construct does not directly provide.

Set the task's execution mode to 'Sync' and enable 'Wait for completion' on the integration instance settings.

Why it fails: There is no global 'Wait for completion' toggle on an integration instance, and 'Sync' is not a task execution mode the playbook engine exposes for command tasks. Integration instance settings govern connectivity, credentials, and proxy behavior, not per-task sequencing. This choice sounds operationally plausible but conflates instance-level configuration with task-level flow control, so it would not guarantee the downstream task sees completed enrichment output.

Convert the command task into a script task and call 'demisto.executeCommand' with a blocking flag set to true.

Why it fails: 'demisto.executeCommand' does not expose a blocking flag parameter that toggles synchronous behavior in that manner. Rewriting a simple command task as a custom script adds maintenance overhead, moves logic out of the visual workflow, and still does not guarantee the engine pauses before the next task. The scenario wants a configuration change, not a code rewrite, and this approach misstates the API surface.

Set the 'Incident Fetch Interval' to a high value to reduce the number of incidents fetched.

Why it fails: This is incorrect because the fetch interval controls how often the integration polls for new incidents, not which incidents are fetched. A high interval might reduce load but does not filter by severity or prevent duplicates. It could even cause missed incidents if the interval is too long.

Set the 'Incident Type' in the integration instance to a custom incident type that only includes high and critical severities.

Why it fails: This is incorrect because the incident type defines the schema and layout, not the filtering criteria. While you can create a custom incident type, it does not automatically filter incoming incidents by severity. Filtering must be done via query parameters or deduplication logic.

Configure a pre-processing rule to drop incidents with low severity.

Why it fails: This is incorrect because pre-processing rules are applied after incidents are fetched, not before. They can modify or drop incidents, but they do not prevent the initial fetch. For filtering during fetch, you need to use the fetch query. Pre-processing would still consume resources and may not prevent duplicates.

DBotScore.Reputation.Bad

Why it fails: DBotScore.Reputation.Bad is not a valid constant in Cortex XSOAR. The DBotScore reputation is typically set using integer constants defined in the CommonServerPython module, such as 0 for unknown, 1 for good, 2 for suspicious, and 3 for bad. Using a non-existent constant would cause errors in the integration.

DBotScore.Reputation.Suspicious

Why it fails: Suspicious reputation (typically value 2) is used when the indicator is potentially malicious but not confirmed. In this scenario, the API returns 'bad', which indicates a confirmed malicious IP. Mapping it to Suspicious would understate the threat and potentially lead to incorrect automated actions, such as not blocking the IP.

DBotScore.Reputation.Good

Why it fails: Good reputation (value 1) indicates a benign indicator. Mapping a 'bad' API response to Good would be a critical error, as it would mislead analysts and potentially allow malicious traffic. The API explicitly returns 'bad', so the correct mapping must reflect a malicious reputation.

Scripts must be written in Python 2.7 because Cortex XSOAR does not support Python 3.

Why it fails: Cortex XSOAR supports both Python 2.7 and Python 3.7+ for scripts. Python 3 is recommended for new development due to its ongoing support and features. Saying scripts must be Python 2.7 is incorrect and would limit functionality and security. The platform provides Docker images for both versions, so developers can choose.

The script can directly modify incident fields by assigning values to demisto.incidents()[0]['customFields'].

Why it fails: Directly modifying the incident object returned by demisto.incidents() does not persist changes to the incident. To update incident fields, you must use demisto.executeCommand('setIncident', {...}) or similar commands. The incident object is a read-only representation; in-memory changes are not saved unless explicitly committed through the API.

Scripts cannot access the incident context; they can only operate on inputs provided as arguments.

Why it fails: Scripts in Cortex XSOAR have full access to the incident context through the demisto object, including incident fields, context data, and previous task outputs. They are not limited to only their arguments. This allows scripts to make decisions based on the current state of the investigation, which is essential for dynamic automation.