Cortex XDR Analyst Exam: Seven XQL Queries to Write Before You Book It

The Palo Alto Networks XDR Analyst exam gives 28% of its score to Data Analysis, and most of that domain is Cortex Query Language (XQL). If you can write a query that filters xdr_data, aggregates it, buckets it by time and joins it to a lookup table, you have covered the part of the exam that rewards hands-on practice most directly.

This post walks through seven queries in the order you would build them during a real investigation. Each one is short, uses only stages and fields from Palo Alto's own documentation, and maps to a numbered task in the exam blueprint.

What does the XDR Analyst exam cover?

The certification checks that you can run a Cortex XDR console as a SOC analyst: triage alerts, investigate incidents, query data and manage endpoint policy. It sits at the Specialist level in the Security Operations track, according to the XDR Analyst certification page.

You book the exam through Pearson VUE, and Palo Alto delivers it in English worldwide. The blueprint is short enough to print on one page, and every task in it is numbered, which makes it easy to tick off as you study.

The four domains and their weights come from the XDR Analyst datasheet (August 2025 edition, read on 15 October 2026):

The datasheet also lists "Basic understanding of programming and scripting languages (i.e., Python, PowerShell, SQL, XQL)" among the required skills. So XQL is named twice: once as a skill and once as a scored domain.

How is an XQL query put together?

An XQL query starts with a data source and then passes the records through stages separated by a pipe (|). The page on XQL language structure states that xdr_data is the default dataset, that dataset = queries hot storage and cold_dataset = queries cold storage, and that results come back in no fixed order unless you sort them.

Three rules save you from slow or confusing queries:

• config must be the very first stage when you use it. config timeframe = 7d pins the time range inside the query text instead of relying on the time picker.
• Without a limit, a query can return up to 1,000,000 rows. Filter early and pick only the fields you need.
• Field values are matched case-insensitively by default. config case_sensitive = true turns that off.

The field names below are all listed on the xdr_data field reference. event_type is an integer there: 1 is Process, 2 is Network, 3 is File and 4 is Registry.

Query 1: Which processes ran on a host?

Start with the plainest possible query: process events from the last day, newest first, with only the columns an analyst reads.

config timeframe = 1d
| dataset = xdr_data
| filter event_type = 1 // Process
    and agent_hostname = "fin-ws-042"
| fields _time, agent_hostname, actor_process_image_name,
         action_process_image_name, action_process_image_command_line
| sort desc _time
| limit 200

actor_process_image_name is the parent that launched the process, and action_process_image_name is the process that was launched. Knowing which side is the actor and which is the action is the base of every causality question in Domain 2.

Query 2: Did an Office application start PowerShell?

This is the classic first hunt. The in operator keeps the filter short, and case does not matter because XQL matches values case-insensitively by default.

config timeframe = 7d
| dataset = xdr_data
| filter event_type = 1
    and action_process_image_name in ("powershell.exe", "pwsh.exe")
    and actor_process_image_name in ("winword.exe", "excel.exe", "outlook.exe")
| fields _time, agent_hostname, actor_process_image_name,
         action_process_image_command_line, causality_actor_process_image_name
| sort desc _time

causality_actor_process_image_name shows the process at the root of the chain, which is what the Causality view in the console draws. If the root is outlook.exe and the child is PowerShell with an encoded command line, you have an incident to open.

Query 3: Which binaries are rare across the fleet?

Rare executables are a cheap lead for IOC hunting (blueprint task 3.5). Group by hash, count the hosts that ran each one, and keep the ones seen on one or two machines.

config timeframe = 7d
| dataset = xdr_data
| filter event_type = 1 and action_process_image_sha256 != null
| comp count_distinct(agent_hostname) as host_count,
       min(_time) as first_seen
       by action_process_image_sha256, action_process_image_name
| filter host_count <= 2
| sort asc host_count
| limit 100

The comp stage reference notes that comp is a blocking stage: it reads every input record before it returns anything, and it drops every field that is not an aggregate or a group key. That is why first_seen has to be computed inside comp and cannot be picked up afterwards.

Query 4: When did a host start talking to the internet?

Network events (event_type = 2) with a public destination, bucketed per hour, show beaconing and data-transfer spikes at a glance.

config timeframe = 2d
| dataset = xdr_data
| filter event_type = 2
    and action_remote_ip not incidr "10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16"
| bin _time span = 1h
| comp count(action_remote_ip) as connections by _time, agent_hostname
| sort desc connections
| limit 50

bin must come before comp when you group by time, otherwise every event keeps its own timestamp and the counts are all 1. A host that makes almost the same number of connections every hour, around the clock, is worth a second look.

Query 5: When did each host first run a tool?

dedup keeps one record per value. With by asc _time it keeps the earliest one, which gives you a first-seen list per host for a tool such as PsExec.

config timeframe = 30d
| dataset = xdr_data
| filter event_type = 1 and action_process_image_name = "psexec.exe"
| fields _time, agent_hostname, action_process_image_command_line
| dedup agent_hostname by asc _time
| sort asc _time

Palo Alto warns that dedup can be expensive on a dataset as large as xdr_data, so filter and trim fields before it, as this query does. The output reads like a lateral-movement timeline: which machine ran the tool first and in what order it spread.

Query 6: Which alerts hit high-value assets?

Lookup tables are blueprint task 3.4. A lookup is a small dataset of name-value pairs that you upload as CSV, TSV or JSON, or write from a query. The lookup datasets page lists high-value assets, terminated employees and service accounts as typical uses, and it caps edits at 1,200 changes a day.

Say you uploaded a lookup called hva_hosts with the columns hostname and owner. An inner join keeps only the events from those hosts:

config timeframe = 1d
| dataset = xdr_data
| filter event_type = 1
| fields _time, agent_hostname, action_process_image_name, action_process_image_command_line
| join type = inner (
    dataset = hva_hosts
    | fields hostname, owner
) as hva hva.hostname = agent_hostname
| sort desc _time

The join stage reference gives the defaults worth memorising: the join type is inner unless you say otherwise, a column name that exists on both sides takes the right side's value (conflict_strategy = right), and the join does not keep any earlier sort order. That last point is why sort comes after join here.

Query 7: Does any process match a list of IOC hashes?

You do not always need a join. A subquery inside filter ... in (...) is shorter when the lookup only supplies values to match. With a lookup called ioc_hashes that holds one column, sha256:

config timeframe = 30d
| dataset = xdr_data
| filter event_type = 1
    and action_process_image_sha256 in (
        dataset = ioc_hashes
        | fields sha256
    )
| fields _time, agent_hostname, action_process_image_name, action_process_image_sha256
| sort desc _time

Save it to your personal Query Library, then turn it into a scheduled query so it runs every few hours without you. Query Library and Schedule Query are both named in blueprint task 3.3, so it pays to have clicked through both screens in a lab tenant.

What should you study besides XQL?

XQL covers about a quarter of the score. The other 72% is console work, and a lab tenant is the only real way to learn it:

1. Domain 2 (34%). Open an incident, follow the causality chain, read the timeline, and run the main response actions at least once: isolate an endpoint, open a Live Terminal session, remediate changes from malicious activity. Then add an exclusion and an exception and note how they differ.
2. Domain 1 (23%). Learn how incident scoring and alert starring change the order of the incident list, and how alerts are grouped into one incident.
3. Domain 4 (15%). Compare the prevention profiles (malware, exploit) with the extension profiles, and look at what a disconnected or outdated agent shows in the endpoint list.

The NWExam XDR Analyst syllabus page lists every blueprint task on one screen, which makes a handy checklist while you work through the lab.

The short video below from the NWExam channel gives a two-minute overview of how to plan your preparation for this certification.

How much does it cost, and what score do you need?

The exam costs USD 250, the price Palo Alto charges for every Specialist-level exam in its certification FAQ (September 2026). Taxes can add to that depending on the country.

The passing score and the scaled-score method are explained in the Palo Alto Networks certification handbook. Palo Alto does not publish a question count or exam length for XDR Analyst in the datasheet, the FAQ or the handbook, so check the figure on your Pearson VUE booking screen before exam day.

Frequently asked questions

1. How much of the XDR Analyst exam is about XQL?

Data Analysis carries 28% of the score, and five of its eight tasks are about XQL: syntax and schema, data sources, query options such as the Query Library and scheduled queries, lookup tables, and hunting for indicators of compromise.

2. What is the passing score for the Palo Alto XDR Analyst exam?

Palo Alto converts every exam to a scale of 300 to 1000, and the passing score is 860 for all of its certification exams. The raw cut score behind it can change from one exam form to the next to account for difficulty.

3. How much does the XDR Analyst exam cost?

USD 250. Palo Alto prices all Specialist-level exams at that figure, and local taxes or fees may be added in some countries.

4. Can I retake the exam right away if I fail?

No. You must wait 15 days before a second attempt, 30 days before a third and 90 days before any later attempt.

5. How long does the XDR Analyst certification stay valid?

Two years from the day you pass. To keep it active you pass the exam again; earning a higher certification in the same track also renews it.

6. Do I need to know Python or SQL for the exam?

The datasheet asks for a basic understanding of Python, PowerShell, SQL and XQL. SQL habits carry over well to XQL, but the pipe-based stage order (filter, then comp, then sort) is the part to practise.

Written by the team behind NWExam, a practice-test site for networking and security certifications. We are not affiliated with Palo Alto Networks.