XSOAR Engineer common mistakes
XSOAR Engineer · Understand the traps and how to avoid them.
Treating the Content Pack installation as the end of integration setup: adding an instance but never testing it, never checking whether the fetch parameters (incident type, fetch query, first-fetch lookback) are correct, and assuming the integration will pull incidents immediately.
Candidates memorize the 'add instance and test' flow and skip the operational layer: the fetch query, classifier/mapper association, and the fact that a failed instance test silently stops fetching. The platform separates instance configuration, classification, and fetching, and the exam tests exactly those seams.
What to do instead
For every integration instance, be able to state in order: instance parameters, the Test button result, the fetch query/incident type, the classifier and mapper attached, and the first-fetch window. Practise describing what happens to incidents when the instance test fails (fetching stops, no incidents are created) and where to verify that.
Confusing the roles of classifier, mapper, and pre-processing rules: describing the classifier as the component that sets field values, or the mapper as the component that decides incident type.
These three are configured on the same incident-type page and all act on incoming incidents, so candidates blur them under time pressure. The distinction only becomes obvious when you have debugged a misclassified incident.
What to do instead
Use a one-line mental model: classifier decides the incident type, mapper fills fields for that type, pre-processing rules run before classification/mapping and can drop or modify raw data. Then walk a sample raw incident through all three in order and state the output of each stage.
Writing playbook tasks that reference task outputs by the wrong path, or assuming a task output exists when the task was skipped or failed, causing later tasks to receive empty or null context.
Candidates learn the ${} syntax and the general idea of context keys but do not internalize that each task writes under its own unique task ID, and that outputs are only populated when the task actually ran. Playbook testing with happy-path data hides this.
What to do instead
Always build context references by picking the task and output from the playbook editor rather than typing them, and explicitly design for the skipped/failed branch: add conditional tasks that check whether the key exists (or use built-in filters) before consuming it. Test the failure path, not just the success path.
Using a script or transformer where a built-in playbook task or filter would do, or conversely hand-rolling complex logic in a playbook instead of writing a script, and being unable to justify the choice.
Candidates over-index on coding because the exam is for engineers, and forget the platform's design guidance: simple data manipulation belongs in filters/transformers, reusable logic belongs in scripts, and orchestration belongs in playbooks. The exam probes judgement, not just capability.
What to do instead
Learn the decision rule: use built-in filters and transformers for field-level data shaping, automation scripts for reusable logic with defined inputs/outputs, and sub-playbooks for reusable orchestration. For any scenario, state which layer you would use and why the other layers are worse.
Describing automation scripts without declaring inputs and outputs properly, or returning a value in a format the playbook cannot consume (for example returning a Python object instead of a serializable structure, or forgetting to return results at all).
Candidates write scripts that work when run manually in the script editor but fail as playbook tasks because the editor's test harness tolerates things the task engine does not. The inputs/outputs contract is easy to overlook.
What to do instead
For every script, define named arguments, read them from the documented argument mechanism rather than hardcoding, and return a dict with clearly named keys. Practise converting a manual script into a task and verifying the returned keys appear as task outputs in the playbook context.
Assuming all engines execute identically: writing a playbook or script that runs on one engine and expecting the same behaviour on another (for example relying on Python-only libraries or on engine-specific context handling).
XSOAR supports multiple script execution engines, and candidates often learn one and generalize. Differences in available libraries, return semantics, and how the engine passes arguments cause silent failures on the other engine.
What to do instead
Know which engines your deployment supports and their constraints: which Python version and libraries are available, how arguments and return values are handled, and whether the engine is available in the customer's deployment type. State engine choice explicitly when answering design questions.
Treating incident fields, layouts, and incident types as cosmetic, and failing to connect them to classification, mapping, and playbook triggering.
Candidates focus on playbooks and integrations as the 'real' engineering work and skim the incident-type configuration, missing that the incident type is what binds classifier, mapper, layout, and default playbook together.
What to do instead
Be able to trace one incident end to end: raw data arrives, pre-processing rules apply, classifier assigns incident type, mapper populates fields, layout displays them, and the incident type's default playbook runs. Explain what breaks at each link if a piece is misconfigured.
Answering troubleshooting questions with 'check the logs' or 're-run the playbook' instead of naming the specific diagnostic surface and what a given symptom implies.
Candidates lack hands-on exposure to failure states, so they fall back on generic advice. The exam rewards candidates who can map a symptom (no incidents fetched, task stuck in waiting, integration command timed out) to the exact place to look.
What to do instead
Build a symptom-to-surface table: instance test failure and fetch issues point to the integration instance and its logs; task errors point to the specific task's inputs and outputs in the playbook; command failures point to the integration's command and the remote API response. Memorize at least one concrete diagnostic step per symptom class.
Ignoring the difference between deployment topologies when answering architecture questions, for example describing a multi-tenant or high-availability setup as if it were a single all-in-one server.
Candidates study one lab environment and generalize its behaviour. Questions about scaling, engine placement, database separation, and content distribution assume the candidate knows which components can be split across hosts.
What to do instead
Learn the component roles (application server, database, engines, message broker, content repository) and which can be separated or scaled. For any architecture question, first identify the deployment type assumed, then answer within it.
Designing playbooks that ignore idempotency and loop safety: tasks that re-run actions on already-handled incidents, unbounded loops, or no exit condition when a condition never becomes true.
Candidates test with a single clean incident and never consider re-entry, retries, or a condition that stays false. Real incidents get re-processed and playbooks hang, but the exam scenario only reveals it if you think about edge cases.
What to do instead
For every playbook you design, state the entry conditions, add a guard so already-closed or already-handled incidents exit early, bound any loop with an explicit maximum or timeout, and define what happens when a condition is never satisfied. Mention these guards explicitly in your answer.