XSOAR interview questions with evidence

1. Ticket hook — closed while VT is red

Night shift. Phishing queue shows #12481 Closed — benign. Work Plan still has a red url task against http://203.0.113.50/login. Context has no DBotScore. A junior wants the playbook disabled “so cases stop auto-closing.” Another wants Continue on error on every task. A third will isolate the mailbox from the same reputation step.

That is the interview. A close without score is a silent miss. Continue on error without an isError branch is the same miss with a green playbook. Auto-contain on a timeout is a self-inflicted IR event. Disable playbook is not a workaround — it is turning the SOAR off.

Hero · who talks to whom

2. Mental model: five objects, one case

Interviewers mix “SOAR” with “SIEM” and “EDR” on purpose. XSOAR does not detect the phish. It classifies what an integration fetched, maps fields, runs the type’s playbook, and records every automated or human action. A content pack on Marketplace with no instance inspects nothing. A playbook on a type that never matches never runs.

Path · alert has to land somewhere

Lab tree you should be able to draw cold:

• Instance mail_lab — Fetches incidents enabled; classifier + incoming mapper bound on the instance.
• Incident type Phishing — layout + attached playbook pb_phish_lab (autorun).
• Reputation instance vt_lab — command !url writes DBotScore.
• Containment instance panos_lab — only after a manual approval task.
• Incident #12481 — URL indicator http://203.0.113.50/login.

3. Ingest order and the error branch

Flowchart first. Recite this order; do not skip classifier, and do not skip the failure path.

4. How to choose classifier, mapper, task type

Four tables. Interviewers mix them. Keep the verbs separate: classify, map, orchestrate, prove, approve.

Classifier vs mapper vs type vs playbook

Command vs automation vs playbook

Enrichment-only vs approval-gated vs auto-contain

War Room vs Context vs Work Plan vs Indicators

5. Do: War Room + DBotScore + approval

Side A is the instance. Side B is the playbook branch. Side C is the close proof. Do not start at YAML.

1. Side A — instance that should have fetched

   Settings → Integrations → Instances → mail_lab / vt_lab. Enabled. Fetches incidents on mail. Test. Read the last error. If Test fails, stop — the playbook is not the patient. Check engine vs cloud, key expiry, 429. Then Classification & Mapping → Test with a saved sample. Confirm type Phishing and mapped fields, not a labels dump.

2. Side B — playbook error path

   On pb_phish_lab, reputation task Continue on error = on. Next task is conditional: isError OR DBotScore.Score empty → set EnrichmentFailed, assign, retry. Score 1 → close with reason. Score 2/3 → manual approval. Do not put panos-register-ip-tag on the reputation task. Version, run Playbook Debugger on #12481, then attach on the type.

3. Side C — prove close or contain

   Re-run from the failed Work Plan task. Quote War Room error gone, Context DBotScore.Score present, approval entry if Score 3, then the PAN-OS / XDR command entry. Close reason matches the score. Original URL retest. Change record for the playbook version.

{
  "URL": { "Data": "http://203.0.113.50/login" },
  "DBotScore": {
    "Indicator": "http://203.0.113.50/login",
    "Type": "url",
    "Vendor": "VirusTotal",
    "Score": 3
  }
}

# Score 3 → manual approval task → then panos_lab
# Score empty + War Room error → do not closeInvestigation

# in the incident, not in a random dashboard
!url url="http://203.0.113.50/login" using="vt_lab"

# Settings → Integrations → Instances → vt_lab → Test
# never: disable pb_phish_lab
# never: Continue on error on every task + close as benign
# never: isolate in the same task as reputation

6. Runtime path after go-live

After pb_phish_lab is attached, every new fetch still walks classifier → mapper → type → playbook. Pack updates do not magically add your error branch. Instance Test going red at 02:00 is how you get a queue of Closed-benign with empty scores — unless pre-process dropped the events first.

• New event → instance fetch (or REST) → pre-process (drop / link) → classifier → mapper → type playbook.
• Extract indicators → reputation commands → DBotScore in context + War Room entry (manual !url always prints; some auto-extract flows skip War Room print — still check Context).
• Condition on Score / isError → assign or approval → contain command → closeInvestigation with a reason that matches evidence.
• Jobs and SLA timers keep running after you leave the tab. A waiting manual task is not a close.

Proof · cockpit

7. Eight interview scenarios

8. Traps and proof checklist

Sources

• Classification and Mapping — classifier picks incident type; mapper maps event attributes to fields (unmapped stay in incident.labels)
• Playbooks overview — manual, conditional, and command tasks; !url / !file generic commands
• Playbook conventions — auto-extract per task; common authoring mistakes
• Calculate Severity By Highest DBotScore — Score as the branch input
• Cortex XSOAR docs — incident type attaches the playbook after classify + pre-process
• Integrations reference — commands and context outputs
• Cortex XSOAR product

Related: XSOAR playbook lifecycle · Cortex XDR architecture · Cortex XSOAR syllabus · Interview hub