Use Case Planning And Development practice questions

Inside the server configuration (Settings > About > Troubleshooting) using global JSON overrides.

Why it fails: Server-level JSON overrides apply globally across all tenants, so they cannot express per-client subscription-tier branching. It is tempting because troubleshooting settings do accept configuration edits, and would be correct for instance-wide defaults, not tenant-specific playbook routing, which belongs in classification and mapping or playbook inputs.

Within the integration instance configuration parameter list as static environment variables.

Why it fails: Integration instance parameters are static per instance and cannot branch execution by tenant tier. They exist to hold connection credentials and endpoint values for one integration. Tier-based routing belongs in the playbook or classifier logic, which can evaluate tenant metadata at run time.

By hardcoding tenant checks into every individual task script using Python sys.argv.

Why it fails: Embedding tenant checks in each task script scatters routing logic across hundreds of scripts, so taxonomy changes require editing every one. Centralised classification mapping or playbook-level conditional tasks suit multi-tenant routing; per-task Python is tempting for its flexibility when logic genuinely varies within a single task.

Within the incident list view column selector.

Why it fails: The column selector customizes which incident fields appear in the table view.

In the user profile settings under password reset.

Why it fails: Password reset settings only manage user credentials.

Inside the dashboard widget editor.

Why it fails: The dashboard widget editor configures visual charts and metrics, not script documentation.

Backing up log files manually to a USB flash drive once a year.

Why it fails: Manual annual USB backups cannot restore an XSOAR HA/DR topology: failover needs replicated PostgreSQL and Elasticsearch nodes plus automated configuration backup, not yearly removable media. It is tempting because offline copies do aid long-term retention, and a USB archive would suit air-gapped evidence preservation rather than live failover.

Running all integrations on a single unmanaged workstation without clustering.

Why it fails: A single unmanaged workstation introduces a solitary failure domain, so losing it halts integration execution and breaks failover entirely. Clustered, managed integration instances distributed across availability zones provide the redundancy and data integrity that HA/DR demands.

Use the 'ServiceNow Incident' integration with the 'create' command and set the task to run unconditionally, relying on ServiceNow's duplicate detection.

Why it fails: Running the task unconditionally would attempt to create a ticket every time the playbook runs, potentially creating duplicates. ServiceNow's duplicate detection may not be configured for this use case, and relying on it is not a reliable way to ensure single ticket creation. The ticket number may also not be captured correctly.

Configure a scheduled job that runs every hour and creates a ServiceNow ticket for any phishing incident without a ticket.

Why it fails: A scheduled job would create tickets on a fixed schedule, not immediately when the incident is created. This introduces latency and could create duplicate tickets if the incident is updated. It also does not guarantee that the ticket number is stored on the incident in a timely manner.

Create a custom automation script that calls the ServiceNow REST API directly and stores the response in the incident context.

Why it fails: While a custom script can create tickets, it bypasses the built-in ServiceNow v2 integration, requiring more maintenance and error handling. The question asks for an XSOAR feature to configure in the playbook, not a custom script. The built-in integration provides a simpler, more maintainable solution.

Set the task 'Continue on error' to true for all tasks.

Why it fails: Setting 'Continue on error' to true allows the playbook to proceed even if a task fails. This contradicts the requirement to stop the playbook on failure. It is useful for non-critical steps, but here it would bypass the failure and potentially leave the incident partially handled, which is not desired.

Use a conditional task after each action to check the result and manually stop the playbook.

Why it fails: While conditional tasks can check results and stop the playbook, they add complexity and are error-prone. Relying on manual checks for every task is inefficient and may miss failures. The built-in 'Stop on error' option is designed for this purpose and is more reliable and simpler to implement.

Set the playbook's 'Run mode' to 'Stopped' before execution.

Why it fails: Setting the playbook's run mode to 'Stopped' would prevent it from running at all. The run mode controls how the playbook is triggered, not its error handling. This option does not address the requirement to stop on task failure and is not a valid configuration for error handling.

Use the built-in loop task with a list input and configure retry settings on the enrichment task.

Why it fails: XSOAR does not have a generic 'loop task' for iterating over lists in the playbook editor. Loops are typically implemented using sub-playbooks or scripts. While tasks can have retry settings, there is no native loop task that iterates over a list. This option misrepresents XSOAR's capabilities and would not achieve the required sequential processing with retries.

Use a sub-playbook that contains the enrichment tasks, and call it in a loop using a condition task.

Why it fails: While a sub-playbook can encapsulate enrichment, using a condition task to loop is cumbersome and does not natively support retries. Condition tasks are for branching, not iteration. Implementing a loop with retries would require complex counter management and is error-prone. This approach lacks built-in retry mechanisms and would be difficult to maintain.

Use a manual task for each indicator and have the analyst retry on failure.

Why it fails: Manual tasks would require human intervention for each indicator, which is impractical for high-volume incidents and defeats automation. The scenario requires automated retries without human involvement. Manual tasks are unsuitable for repetitive, high-volume operations and would introduce significant delays and inconsistency.

Configuring an indicator extraction rule in the integration instance settings

Why it fails: Indicator extraction rules are configured at the integration level to automatically extract indicators from incoming events before they become incidents. This happens during ingestion, not within a playbook task. While useful for initial data population, it does not provide a method to extract indicators from incident data during playbook execution, so it does not meet the requirement of extracting within a playbook task.

Enabling the automatic indicator extraction option in the incident type settings

Why it fails: The automatic indicator extraction option in incident type settings triggers extraction when an incident is created, not during playbook execution. It relies on predefined rules and does not offer a way to extract indicators from specific task outputs or updated incident data within a playbook. Therefore, it cannot be used as a method within a playbook task to extract indicators on demand.

Using the 'extractIndicators' command in a command-line task

Why it fails: The 'extractIndicators' command is not a standard XSOAR command. While there is a built-in ExtractIndicators automation, it is executed as a script task, not via a command-line task. Command-line tasks are used to run integration commands, and no such command exists for indicator extraction. Thus, this option is invalid and would not work in a playbook.

Use the 'Deduplicate' task to remove duplicate indicators from the list.

Why it fails: While deduplication is needed, there is no built-in task called 'Deduplicate' in XSOAR. Deduplication can be achieved through scripting or by using the 'Formatting' options in tasks. This option is incorrect because it references a non-existent task, and the engineer should use other methods such as a script or the 'Unique' transformer.

Use the 'Indicator Enrichment' sub-playbook to automatically enrich all indicators.

Why it fails: While sub-playbooks can be used for enrichment, there is no standard 'Indicator Enrichment' sub-playbook that automatically enriches all indicators. The engineer would need to build or customize one. This option is too vague and not a built-in feature, so it is not the most efficient choice compared to using the dedicated 'Enrich Indicators' task.

Use the 'Create Indicators' task to generate new indicators from the extracted data.

Why it fails: The 'Create Indicators' task is used to create new indicator objects in the system, not for enrichment. It would not help with enriching existing indicators. This option is incorrect because the goal is to enrich, not create. Using this task might lead to duplication and is not part of the enrichment workflow.

Use a single enrichment task that processes all indicators at once, relying on the integration to handle duplicates internally.

Why it fails: Not all integrations deduplicate indicators internally, and some may still make separate API calls for each indicator. Relying on the integration can lead to unnecessary API usage and is not a reliable way to prevent duplicate enrichment.

Use a script to manually parse each source and store indicators in a set, then enrich each unique indicator individually.

Why it fails: While a custom script can deduplicate, it requires additional development and maintenance. XSOAR provides built-in commands like 'ExtractIndicators' and 'GetDuplicates' that are optimized and easier to use, reducing the risk of errors and speeding up development.

Configure the enrichment integration to cache results so that duplicate indicators return cached data without API calls.

Why it fails: Caching can reduce API calls but does not prevent the playbook from attempting to enrich duplicates. It also depends on the integration's caching capabilities, which may not be available or configured. Deduplication before enrichment is more direct and reliable.

Use a 'Foreach' task to iterate over URLs, and within it, check each URL against the blocklist. If a malicious URL is found, use a 'break' condition to exit the loop and proceed to ticket creation.

Why it fails: XSOAR's 'Foreach' task does not support a 'break' condition to exit the loop early. While you can use conditions to skip tasks, the loop will continue iterating over all items. This approach would not stop processing further URLs once a malicious one is found, leading to unnecessary checks.

Use a 'GenericPolling' task to poll the blocklist for each URL sequentially and stop when a malicious one is found.

Why it fails: GenericPolling is for long-running commands, not for iterating over a list. It would not provide a way to stop processing further URLs. This approach is not suitable for the use case and would complicate the playbook unnecessarily.

Use a 'Foreach' task with parallel execution to check all URLs simultaneously, then aggregate results and proceed if any are malicious.

Why it fails: Parallel execution would check all URLs at once, but it does not stop processing once a malicious URL is found; it would still check all URLs. This increases the number of API calls and does not meet the requirement to stop early. Additionally, aggregating results adds complexity.

Use the 'StringReplace' transformer to remove internal domain names from the JSON string.

Why it fails: StringReplace performs literal string replacements, which could inadvertently alter other parts of the JSON or miss variations of the domain. It is not a reliable method for filtering a list of emails. It also does not extract emails; it only modifies existing strings. This action does not meet the requirement.

Use the 'JsonToTable' transformer to convert the JSON response into a table format.

Why it fails: JsonToTable is useful for displaying JSON data in a table, but it is not the most efficient for extracting specific nested fields. It may flatten the structure but requires additional steps to extract the email list. For nested extraction, a JSON path or JMESPath transformer is more direct. This action alone does not accomplish the extraction goal.

A conditional task with multiple branches for each category

Why it fails: While conditional tasks with multiple branches can achieve the selection, the engineer explicitly wants to avoid multiple conditional tasks. This approach would require several conditional tasks or a complex condition, which contradicts the requirement. It is a valid method but not the optimal one given the stated preference for a single task.

A manual task where the analyst selects the sub-playbook

Why it fails: A manual task requires human intervention, which defeats the purpose of automation. The requirement is to dynamically determine the sub-playbook based on the incident field without manual input. Manual selection would introduce delay and potential errors, and it does not leverage XSOAR's automation capabilities for dynamic routing.

A script task that uses the 'executeCommand' to run the sub-playbook

Why it fails: The 'executeCommand' function in XSOAR scripts is used to run integration commands, not to invoke sub-playbooks. Sub-playbooks are executed via a dedicated sub-playbook task. While a script could technically call a sub-playbook through the API, that is not the standard or recommended approach and would be more complex than using the built-in dynamic sub-playbook task.

Use cases that involve zero existing documentation or standard operating procedures.

Why it fails: Undocumented use cases lack the defined inputs and outputs XSOAR playbooks require, so they cannot be automated reliably in a first pilot. They are tempting because documentation gaps often motivate automation projects, and would be correct once processes are formalised and repeatable.

Use cases requiring brand-new custom integrations with unsupported legacy APIs.

Why it fails: Custom integrations against unsupported legacy APIs introduce development and maintenance risk that delays the pilot's time-to-value. They are tempting because they promise coverage of critical legacy systems, and would be correct after core integrations are proven and engineering capacity exists.

Extremely low event frequency and high procedural ambiguity.

Why it fails: Low-frequency, ambiguous cases give no repeatable baseline for measuring automation value, so they cannot validate the platform during a pilot. Such cases are tempting because they expose gaps in undocumented processes, and would be the right choice later when maturing coverage of rare, complex incidents.

Increase the fetch limit per interval to batch all alerts into a single massive payload.

Why it fails: Raising the fetch limit increases the volume of duplicate incidents created per interval, worsening fatigue rather than reducing it. Batching suits low-volume sources where throughput, not duplication, is the constraint; deduplication logic must run before incident creation.

Write a post-processing cron job that deletes duplicate incidents after they are closed.

Why it fails: Deleting incidents after closure leaves analysts already fatigued by the duplicate incidents created during ingestion. Deduplication must occur before incident creation. Post-processing cron jobs suit housekeeping tasks like purging aged closed incidents, not preventing duplicate incident generation.

Disable fetch incidents and rely solely on email notifications sent to the SOC team.

Why it fails: Email notifications bypass XSOAR incident creation entirely, so no deduplication, enrichment, or automated response occurs, and alerts are lost in inboxes. Email suits low-volume notification of summary reports, not ingestion of thousands of hourly alerts requiring triage.

An integration instance fetch-incidents polling interval adjustment.

Why it fails: Fetch-incidents polling interval governs how often an integration retrieves new incidents; it cannot insert an approval gate before an isolation command. It tempts because tuning it controls ingestion timing, but a manual task with analyst approval is needed; polling adjustments would be correct only when incidents arrive late or duplicate.

A pre-processing rule that drops incoming JSON payloads lacking approval metadata.

Why it fails: Pre-processing rules filter or drop incoming events before playbook execution, so they cannot prompt an analyst mid-playbook. They tempt because they gate data entering the system, but approval must occur after the isolation decision point via a manual task; dropping payloads would be correct only for suppressing malformed or unwanted incident ingestion.

A transformer function applied to incident field mapping.

Why it fails: Transformers manipulate field values during mapping and cannot pause execution for human input. They are tempting because they customise data flowing through playbooks, but a manual approval task is required to prompt analysts; transformers would be correct only for reformatting or enriching incident fields automatically.

Use a scheduled job instead of a playbook to poll all three platforms periodically.

Why it fails: A scheduled job polls on a fixed interval and cannot branch on enrichment results or feed them into incident response, so it adds latency rather than optimising the playbook. It is tempting because periodic polling suits continuous indicator ingestion, and it would be correct for maintaining TIP data outside incident workflows.

Place the three integration tasks sequentially in a straight vertical line.

Why it fails: Sequential tasks force each integration to wait for the previous call to return, so total execution time is the sum of all three response times rather than the longest. It is tempting because vertical ordering is the default layout and is correct when each task consumes the prior task's output.

Combine all three TIP calls into a single monolithic Python script inside one automation task.

Why it fails: One monolithic script serialises the three calls and loses per-integration error handling, retry logic and command outputs, so a single failure blocks all enrichment. It is tempting because it reduces task count, and it would be correct where the calls share authentication and must run as one atomic unit.

Terminating employment status of a suspected insider threat.

Why it fails: Employment termination is an HR and legal decision with contractual consequences, so it cannot be executed autonomously by a playbook. It tempts because insider threats require fast containment, which would justify automated account disablement, not irreversible employment actions.

Deleting primary database backups on suspicion of data exfiltration.

Why it fails: Deleting backups is irreversible and destroys recovery capability, so it demands human authorisation before execution. It tempts because exfiltration is high-severity and urgent, which would justify automated containment such as isolating the host, not destroying data.

Revoking executive internet access during an ongoing ransomware outbreak.

Why it fails: Severing executive connectivity during an outbreak risks business-critical operations and needs human judgement about scope. It tempts because ransomware containment is time-sensitive, which would justify automated isolation of confirmed infected endpoints, not blanket revocation of executive access.

Custom DBot score thresholds configured in system settings.

Why it fails: DBot score thresholds are numeric reputation bands applied during indicator enrichment; they cannot branch playbook execution or invoke a sub-playbook. They are tempting because enrichment feeds the criticality decision, but thresholds are correct when you need automatic indicator verdicts, not conditional task routing based on incident context.

Incident layout tab visibility rules.

Why it fails: Layout tab visibility rules control which fields and sections analysts see on the incident screen; they are presentation settings and never execute tasks or call sub-playbooks. They are tempting because both are configured per incident type, but layouts are correct when you need to tailor the analyst's view, not to branch workflow logic.

Global server environment variables evaluated at startup.

Why it fails: Global server environment variables are static values loaded at startup and shared across all incidents; they cannot be evaluated per-incident against enrichment output to select a sub-playbook. They are tempting because they parameterise automation, but they are correct for constants like API endpoints, not dynamic context-driven branching.

CPU utilization of the Demisto engine

Why it fails: CPU utilisation of the Demisto engine reflects infrastructure load, not analyst handling time, so it cannot establish a manual triage baseline. Mean time to resolve phishing incidents is the required metric. Engine resource monitoring is relevant when sizing or tuning the XSOAR deployment, not when measuring human response effort.

Total number of active API integrations

Why it fails: Counting active API integrations measures platform configuration, not human effort, so it cannot express manual triage and resolution duration. The baseline required is mean time to resolve phishing incidents. Integration counts matter when assessing automation coverage or licence capacity, not when quantifying analyst workload before building a playbook.

Total number of ingested log sources

Why it fails: Ingested log source totals describe data onboarding volume, not the duration analysts spend triaging and resolving phishing emails. The baseline needed is mean time to resolve. Log source counts are the correct measure when scoping ingestion licensing or detection coverage, not when quantifying manual phishing handling effort.

Store the PII in plain text inside incident custom fields and restrict access using incident layout roles.

Why it fails: Plain-text storage in custom fields directly violates the requirement that PII not persist in incident fields, and layout roles only restrict display, not underlying storage or API retrieval. Custom fields suit non-sensitive metadata, so this would be acceptable only where the data carries no PII.

Rely on the browser's local cache to encrypt the sensitive fields on the analyst's workstation.

Why it fails: Browser local cache sits on the analyst's workstation, outside XSOAR's control, and cannot satisfy a compliance rule governing XSOAR context data and incident fields; it also stores PII locally. Caching is intended for performance, so it would suit read-heavy dashboards, not PII handling.

Disable the XSOAR server audit log entirely.

Why it fails: Disabling the audit log removes the record of who accessed PII, which most compliance regimes require, and does nothing to stop PII persisting in context data or incident fields. Audit logging is meant for forensic traceability, so disabling it would only be considered where no accountability requirement exists.