Domain 1: Planning and Installation
- Plan the tenant region first, because a Strata Logging Service instance that streams data into Cortex XSIAM must be in the same region as the tenant, and onboard Palo Alto Networks firewall and cloud logs early because they give the analytics the most immediate security context.
- Agent bandwidth scales linearly at about 120 Mbps for every 100,000 agents, and an agent rollout plan verifies endpoint operating systems, identifies third-party security products for compatibility and runs a proof of concept that simulates production.
- A standard Broker VM needs at least 4 cores, 8 GB RAM and a thin-provisioned 512 GB disk, while an engine needs at least 8 cores and 16 GB RAM for development or 16 cores and 32 GB RAM for production, on x86_64 only.
- Engines run on supported Linux distributions with Docker or Podman installed first unless the shell installer is used, need Python 3 and IPv4 forwarding for DEB and RPM installs, and do not support natively running Python or PowerShell integrations and scripts.
- The Cortex XDR agent cannot use a proxy that requires authentication, so an authenticating upstream proxy is reached through a Broker VM agent proxy holding those credentials, and on Linux SELinux must be enabled before the agent is installed or the agent has to be reinstalled.
- Connectors, standard data collectors and cloud service provider onboarding are configured from Data Sources & Integrations, Broker VM applets from the Broker VMs page and XDR Collectors under Settings > Configurations > XDR Collectors, and a content pack integration is used instead of a standard collector when automations or rules are also needed.
- An installed integration is configured by adding one or more instances, an On Demand instance runs only when a playbook or CLI command names it with the using argument, and integration permissions can restrict each command to specific roles per instance.
- Agent traffic is outbound only and need not be bidirectional: ch-<tenant> carries heartbeats, dc-<tenant> carries EDR data uploads, and cc-<tenant> serves verdict requests with latency-based routing to the closest region.
- Infrastructure IP addresses carry tenant traffic to on-premises components such as the Broker VM, Data Collection IP addresses carry tenant traffic into the network to collect data, egress IP addresses reach external services, and engines connect outbound to wss://api-<tenant>.xdr.<region>.paloaltonetworks.com/xsoar/d1ws.
- Windows agents are installed per machine with msiexec at the default path, and installation properties such as VDI_ENABLED=1 for non-persistent VDI, TS_ENABLED=1 for multi-user temporary sessions, ENDPOINT_TAGS for dynamic endpoint groups and proxy_list for up to 10 proxies shape the deployment.
- RESTRICT_LIVE_TERMINAL, RESTRICT_SCRIPT_EXECUTION and RESTRICT_FILE_RETRIEVAL disable a response action for the life of that installation, and a VDI golden image is prepared with cytool imageprep scan so clones start with local verdicts.
- A Broker VM registers with a token valid for 24 hours, and in a Broker VM HA cluster listener applets such as Syslog, NetFlow and Windows Event Collector run active/active behind a load balancer you supply while pull applets such as the Kafka, CSV, Files and Folders and Database collectors run active/passive on the primary node.
- Broker VM outbound bandwidth to the tenant is planned at about 25 percent of the data arriving at its applets, up to 50 percent on unstable links or poorly compressible data, and the Broker Service FQDNs are excluded from SSL decryption when the decrypting CA cannot be uploaded to the broker.
- Engines can be placed in load-balancing groups with each engine in only one group, keep their logs in /var/log/demisto and settings such as proxy and log level in d1.conf, and act as a proxy so integrations reach services the tenant cannot reach directly.
- Tenant-level roles are recommended over Cortex Gateway roles because they support Scope Based Access Control and dataset access management, but SBAC is not enforced until Enable Scope Based Access Control is turned on in Server Settings.
- SAML group mapping is case sensitive and needs each group as a single value such as the group CN, with Microsoft Entra ID using the group object ID, and the SSO Default Role should be least privileged because JIT-provisioned users without an explicit assignment inherit it.
Domain 2: Integration and Automation
- The Broker VM Syslog Collector accepts UDP and TCP, where UDP messages are truncated at 4 KB and newline framing caps each TCP message at 64 KB, so octet-counting framing is used for larger messages, and for CEF or LEEF the Vendor and Product in each event take precedence over the collector settings.
- The Windows Event Collector applet needs Broker VM 8.0 or later and a broker FQDN resolvable in DNS, forwarders reach it on TCP 5986 with the WinRM plugin running as NETWORK SERVICE, and audit policies must still be enabled on the forwarders because the WEC only controls which events are queried.
- Firewalls and Panorama onboard through the direct NGFW integration, which needs the Panorama Cloud Services plugin, log forwarding profiles on the rules and a per-firewall certificate on PAN-OS 10.1 and later, and raw logs land in per-type panw_ngfw_*_raw datasets while stitched data is queried in xdr_data or presets such as network_story.
- XDR Collectors use Filebeat profiles for uncompressed JSON or text logs, Winlogbeat profiles on Windows only and Settings profiles for upgrades, and the add_fields processor sets vendor and product so events land in <vendor>_<product>_raw.
- Generic S3 collection reads an SQS queue fed by object-create notifications from a dedicated bucket and prefers Workload Federated Identity for short-lived role assumption, while Azure Event Hub collection needs the event hub connection string, a storage account for checkpointing and a consumer group, sized in advance because partitions cannot be changed.
- Broker VM collectors such as NetFlow, Database and Kafka write to a dataset named <vendor>_<product>_raw from their Vendor and Product values, and the NetFlow Collector is sized at 4 CPUs for up to 50K flows per second and 8 CPUs for up to 100K.
- An indicator's verdict comes from the source with the highest reliability, which is set per integration instance, and rate-limited services such as Whois are best run on an engine so requests leave from the organization's own IP address.
- Issue classifiers map a rawJSON value to an issue type with a default type for unmapped values, and mappers apply a common mapping first and then type-specific mappings that can overwrite it, so naming a mapper after its issue types eases maintenance.
- Long-running integrations listen for inbound data, need a unique Listen Port per instance on an engine, are rate limited to 600 requests per minute on the tenant, and support custom long-running integrations and custom certificates only on engines.
- The Generic Export Indicators Service publishes indicator lists as an external dynamic list in formats such as PAN-OS text, can run as several instances with different queries and formats, and in on-demand mode needs export-indicators-list-update run once to initialize.
- Adding a content pack to the Marketplace Cart pulls in its mandatory dependencies, an install error blocks installation while a warning does not, and reverting a pack deletes content items that are not in the target version, which can break other packs.
- A detached content item stops receiving Marketplace updates and reattaching it overwrites local changes, while packs can be updated during working hours because a playbook already running finishes on its original version.
- The Playbook Catalog lists every Marketplace playbook to preview and adopt while the Org Repository holds adopted ones, which are locked to Playbook Starts settings until opened in the editor or duplicated into an editable copy.
- An automation rule triggers one playbook or Quick Action per issue, so several actions belong in one playbook, playbooks started by rules, jobs or feed triggers run as the system rather than under a user's scope, and a job's playbook must close its investigation or the job stays Running.
- Standard tasks act and Conditional tasks branch, a failing task can continue down an Error Path where GetErrorsFromEntry reads the error, the Using field picks the integration instance (empty runs all instances), and GenericPolling polls until its filter returns no unfinished IDs.
- Extend Context with a DT expression plus Ignore Outputs keeps context small, custom filters and transformers are scripts tagged filter or transformer, and the playbook debugger runs tasks for real with the logged-in user's permissions, so destructive tasks are skipped and their outputs overridden.
Domain 3: Content Optimization
- A Parsing Rules file holds INGEST sections that define the target dataset plus CONST, RULE, COLLECT and EXTEND sections in any order, every statement ends with a semicolon, XQLp permits only the alter, fields, filter, join and call stages without a leading dataset, and a drop stage must come last.
- INGEST requires vendor, product and target_dataset with no_hit defaulting to keep, a fields stage fixes the dataset schema to the listed fields, and because all rules in a group are evaluated independently rather than first-match, overlapping INGEST sections duplicate logs unless their filters are exclusive.
- COLLECT rules run on the Broker VMs named in target_brokers before ingestion and convert altered logs to JSON, so they should not reshape analytics-supported vendors, while an EXTEND section runs right after the default rule whose full header and content_id it names.
- _time is mandatory in parsing and falls back to _insert_time when null or invalid, parse_cef turns a CEF string into an object with cef header keys plus extension keys, and the Simulate view tests user-defined rules against sample logs with a diff.
- Data Model Rules use XQLm with only alter, filter and call, a MODEL section names its dataset, ENUM fields should take XDM_CONST values such as XDM_CONST.IP_PROTOCOL_TCP, and XDM_ALIAS works only in XQL queries, never in modeling rules.
- Network stories need every mandatory network XDM field mapped or padded, including xdm.event.tags with EVENT_TAG_NETWORK, and missing authentication fields are handled Map, then Derive, then Pad, with xdm.source.ipv4 never padded.
- Correlation rules run in Real Time or on a schedule no more often than every 10 minutes (hourly by default), can suppress repeats for up to a day on chosen fields, can save results to a dataset or a lookup, and move between tenants by JSON export and import.
- Each correlation run is recorded in correlations_auditing, and a resources exceeded error is fixed by simplifying the query: drop unneeded fields, shorten the time frame, add a fields stage before heavy stages or split the rule.
- BIOC rules detect behaviors rather than hashes with queries that must filter on event_type and use only filter and alter stages on xdr_data or cloud_audit_log, they analyze historical data when created or enabled, and custom prevention rules attach only to Restrictions profiles you created.
- IOC rules cover full path, file name, domain, destination IP, MD5 and SHA256, but with the Threat Intel Management add-on File, Domain and IP Address detections belong in indicator rules, which act only on indicators already in TIM and prevent only on File indicators.
- When sources of equal reliability disagree the most recent value wins except for the verdict, where the worse verdict wins, and a manually set verdict is recalculated only after it is set to Unknown and the indicator is enriched again.
- Scoring rules can target hostnames, asset objects, IP addresses, users, and Active Directory or Azure groups and organizational units, where the group and OU basis requires the Cloud Identity Engine.
- Attack Surface Testing runs external unauthenticated tests at intrusivity levels 0 to 5 where a default level includes every lower level, its source IP range belongs on security tooling allow lists, and only an exact version match raises a CVE issue while a partial match creates a finding.
- System and content pack issue and case layouts are locked, so a duplicate is customized instead, layout rules are evaluated in order until one applies, and system tabs such as War Room and Work Plan can only be hidden.
- Custom issue field names and types cannot change after creation, a field-triggered script runs before the change is saved so it can validate the value, and timer fields act on expiry only through an attached script tagged SLA.
- Dashboard widget parameters are referenced with $ and multi-select filters need in(), table drilldowns use $row.<column>, report templates prefetch data with the scope of the user who last saved them, and new or imported dashboards and reports stay Restricted until shared.
Domain 4: Maintenance and Troubleshooting
- An issue exception rule takes effect only after approval within seven days and then creates matching issues marked Excepted with paused SLA timers, while an issue exclusion permanently stops matching issues from being saved without deleting the underlying logs.
- Applying an issue exclusion to historic issues cannot be undone, an exclusion can be built from a case with Create Exclusion to preview the matching issues, and exception rules need Exception Management Admin while approvers are managed with Exception Approver Admin.
- Exception Configuration groups Issue Exclusion, IOC/BIOC Suppression, Disable Injection and Prevention, Disable Prevention, Legacy Agent Exceptions and Support Exception rules, where Disable Injection and Prevention is a bypass of at most 48 hours and Disable Prevention requires agent 7.9 or later.
- Automation exclusion policies protect the critical assets in their lists from remediation commands wherever the commands run, are enabled or disabled rather than created, and allow an audited override-policy parameter only when overrides are permitted.
- Agent Upgrade Rollout is immediate or delayed by 7 to 45 days with scheduling windows, Content Rollout can be delayed up to 30 days, and a phased upgrade plan moves through batches of increasing risk before the final group.
- With all download sources selected agents fetch content from P2P peers, then a Broker VM, then the tenant, P2P needs UDP and TCP on port 33221 by default between agents in a subnet, and Global Content Management caps bandwidth using a calculator based on agent count.
- Standard endpoints upgrade from the server, but non-persistent VDI and temporary session agents are upgraded by reinstalling on the golden image, and automatic XDR Collector upgrades stay off until enabled in a Settings profile.
- Broker VM applets update independently of the broker, an HA cluster upgrades as a rolling upgrade only while its status is Healthy with at least two working nodes, and engines need an upgrade after a major Cortex XSIAM version or a tenant-engine protocol change.
- Health issues are queried from the alerts dataset with alert_domain = "DOMAIN_HEALTH", ingestion metrics are aggregated in 5-minute periods per source, and a scheduled correlation rule joining metrics_view with a lookup of expected devices raises a health issue for sources that go silent.
- Parsing failures are recorded in parsing_rules_errors, where data model rule errors always carry ERROR_CATEGORY Compile, and a dataset past its 2,000-field limit stops parsing until a fields stage in the INGEST section keeps only the needed fields.
- An oversized syslog warning often means logs lack end-of-line delimiters and merge together, an octet-framing warning means the length header is missing, and when Auto-Detect fails on the first two logs the collector treats the connection as RAW.
- Broker VM status messages point to the fix, such as adding disk when the caching disk passes 90 percent, and Broker VM logs are gathered with Generate New Logs before Download Logs becomes available.
- An engine that is not connected is checked with systemctl status d1, then d1.log and journalctl, a websocket bad handshake can mean clock drift fixed with NTP, and Python import errors mean the engine is not using Docker, fixed with python.engine.docker set to true in d1.conf.
- Agent status Partially protected means some modules or data collection are not running and Unprotected means protection is not enforced, and cytool runtime and cytool protect query or control agent components and protection locally.
- A Broker VM HA primary fails over automatically on lost tenant connectivity, applet or internal component failure, a full disk, or CPU or memory above 95 percent for more than 10 minutes, and a manual switchover starts from the Primary node on the Brokers or Clusters tab.
- Integration fetch debugging relies on the Troubleshooting Instances dashboard for command errors and on knowing that demisto.getLastRun() is empty from the CLI because it is stored only in the server-side fetch flow.
Palo Alto XSIAM Engineer exam tips
- Weight your time by the blueprint: Integration and Automation is the largest domain at 30 percent, so data source onboarding, feed and automation integrations, Marketplace content packs and playbook design deserve the deepest first pass, followed by the 24 percent Content Optimization and Maintenance and Troubleshooting domains and the 22 percent Planning and Installation domain.
- Practise writing Parsing Rules and Data Model Rules by hand, because the hardest Content Optimization items turn on section syntax, independent rule evaluation, COLLECT versus INGEST placement, XDM mandatory fields and the Map, Derive, Pad order.
- Build a numbers and ports sheet for the platform, including Broker VM and engine hardware, tenant FQDNs and IP address roles, syslog size limits and framing, P2P and agent proxy ports, upgrade rollout delays and HA failover triggers, and practise applying it to a scenario.
- Learn where each artifact lives and how it fails: health issues in the alerts dataset, ingestion metrics in metrics_view, parsing errors in parsing_rules_errors, correlation runs in correlations_auditing, and engine state in d1.conf, d1.log and journalctl.
- Separate look-alike controls before the exam: issue exceptions versus issue exclusions versus automation exclusion policies, IOC rules versus indicator rules versus BIOC rules, and listener versus pull applets in a Broker VM HA cluster.
Study guide FAQ
What does the XSIAM Engineer exam cover?
Four domains from the August 2025 datasheet: Planning and Installation (22%), covering infrastructure and deployment requirements, communication requirements, agents, Broker VM, engines and user roles; Integration and Automation (30%), covering data source onboarding, automation and feed integrations, Marketplace content packs and playbook workflows; Content Optimization (24%), covering parsing and data modeling rules, detection rules, layouts and dashboards; and Maintenance and Troubleshooting (24%), covering exceptions and exclusions, component updates and troubleshooting.
How does CertGrid practice map to the real exam?
The CertGrid bank holds 519 questions written to the four datasheet domains and weighted the same way: 115 in Planning and Installation, 161 in Integration and Automation, 130 in Content Optimization and 113 in Maintenance and Troubleshooting, with many scenario items built around parsing rules, playbook tasks, collector settings and troubleshooting evidence.
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 Integration and Automation at 30 percent, then cover Content Optimization and Maintenance and Troubleshooting at 24 percent each and Planning and Installation at 22 percent. Research the keywords of each blueprint task in the Cortex XSIAM documentation, complete the Palo Alto Networks learning path, and work hands-on with Broker VM applets, Parsing Rules, Data Model Rules, correlation rules and playbooks in a lab 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 - XSIAM Engineer datasheetBlueprint revised AUGUST 2025 · link and content verified 20 October 2026Four domains totalling 100%: Planning and Installation 22%, Integration and Automation 30%, Content Optimization 24%, Maintenance and Troubleshooting 24%; 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.