Troubleshooting practice questions

While reviewing a compromised host in the Cortex XDR Incident Viewer, an analyst wants to isolate the endpoint from the network to prevent lateral movement while maintaining administrative access. Which response action should the analyst initiate?

Trap 1: Disable User

Disable User suspends the account's authentication, which does not sever the compromised host's existing network sessions, so lateral movement continues. It suits revoking a compromised identity's access, not containing an endpoint that must stay reachable for administrative remediation.

Trap 2: Kill Process Tree

Kill Process Tree terminates the malicious process and its children but leaves the endpoint's network interfaces active, so lateral movement is not prevented. It suits stopping active malicious execution, not isolating a host from the network while retaining administrative access.

Trap 3: Quarantine File

Quarantine File isolates a malicious file artefact on the endpoint, not the host's network connectivity, so lateral movement remains possible. It suits containing a known malicious binary pending analysis, not severing an infected host's network access while preserving administrative reach.

A
Disable User
Why it fails: Disable User suspends the account's authentication, which does not sever the compromised host's existing network sessions, so lateral movement continues. It suits revoking a compromised identity's access, not containing an endpoint that must stay reachable for administrative remediation.
B
Isolate Endpoint
Isolate Endpoint enforces a host-based network containment policy, blocking all traffic except the Cortex XDR management channel, so the analyst retains administrative control while lateral movement is prevented. This directly satisfies the stem's dual requirement: network isolation with preserved administrative access for investigation.
C
Kill Process Tree
Why it fails: Kill Process Tree terminates the malicious process and its children but leaves the endpoint's network interfaces active, so lateral movement is not prevented. It suits stopping active malicious execution, not isolating a host from the network while retaining administrative access.
D
Quarantine File
Why it fails: Quarantine File isolates a malicious file artefact on the endpoint, not the host's network connectivity, so lateral movement remains possible. It suits containing a known malicious binary pending analysis, not severing an infected host's network access while preserving administrative reach.

Read the full network assurance explanation →

Question 2hardmulti select

When deploying and troubleshooting the integration between Cortex XDR and Active Directory for ITDR, which TWO steps or configurations are critical to ensure successful telemetry collection? (Choose two)

Trap 1: Modifying the local BIOS boot order on every user workstation

Boot order firmware settings have no bearing on directory telemetry; ITDR reads authentication and directory-change events from domain controllers. BIOS changes are relevant when reimaging or booting alternate media, not when configuring log forwarding or audit policies. This step consumes change windows while collecting nothing.

Trap 2: Installing the full Cortex XDR Agent kernel driver directly on all…

ITDR telemetry comes from directory-service event logs and authentication traffic, not from kernel-level endpoint sensors on DNS infrastructure. Cortex XDR agents belong on workstations and servers generating process and network events. Installing a kernel driver on DNS root servers adds no AD telemetry and risks destabilising critical name resolution.

Trap 3: Disabling all firewall rules between endpoints and the Active…

ITDR collection depends on audit policy, directory-service logging and service-account permissions, not on SMB access to SYSVOL. Disabling firewall rules broadly weakens segmentation without enabling any telemetry channel. SYSVOL share access matters only for Group Policy processing, so this step addresses an unrelated requirement.

A
Modifying the local BIOS boot order on every user workstation
Why it fails: Boot order firmware settings have no bearing on directory telemetry; ITDR reads authentication and directory-change events from domain controllers. BIOS changes are relevant when reimaging or booting alternate media, not when configuring log forwarding or audit policies. This step consumes change windows while collecting nothing.
B
Configuring the Cortex XDR Broker VM to receive and parse syslog or Windows event streams from domain controllers
Domain controllers generate the security telemetry Cortex XDR needs, but it must be forwarded. The Broker VM acts as the collection and parsing intermediary, receiving syslog or Windows event streams, which is essential before ITDR analytics can consume that data.
C
Enabling advanced auditing policies (such as logon/logoff and account management auditing) on Domain Controllers
Advanced auditing policies determine whether logon, logoff and account management events are written to the Windows security log at all. Without them, domain controllers emit no relevant records, so the Broker VM has nothing to forward and ITDR telemetry stays empty.
D
Installing the full Cortex XDR Agent kernel driver directly on all DNS root servers
Why it fails: ITDR telemetry comes from directory-service event logs and authentication traffic, not from kernel-level endpoint sensors on DNS infrastructure. Cortex XDR agents belong on workstations and servers generating process and network events. Installing a kernel driver on DNS root servers adds no AD telemetry and risks destabilising critical name resolution.
E
Disabling all firewall rules between endpoints and the Active Directory SYSVOL share
Why it fails: ITDR collection depends on audit policy, directory-service logging and service-account permissions, not on SMB access to SYSVOL. Disabling firewall rules broadly weakens segmentation without enabling any telemetry channel. SYSVOL share access matters only for Group Policy processing, so this step addresses an unrelated requirement.

Question 3easymultiple choice

What is the primary function of the Cortex XDR Agent Support File collection tool?

Trap 1: To generate a forensic disk image of the entire hard drive

Support File collection bundles agent logs, configuration and diagnostics; it does not image a full disk. Forensic imaging is tempting because both aid investigations, yet imaging is performed with dedicated acquisition tools, not the agent's support utility.

Trap 2: To back up the user's personal documents to the cloud data lake

The tool gathers agent logs and diagnostic artefacts for support cases, not user documents. Cloud backup of personal files is tempting because Cortex XDR does forward telemetry to a cloud data lake, but that pipeline carries endpoint security events, not document backups.

Trap 3: To export endpoint cryptographic keys to an external vault

The utility collects diagnostic logs and configuration for troubleshooting, not cryptographic material. Exporting keys is tempting because the agent manages certificates and secrets locally, but key escrow is handled by dedicated vault or PKI tooling, not support file collection.

A
To collect diagnostic logs, configuration details, and troubleshooting data for Palo Alto Networks Support
The Cortex XDR Agent Support File collection tool gathers agent diagnostic logs, configuration state and troubleshooting artefacts into a bundle for Palo Alto Networks Support. This directly satisfies the stem's requirement for a support-facing collection function rather than endpoint remediation or policy enforcement.
B
To generate a forensic disk image of the entire hard drive
Why it fails: Support File collection bundles agent logs, configuration and diagnostics; it does not image a full disk. Forensic imaging is tempting because both aid investigations, yet imaging is performed with dedicated acquisition tools, not the agent's support utility.
C
To back up the user's personal documents to the cloud data lake
Why it fails: The tool gathers agent logs and diagnostic artefacts for support cases, not user documents. Cloud backup of personal files is tempting because Cortex XDR does forward telemetry to a cloud data lake, but that pipeline carries endpoint security events, not document backups.
D
To export endpoint cryptographic keys to an external vault
Why it fails: The utility collects diagnostic logs and configuration for troubleshooting, not cryptographic material. Exporting keys is tempting because the agent manages certificates and secrets locally, but key escrow is handled by dedicated vault or PKI tooling, not support file collection.

Question 4hardmulti select

An administrator is troubleshooting a failed Cortex XDR agent installation on a Windows endpoint. Which THREE log locations or troubleshooting methods should the administrator examine to determine the root cause of the installation failure?

Trap 1: The BIOS firmware boot order configuration screen

BIOS boot order governs which device firmware hands control to at startup; it holds no records of MSI installer failures or agent service errors. It is examined when a machine boots from the wrong disk, not when diagnosing Cortex XDR installation faults.

Trap 2: The local router routing table via the arp -a command

The ARP cache and routing table reveal nothing about why the Cortex XDR installer failed; they show layer-2 and layer-3 neighbour mappings. The arp command is used to diagnose connectivity or duplicate-IP issues, so it would be relevant when the endpoint cannot reach the management server, not when installation itself aborts.

A
The Windows System and Application Event Logs for MSIInstaller or service creation errors
Windows Installer writes MSIInstaller events and service-creation failures to the System and Application logs. These record the actual MSI error code and service registration faults, giving the root cause of a failed Cortex XDR agent installation rather than generic network or policy symptoms.
B
The agent installation log files located in the Windows %TEMP% directory or Cyvera installation logs
The installer writes detailed MSI and Cyvera logs to %TEMP% during Cortex XDR agent deployment, recording prerequisite failures, permission errors and service registration issues. Examining these satisfies the requirement to determine the root cause of the installation failure.
C
The Windows Installer verbose log generated during the installation process (e.g., using msiexec /i installer.msi /l*v install.log)
The MSI verbose log, produced via msiexec with /l*v, records each installation action and error code, exposing the precise failure cause. This satisfies the stem's requirement to determine the root cause of the Cortex XDR agent installation failure on Windows.
D
The BIOS firmware boot order configuration screen
Why it fails: BIOS boot order governs which device firmware hands control to at startup; it holds no records of MSI installer failures or agent service errors. It is examined when a machine boots from the wrong disk, not when diagnosing Cortex XDR installation faults.
E
The local router routing table via the arp -a command
Why it fails: The ARP cache and routing table reveal nothing about why the Cortex XDR installer failed; they show layer-2 and layer-3 neighbour mappings. The arp command is used to diagnose connectivity or duplicate-IP issues, so it would be relevant when the endpoint cannot reach the management server, not when installation itself aborts.

Question 5hardmultiple choice

An administrator configures a custom data stitching rule to correlate custom application logs with endpoint events. After deployment, no new incidents are formed from these logs. What is the most critical factor to verify when troubleshooting custom stitching rules?

Trap 1: That featured fields are enabled for the custom schema

Featured fields must be populated for stitching to match events; without them the rule never correlates. Enabling featured fields is genuinely required when defining a custom schema's searchable columns, so it is tempting, but the failure here is that no incidents form at all, which points to the stitching query or connector rather than field enablement.

Trap 2: That the incident score is locked at maximum

Incident scores are calculated from correlated alerts; locking a score at maximum does not create incidents and no such setting governs stitching. Score locking is used to prevent automatic severity changes on an existing incident, so it is tempting when tuning triage, but it cannot explain why no incidents form from the custom logs.

Trap 3: That all incoming custom logs are starred by default

Starring logs marks them for analyst attention; it neither triggers correlation nor creates incidents. Starring is genuinely useful for flagging notable events during investigation, which makes it tempting, but the absence of incidents stems from the stitching rule failing to match custom schema fields to endpoint events.

A
That featured fields are enabled for the custom schema
Why it fails: Featured fields must be populated for stitching to match events; without them the rule never correlates. Enabling featured fields is genuinely required when defining a custom schema's searchable columns, so it is tempting, but the failure here is that no incidents form at all, which points to the stitching query or connector rather than field enablement.
B
That the incident score is locked at maximum
Why it fails: Incident scores are calculated from correlated alerts; locking a score at maximum does not create incidents and no such setting governs stitching. Score locking is used to prevent automatic severity changes on an existing incident, so it is tempting when tuning triage, but it cannot explain why no incidents form from the custom logs.
C
That all incoming custom logs are starred by default
Why it fails: Starring logs marks them for analyst attention; it neither triggers correlation nor creates incidents. Starring is genuinely useful for flagging notable events during investigation, which makes it tempting, but the absence of incidents stems from the stitching rule failing to match custom schema fields to endpoint events.
D
That the custom log fields correctly map to shared schema identifiers like user or IP
Custom stitching rules only correlate logs when their fields resolve to shared schema identifiers such as user, IP or device. If mappings are absent or incorrect, the rule produces no matches, so no incidents form. Verifying field-to-schema mapping directly addresses the missing-incident symptom.