Domain 1: Planning and Installation
- The Cortex XDR agent installs on Windows, macOS, and Linux endpoints; installing the Linux agent requires root or an account with equivalent elevated privileges.
- A fresh install package performs a complete initial installation and registration for endpoints that have no existing agent; it does not migrate alert history between tenants.
- A platform-specific installation package bundles the installer, proxy configuration, and policy assignment, so tying it to an endpoint group and policy ensures endpoints receive the correct policy automatically; proxy settings can be embedded at build time or applied later through policy.
- Broker VM applets extend collection: the Windows Event Collector pulls or receives Windows event logs (via WinRM or Windows Event Forwarding) from hosts without an agent, the Syslog Collector listens over TCP or UDP for forwarded logs, and the Local Agent Settings applet caches agent content locally to cut redundant internet traffic.
- VMware ESXi is a supported virtualization platform for hosting the Broker VM; setup follows deploy the appliance, configure the network, then register.
- A registration token is a tenant-specific credential used to link a Broker VM to the correct Cortex XDR tenant.
- Cortex XDR Prevent delivers endpoint protection like next-generation antivirus and exploit prevention without the broader analytics and investigation tooling; sizing a Pro per Endpoint deployment is driven mainly by the total number of endpoints running the agent.
- Agents and brokers initiate outbound communication, so deployments generally need no inbound internet connections; with a Broker VM proxying traffic, typically only the broker itself needs outbound access to the cloud.
- Pre-deployment readiness checks confirm endpoints run a supported OS and that firewall and web gateway rules allow required outbound connections to the Cortex XDR cloud; a tenant provisioned in one region generally cannot be moved, so changing region means provisioning a new tenant.
- Cortex XDR can map identity provider groups to roles so role assignment reflects external IdP group membership.
Domain 2: Cortex XDR Agent Configuration
- Exploit protection targets technique-based abuse of legitimate processes (memory corruption, code-reuse chains, heap tampering, kernel privilege escalation), while malware protection evaluates files, hashes, and behavior for a malicious verdict.
- Administrators extend exploit protection by adding an application's process to the profile's protected process list, applying the configured modules to custom or line-of-business software.
- A policy rule assigns a specific exploit protection profile to a defined endpoint group, allowing different enforcement levels across the environment; a built-in default policy guarantees every endpoint always has settings applied.
- Best practice is to pilot a new exploit protection profile in Report mode before enforcing it broadly in Block mode, scoping the pilot with a higher-ranked, narrowly scoped rule.
- Rule rank resolves conflicts: an endpoint group can be referenced by several rules, and a pilot rule ranked below the production rule never applies to overlapping endpoints.
- Dynamic groups auto-track a broad, changing population (for example all macOS endpoints via an OS filter), while static groups fit small, fixed, manually curated membership; a name pattern filter targets endpoints by hostname format.
- A safe exception workflow investigates the triggering module and rule, verifies file reputation and signature, and checks whether an available content update already fixes the behavior before creating an exception.
- Exception scope matters: a folder-path exception exempts every file in that folder, while a hash exception exempts only one exact file, so prefer the narrower hash exception when possible.
- Disabling a module (for example Behavioral Threat Protection) stops it from detecting or blocking entirely, unlike Report mode which still logs findings.
- A quick scan targets commonly exploited, high-risk locations while a full scan covers the entire file system, the Executable scripts category covers interpreted languages such as PowerShell and VBScript, and content update scheduling controls when the agent checks for and applies new content.
Domain 3: Ingestion and Automation
- A Broker VM with the appropriate collection module gathers third-party logs and forwards them into Cortex XDR: the Syslog Collector receives forwarded server syslog, and the Windows Event Collector receives events via Windows Event Forwarding, both without an agent on the source.
- Each source format should be handled by its own collector instance configured for that specific format.
- Firewall (NGFW) logs reveal internal host-to-host traffic for lateral movement detection, so network activity for a host can be analyzed even without an agent installed on it.
- CloudTrail logs give visibility into AWS API calls and administrative activity, and Active Directory authentication logs enable identity analytics for detecting anomalous logon behavior.
- Creating an API key requires a name and an associated role; minimizing a key's permissions follows least privilege, for example scoping a reporting key to read-only so a leak cannot trigger isolation or config changes.
- Requests using an Advanced API key pass the numeric key identifier in the x-xdr-auth-id header alongside the Authorization header, and both values are required for verification.
- Custom datasets fill from continuous ingestion, while lookup datasets get their content from a manually uploaded file rather than an ongoing event stream.
- Event stitching combines related events from multiple sources into a single causality chain, and unmatched join results are most often caused by join key values not aligning exactly between the two datasets.
- The most direct way to confirm ingested events actually arrived is querying the target dataset with XQL over a recent time window; if none appear, first verify the source is sending to the correct Broker VM address and port.
- Email alerts fire when an incident matches a configured notification rule's criteria, and isolating an endpoint restricts its network communication while keeping the agent reachable for management.
Domain 4: Detection and Reporting
- BIOC rules match behavior on individual real-time events or causality chains, while correlation rules run scheduled XQL queries that can aggregate counts and join across multiple events and datasets over a time window.
- Correlating two distinct events, such as a file write followed by a registry change within a defined window, is a correlation rule use case that single-event BIOC logic cannot express.
- Custom BIOC rules are authored and maintained by the customer's detection engineers, whereas Analytics BIOC rules are written by Palo Alto Networks and delivered through content updates; both are rule-based and require no baseline.
- BIOC categories match by event type: a file rule matches path and extension, a process rule matches process name, command line, and parent process, and a registry rule matches activity like adding a value to an autorun key.
- A cryptographic file hash such as SHA256 is derived purely from file content, so it matches regardless of the file's name or location, unlike easily altered filename or path indicators.
- Indicator metadata aids triage: the class or category field labels the threat type, the source or vendor field records the indicator's origin, and expiration settings let stale indicators stop matching; teams add indicators in bulk via CSV upload or threat intel feed integration rather than one by one.
- Analytics depends on complete input data, so coverage validation confirms required sources (agent telemetry, firewall logs to Cortex Data Lake, and identity feeds) are actually flowing before Analytics can learn from them.
- Identity analytics uses Active Directory data to baseline user behavior and flag anomalies, such as unusual logon times or locations, or an interactive logon by a service account that normally authenticates silently.
- Scope exclusions quiet known benign sources of repeated false positives (for example a scanner or backup account) without disabling detection broadly.
- A drill-down query pulls supplementary event details tied to an already-triggered alert, and setting a dashboard as the default for a role makes it that role's landing view on login.
Domain 5: Maintenance and Troubleshooting
- Decommissioned endpoints left in the console keep consuming licensed endpoint capacity, so regular cleanup of stale records and uninstalling the agent are part of good license hygiene.
- In a proxy-restricted environment, the Broker VM's own proxy configuration must point at the proxy so it can reach the tenant, and even with correct firewall rules a broker that cannot resolve the tenant's FQDN through DNS will fail to connect.
- Significant clock drift on a Broker VM can break the TLS trust used to establish its secure tenant session, failing the connection even when the network path and firewall rules are fully correct.
- A connected agent stuck on old content points to a connectivity problem specifically with the content distribution servers, since basic check-in and content delivery can use different paths.
- Local content caching on the Broker VM and scheduled update windows both reduce redundant WAN traffic and avoid peak-hour contention at remote sites.
- Re-registering restores tenant identity and trust using the existing installation, which is faster and less disruptive than a full reinstall that replaces binaries and resets local configuration; end-of-life agent versions stop receiving new content updates over time.
- cytool is the local endpoint utility used to check the agent's runtime status, and checking a Broker VM applet locally first helps isolate whether an issue is at the broker or further along the path to the cloud.
- The Action Center provides an Agent Upgrade action for scheduled, targeted rollouts.
- Windows event retrieval requires reachable WinRM and sufficient read permissions on the target's event logs; a source-initiated subscription lets each machine push its own events rather than being individually polled.
- Console-level issues are investigated using tenant audit logs and exported configuration, and ingestion volume against the licensed allotment is tracked in the console's license or usage information; a disconnection pattern isolated to one network segment points to a network-side cause rather than a tenant-wide outage.
XDR-Engineer exam tips
- Master the difference between BIOC rules (single real-time events or causality chains) and correlation rules (scheduled XQL that aggregates and joins across datasets); this distinction is tested repeatedly.
- For any rollout question, reason through rule rank first: a lower-ranked rule never applies to endpoints already covered by a higher-ranked one, so pilots must be higher-ranked and narrowly scoped.
- When a scenario describes a broker or agent that cannot connect, walk the layered checklist in order: DNS resolution of the tenant FQDN, proxy configuration, firewall or outbound rules, and clock or NTP drift affecting TLS.
- Remember the least-scoped fix wins: prefer a narrow exception (specific hash) or scope exclusion over disabling a module or granting broad rights, and pilot in Report mode before Block.
- Know your data-source-to-detection mapping cold (firewall logs for lateral movement, AD auth logs for identity analytics, CloudTrail for AWS), because Analytics only works when its required sources are validated as flowing in.
Study guide FAQ
What is the passing score and format of the XDR Engineer exam?
The exam requires a scaled score of 700 to pass, runs 90 minutes, and covers five domains from planning and installation through maintenance and troubleshooting.
What is the difference between the Broker VM and the Cortex XDR agent?
The agent installs on individual Windows, macOS, and Linux endpoints for prevention and telemetry, while the Broker VM is an appliance that collects third-party data (syslog, Windows events) and can act as a local relay or content cache for agents in restricted networks.
When should I use a BIOC rule versus a correlation rule?
Use a BIOC rule to flag a specific malicious pattern the moment it occurs within a single event or causality chain, and use a correlation rule when you need to aggregate counts or join distinct events across multiple datasets over a time window.
How do I extend exploit protection to a custom application?
Add the application's process to the exploit protection profile's protected process list, which applies the profile's configured modules to that software beyond the default protected set.