Domain 1: Planning, Installation, and Maintenance
- Roles created in Cortex Gateway are available in every tenant, but the advanced role settings of default dashboards, preset queries and weekly shifts are defined per role inside each tenant, and those shifts start on Sunday and are entered in UTC.
- A user group carries a single role, so a user who needs several roles joins several groups and receives the highest access from the combination, and deactivating a user neither revokes that user's API keys nor reassigns the user's incidents and tasks.
- SAML SSO is configured separately for each tenant in both the IdP and the tenant, SAML users sign in at the tenant FQDN rather than through Cortex Gateway, and the Execute potential harmful actions permission governs only CLI use of Potentially Harmful commands because playbook tasks run as the DBot user.
- Several engines can share one host only through the Shell installer with the multiple-engines setting, the UI Edit Configuration of a Shell engine overrides d1.conf, and keys such as http_proxy, https_proxy, BindAddress and EngineURLs can be set only in d1.conf.
- Common engine faults have documented fixes: synchronize the engine clock with NTP for a d1ws bad handshake, move BindAddress to a high port such as 8443 when port 443 cannot be bound, and check the cron job that collects the upgrade file when a UI engine upgrade fails.
- Setting engine.to.server.proxy to false in d1.conf sends integration traffic through the configured proxy while the engine talks to the tenant directly, and an engine created on a main tenant reaches child tenants only through a propagation label plus the setting that lets tenants use it for their own integration instances.
- Production content is updated only by pushing from the development tenant and installing on production, never by manual export and import, individual content items but not whole packs can be excluded from a push, and pack items edited after a push are pushed again from the Local Changes view.
- The built-in remote repository suits a single-branch deployment while a private Git repository is needed for several branches or outside access, overwriting a repository with tenant content requires an empty branch, and custom content should be exported as a backup before repository settings change.
- Marketplace packs are Cortex XSOAR, Partner, Developer or Community supported, with Developer-supported packs backed by their publisher and Community-supported packs carrying no publisher support, per-pack update notifications can be turned on only after a pack is installed, and contributed content is checked by the ValidateContent script, which runs demisto-sdk validate and lint.
- The Deployment Wizard detaches an incident type whose playbook differs from the recommended one, and the Default pack works by assigning the Default layout and Default playbook to an incident type after any locked type is duplicated or detached.
- On an integration instance a configured classifier outranks the incident type chosen on the Collect settings, fetching should be enabled only once classification, mapping and the playbook are ready, the fetch interval defaults to 1 minute, and Clear all queued items empties an instance's ingestion queue during a flood.
- An instance that keeps hitting API rate limits on the tenant can be moved to an engine, a Bundle ID ties together every log line from one command or fetch execution, credentials objects keep secrets out of instance settings, and fetch-error emails need module.health.notification.users plus message.ignore.failedFetchIncidents set to false.
- A Cortex XSOAR 8 SaaS production tenant handles 24,000 incidents a day at up to 1,000 an hour and queues the excess rather than dropping it, while a development tenant has lower limits and should not be used for production or stress testing.
- Server configuration keys tune system behaviour, for example engines.notification.users for engine disconnect emails, UI.version.control.admin.only to restrict repository pushes to administrators and ignore.default.in.playbooks to make playbooks honour Do not use by default, while management audit logs are kept for one year and export as TSV.
- Cortex XSOAR 8.14 On-prem upgrades move one version at a time and cannot be rolled back, a restore needs a cluster on the same version with the same resources, and backups use a dedicated target folder per cluster and per backup task with at least 30 days of retention.
Domain 2: Use Case Planning and Development
- The incident lifecycle runs from planning and configuring integrations through classification and mapping, pre-processing, incident creation and the playbook to post-processing at closure, and planning of incident types, fields and layouts is revisited once real data starts arriving.
- The indicator lifecycle identifies the type and value, formats and validates it, creates or updates the indicator, gathers reputation and enrichment, applies reputation scripts, maps indicator fields and finally handles expiration, with a daily job updating Expiration Status and new data returning an expired indicator to Active.
- Incidents are kept six months by default, up to 1,000 incidents per tenant can be retained indefinitely by roles with the retain permission and found with retained:T, and incidents exported to cloud storage become JSON files that cannot be imported back.
- A tenant allows at most 1,000 incident fields in total including system and content pack fields, Long text fields are indexed word by word for wildcard search but cannot be sorted or charted in graphical widgets, and a new field is added to every incident type unless that default is cleared.
- Scripts tagged field-display decide whether a field appears on the new, edit or close forms and which values it offers, whereas field trigger scripts react to changes, cannot close incidents, receive only the delta for list fields and do not fire when a post-processing script changes the field.
- An incident layout has four views (Incident Summary, New/Edit form, Close form and Incident Quick View), tabs can carry a Display Filter and Viewing Permissions, each section should hold no more than 50 fields, and a detached layout keeps its name so its incident type needs no change.
- At ingestion Common Mapping is applied first and the incident type mapping then overrides it, fields restricted to particular incident types appear only when that type is selected in the mapper, and data that is not mapped is discarded or left in unsearchable labels.
- A content pack classifier is duplicated before editing, uploaded sample data must be an array of dictionaries, a dot inside a mapped field name is escaped with a backslash, outgoing mappers draw on the integration schema or uploaded JSON to support mirroring, and integration YAML can name a default classifier and incoming and outgoing mappers.
- Incidents can arrive from fetching integrations, long-running listeners such as Generic Webhook, the REST API, playbooks or manual creation, but API-created incidents run no playbook unless createInvestigation is true and incidents created by a playbook or by hand skip classification, so their type must be set at creation.
- A well-built fetch-incidents command stores each event in rawJSON for classifiers and mappers, honours a max_fetch default from the YAML, keeps lastRun to small values such as the latest creation time and IDs, and returns an empty list when nothing is new so the instance stays healthy.
- Pre-process rules act before an incident is created and can drop, drop and update, link, or link and close incoming duplicates, only scripts tagged preProcessing can run from a rule, and a Drop and update match records the dropped event and a droppedCount on the existing incident.
- A post-processing script is set on the incident type, runs after remediation and before closure no matter who closes the incident, blocks closure by returning an error, and loses the system closure arguments from demisto.args() once it declares its own custom argument.
- The incident type Settings tab holds the default playbook, layout, post-process script and SLA with reminder while extraction rules sit on their own tab, and duplicating a content pack incident type keeps the original receiving pack updates.
- An incident type SLA sets the due date from creation to closure and applies only to incidents ingested after it is defined, whereas Timer/SLA fields such as Time to Assignment track a single step and must be started, paused or stopped by a playbook, script or CLI command.
- Pausing a timer keeps its accumulated time but stopping ends the run, closing an incident stops its timers until resetTimer is used, only SLA-tagged scripts can run on an SLA breach, and slaStatus reports -1 with no SLA, 0 within range, 1 past the risk threshold and 2 in breach.
- Lists hold Text, Markdown, HTML, CSS or JSON content such as communication templates or internal network ranges, Save Version keeps a restorable history, a detached pack list stops receiving updates, propagation labels deliver lists to child tenants, and scripts manage them with getList, createList, setList and removeFromList.
Domain 3: Playbook Development
- Playbook inputs and outputs are defined in groups on the Playbook Triggered task, inputs can come from incident context or from indicators as in Threat Intel Management playbooks, and input names follow PascalCase such as EntityID.
- A task's Advanced settings can mark results as evidence for the Evidence Board or as a filterable note, tag results for War Room filtering and layout sections more reliably than task IDs, and run without a worker, while Quiet Mode keeps playbook output out of the incident to save size and time.
- Integration command outputs are declared in YAML as BrandName.Object.PropertyName context paths, CommandResults writes them under outputs_prefix with outputs_key_field deciding whether entries update or append, and Extend context saves extra raw-response fields, found by running the command with raw-response=true.
- Context is the per-incident JSON store of every command and script result, DT selectors filter it with JavaScript over val and obj and mutators such as =val.toLowerCase() reshape a value, while Set (which accepts a DT selector key only when append is true), SetIfEmpty, SetMultipleValues, SetByIncidentId and DeleteContext with keysToKeep handle routine writes and clean-up.
- A manual task waits until the responsible analyst completes it, an automated task with empty required arguments waits for them to be filled, section headers group tasks and time playbook phases for dashboards, and a task can skip its branch when its script or sub-playbook is unavailable.
- Ask and data collection communication tasks can reach users outside the platform by email and web survey, data collection sends multi-question surveys whose replies land in context and can close early after a set number of replies, and forms sent to distribution lists need external.form.validate.user set to false.
- Sub-playbooks are reusable building blocks with generic inputs, a For Each Input loop runs the sub-playbook once per item, a loop that exits on a condition treats its inputs as a whole, and loops are worth using only when actions must stay paired to specific data.
- A polling design starts the remote job and saves its ID, hands it to the GenericPolling sub-playbook with the polling input marked Is array and any extra arguments passed through AdditionalPollingCommandArgNames and AdditionalPollingCommandArgValues, then retrieves the results, and Scheduled Commands can replace the playbook inside code.
- Filters cast values to the expected type and fail the task when casting fails, a list on the left of a single-item filter passes if any item matches, Is defined treats empty strings and empty lists as defined, and Matches uses Go-style regular expressions.
- Transformers apply in the order listed and can be dragged to reorder, some act on each item while others such as Count act on the whole list, Slice uses a zero-based start and an exclusive end, and custom transformer scripts need the transformer tag plus entirelist to see the full array.
- The playbook debugger opens attached playbooks in View and custom or detached ones in Edit, can use incidents built from imported JSON as test data, runs with the logged-in user's permissions, uses its own worker pool sized by workers.count.Debug, and ignores a breakpoint whose condition refers to missing data.
- Integration problems are traced by adding debug-mode=true to a command, test-module or fetch in the CLI to attach a log file, by setting the instance Log Level to Verbose only while troubleshooting, and by temporarily raising fetch.history.size above its default of 20 records.
- Built-in content includes the Base and Common Scripts packs, CommonServerPython and CommonServerPowerShell helper libraries, and scripts such as taskComplete, getEntries, SetGridField and ScheduleCommand, while script tags such as dynamic-section, widget, enhancement and reputation decide where a script can be used.
- A custom script declares typed arguments and dot-notation context outputs, can run as DBotRole while a Role limits who may run it, runs Python on the demisto/python3 Docker image by default, and should raise exceptions caught in main so return_error shows a readable War Room error.
- A scheduled polling command needs polling: true in the integration YAML and returns a PollResult that decides whether to continue, runs no more often than every 10 seconds without holding a worker while waiting, and reuses its first execution's arguments on every rerun.
- Jobs are time triggered on a recurring schedule or event triggered by feed changes, queue handling decides whether a new run is skipped or replaces a run still in progress, the Role field controls access to the incident a job creates, and indicator processing playbooks in jobs should run in quiet mode.
Domain 4: Incident Interactions and Reporting
- A Pending incident has not started its investigation, while an Active incident has an activated War Room, starts its assigned playbook and can be assigned to users, and severity maps to numbers as Critical 4, High 3, Medium 2, Low 1, Informational 0.5 and Unknown 0.
- From the incidents table an engineer can assign incidents in bulk, mark one as a duplicate of an incident kept by ID, run one command across all selected incidents and close incidents even when tasks are still open, though batch edits cannot upload files.
- Incident search evaluates times in UTC with relative months limited to 12, word searches on name, type and phase need the raw prefix such as rawName for exact matches, and regex searches place the pattern between slashes inside quotes.
- A saved query is replaced by saving another with the same name and can become the page default, while a shared query cannot be edited by its recipients and stays with them after unsharing only if they copied it or set it as their default.
- Incident table exports produce a CSV Summary Report or an Excel Detailed Report of the visible columns for up to 1,000 incidents, and investigation summary PDFs come from layout tabs other than the War Room, Work Plan and Evidence Board, by template or with GenerateSummaryReports.
- In the CLI an exclamation mark runs commands and scripts, a slash runs system operations and an at sign notifies users, backticks avoid escaping quotes, using picks the integration instance, retry-count and retry-interval control retries and auto-extract selects inline or out-of-band extraction.
- Each user has a private Playground for testing commands outside an incident, edited War Room entries gain a History link, and investigation.prevent.modify.closed decides whether chats and notes can be added after closure.
- The Work Plan shows the running playbook, rerunning the current playbook is done by selecting it again, ad-hoc tasks run a single automation or a whole playbook for that run only, and the plan can be exported as a PNG or managed with the /task command.
- Evidence can be added from War Room entries, uploads, the AddEvidence command or playbook tasks, tags added on the Evidence Board are not copied back to the War Room, and War Room markdown highlights ==text== and renders %%% blocks as buttons that run commands.
- Linking groups related incidents without closing them, whereas deduplication closes or drops one of them, and the canvas suggests related incidents from shared labels, indicators and custom fields, expands entity relationships and saves snapshots to the War Room.
- Mirroring ties a Cortex XSOAR incident to an external ticket through dbotMirrorId, close_incident and close_out decide which side closes the other, get-remote-data closes the local incident with a dbotIncidentClose entry, and dirtyFieldsAll triggers a full field synchronization.
- A child investigation compartmentalizes a sensitive line of inquiry and can be restricted to a select group, and post-processing scripts such as CloseLinkedIncidentsPostProcessing close linked incidents when the main incident closes.
- Out-of-the-box dashboards are duplicated before editing or sharing, dashboards move between environments as JSON, Read only sharing lets users copy and export while Read & Edit also allows editing, and only the owner can delete a shared dashboard for everyone.
- New reports default to the last 7 days as A4 portrait PDF, CSV output keeps only tables and text widgets, reports run in UTC unless the report or reports.time.zone changes it, and a Page Break widget prevents overlapping text after long tables.
- Widgets draw on data sources such as incidents, indicators, SOAR Metrics and War Room Entries, grouping by a custom field requires that field to be searchable, custom calculations use CLI names, and script widgets need the widget tag and read searchQuery, from and to from their arguments.
- Dashboards perform best with simple widgets, refresh intervals above one minute and a limited widget count, and the Cost Optimization Playbooks and API Execution Metrics dashboards show playbook runtimes and enrichment API usage.
Domain 5: Threat Intelligence Management
- Threat Intelligence Management extends the indicator library with intelligence detail views, relationships and Threat Intel Reports, so without a TIM license indicators can still be customized but relationships and the detail view are unavailable.
- A Threat Intel Report moves from draft to review to published, publishing makes it read-only for every role until it is unpublished, it can be shared outside Cortex XSOAR as a PDF, and its built-in types are Campaign, Executive Brief, Malware, Threat Actor and Vulnerability.
- On the Threat Intel page a search accepts wildcards and complex queries while a lookup returns one exact value, sourceBrands matches an integration while sourceInstances matches one instance, and a main tenant views indicators from child tenants without creating them there.
- Indicators are created by feed integrations, by extraction from incident data that matches an indicator type regex, and manually or by scripts such as createNewIndicator and CreateNewIndicatorsOnly, which reports whether each value was new or already existed.
- Extraction settings are defined per incident type, inline extraction holds the playbook until indicators exist while out-of-band extraction runs in parallel without writing to context, extraction from the Labels field should be disabled, and returning IgnoreAutoExtract set to True stops extraction for a script's output.
- Feed integrations shape ingestion through settings such as a CSV feed's Ignore Regex, a JSON feed's JMESPath extractor with default Bad reputation and C - Fairly reliable source reliability, and a TAXII 2 feed's collection name and Full Feed Fetch behaviour.
- An indicator type profile is defined on its Settings tab with custom fields mapped on its Custom Fields tab, a new field needed by only one type should relate only to that type, and enabling the File SHA-256, File SHA-1, File MD5 and SSDeep types in place of File gives every hash its own indicator.
- Indicator field trigger scripts need the field-change-triggered-indicator tag and receive the changed indicators with old and new values, while formatting scripts such as FormatURL refang hxxp links and unwrap URL defense prefixes before the indicator is stored.
- An indicator layout has Indicator Summary, Quick View and New/Edit form views, a duplicated layout takes effect only after the indicator type's Layout field points to it, and setIndicators can reset an indicator's expiration to never or to a specific time.
- Indicator relationships require a TIM license, default to related-to when added from an indicator, can be created by CreateIndicatorRelationship from a named entity or an indicator query, and must use relationship names from the predefined list.
- An indicator's verdict comes from the source with the highest reliability on the Admiralty scale, scores run from 0 Unknown through 1 Benign and 2 Suspicious to 3 Malicious, and smart merge fills fields from the most reliable source while appending tags and multi-select values from all sources.
- Generic reputation commands such as ip and domain enrich through every enabled integration that implements them, enrichIndicators and the Enrich button use the enrichment cache and update the indicator, and enhancement scripts run on demand rather than during extraction.
- The Generic Export Indicators Service replaces the deprecated External Dynamic List integration, each instance occupies its listen port and the next two ports, a q query exports at most 100,000 indicators, and on a SaaS tenant without an engine it uses basic authentication with no custom certificates.
- The TAXII2 Server shares indicators as collections that map names to indicator queries under the threatintel API root, reached on Cortex XSOAR 8 through the tenant's ext- address and the instance execute path.
- An exclusion list entry holds a value, a regex flag, a reason and indicator types, CIDR values exclude whole ranges, excluding a domain with all subdomains takes two entries, the excludeIndicators command adds entries without regex, and the EXCLUSION LIST permission limits who can change the list.
Palo Alto XSOAR Engineer exam tips
- Spend the most time on Playbook Development at 30 percent: build playbooks that read and write context, use Extend context, DT selectors, filters and transformers, and run them in the debugger until the data each task receives is predictable.
- Use Case Planning and Development at 22 percent rewards knowing the order of ingestion: integration instance, classifier, Common Mapping then incident type mapping, pre-process rules, incident creation, playbook and post-processing, plus how SLAs differ from Timer/SLA fields.
- Threat Intelligence Management at 18 percent is detail-heavy, so learn how verdicts follow source reliability, how extraction modes behave, what needs a TIM license and how the Generic Export Indicators Service, TAXII2 Server and exclusion lists share or suppress indicators.
- Incident Interactions and Reporting at 16 percent is best learned hands-on in the CLI and War Room: practise the !, / and @ prefixes, common CLI arguments, Work Plan actions, incident search syntax, linking versus deduplication, and widget and report settings.
- Planning, Installation, and Maintenance is only 14 percent but tests exact procedures, so know where engine keys live in d1.conf, how Cortex Gateway roles differ from tenant settings, how dev/prod push and remote repositories work and which server configuration keys fix common problems.
Study guide FAQ
What does the XSOAR Engineer exam cover?
Five domains from the August 2025 datasheet: Planning, Installation, and Maintenance (14%), covering authentication, engines, dev/prod deployments, Marketplace packs, integration instances and system maintenance; Use Case Planning and Development (22%), covering lifecycles, fields and layouts, classifiers and mappers, incident creation, pre-processing and post-processing, SLAs and lists; Playbook Development (30%), covering task inputs and outputs, context, task types, sub-playbooks, filters and transformers, the debugger, scripts and jobs; Incident Interactions and Reporting (16%), covering incident states and actions, the War Room, relationships, dashboards and reports; and Threat Intelligence Management (18%), covering indicators, feeds, relationships, enrichment, sharing and exclusion lists.
How does CertGrid practice map to the real exam?
The CertGrid bank holds 549 questions written to the five datasheet domains and weighted the same way: 79 in Planning, Installation, and Maintenance, 113 in Use Case Planning and Development, 165 in Playbook Development, 91 in Incident Interactions and Reporting and 101 in Threat Intelligence Management, with many scenario items built around d1.conf entries, classifier and mapper plans, context paths, filter and transformer chains, CLI commands and export settings.
What is the passing score?
Palo Alto Networks sets the passing score at 860 on a 300-to-1000 scale for every one of its certification exams, and it publishes no question count or seat time for this exam, so the length of a CertGrid mock is a practice setting and a scaled score cannot be read as a percentage correct.
How should I prepare?
Start with Playbook Development at 30 percent, then Use Case Planning and Development at 22 percent, Threat Intelligence Management at 18 percent, Incident Interactions and Reporting at 16 percent and Planning, Installation, and Maintenance at 14 percent. Research the keywords of each blueprint task in the Cortex XSOAR 8 documentation and on xsoar.pan.dev, complete the Palo Alto Networks learning path, and work hands-on with integration instances, classifiers and mappers, playbooks, the debugger and feeds in a development tenant if you can.
Official exam sources
The domain names and weightings on this page follow the published exam blueprint. Each source below records what it confirmed and when it was read, so the split can be checked rather than taken on trust.
- Palo Alto Networks - XSOAR Engineer datasheetBlueprint revised AUGUST 2025 · link and content verified 20 October 2026Five domains totalling 100%: Planning, Installation, and Maintenance 14%, Use Case Planning and Development 22%, Playbook Development 30%, Incident Interactions and Reporting 16%, Threat Intelligence Management 18%; leaf objectives per the datasheet blueprint table.
- Palo Alto Networks - certification handbooklink and content verified 20 October 2026"For ALL Palo Alto Networks Certification exams, the converted raw passing score is 860 on a scale of 300 to 1000." 700 is CertGrid's own internal threshold, not the vendor figure.
The vendor does not publish this. Palo Alto publishes neither an item count nor an exam length for this exam on its certification page, in the datasheet or in the handbook. So the 90 minutes and 75 questions of the CertGrid mock are practice settings, unverified from Palo Alto's own documents, and the question count is shown as "Varies" rather than as a Palo Alto figure.