Troubleshooting practice questions

A Cortex XSIAM administrator notices that an ASM scan completed successfully but a known external web application was not listed in the results. The application is reachable from the internet and is owned by the organization. Which troubleshooting step is most appropriate to determine why the asset was missed?

Trap 1: Re-run the entire discovery configuration from scratch to force a…

Re-running discovery without first identifying why the asset was excluded wastes time and is likely to produce the same omission if the asset lies outside the seed scope. It treats the symptom rather than the cause and does not provide any diagnostic information about coverage gaps.

Trap 2: Add the web application to the asset inventory manually so it…

Manually adding the asset masks the underlying discovery gap and means future changes to that asset or its siblings will also be missed. It produces a report entry without validating whether seeds or scan scope are correct, which is the actual diagnostic question the administrator needs to answer.

Trap 3: Increase the scan's request rate to ensure the web application…

Raising request rate can improve throughput but also increases the chance of rate limiting or blocking by the target. It assumes the miss was caused by timing, which is only one of several possibilities, and it does not verify whether the asset was ever in scope, so it may leave the real coverage gap unresolved.

A
Re-run the entire discovery configuration from scratch to force a fresh enumeration of all seeds
Why it fails: Re-running discovery without first identifying why the asset was excluded wastes time and is likely to produce the same omission if the asset lies outside the seed scope. It treats the symptom rather than the cause and does not provide any diagnostic information about coverage gaps.
B
Verify that the asset's hostname or address falls within the configured discovery seeds and that the relevant ports are included in the scan scope
ASM only enumerates assets that fall within configured seeds and ports that are in scope. If the hostname is outside the seed set, or the service listens on a port the scan does not probe, the asset will not appear even though it is reachable. Checking seed coverage and port scope is the most direct way to explain a missed asset.
C
Add the web application to the asset inventory manually so it appears in ASM reports going forward
Why it fails: Manually adding the asset masks the underlying discovery gap and means future changes to that asset or its siblings will also be missed. It produces a report entry without validating whether seeds or scan scope are correct, which is the actual diagnostic question the administrator needs to answer.
D
Increase the scan's request rate to ensure the web application responds before the scan times out
Why it fails: Raising request rate can improve throughput but also increases the chance of rate limiting or blocking by the target. It assumes the miss was caused by timing, which is only one of several possibilities, and it does not verify whether the asset was ever in scope, so it may leave the real coverage gap unresolved.

Read the full Ansible explanation →

Question 2hardmultiple choice

While troubleshooting a failed custom automation script inside a playbook, you notice that the script returned a non-standard error object. Where should you look first within XSIAM to inspect the raw inputs and outputs passed to the automation?

Trap 1: Data Hub > Query Service

Incorrect. The Query Service is for querying log data, not debugging active playbook script memory states.

Trap 2: Settings > Integrations > Instances logs

Incorrect. Integration instance logs show connection health, not specific playbook task execution runs.

Trap 3: Incidents > Audit Trail

Incorrect. The audit trail shows incident-level state changes, not granular script variable inputs/outputs.

A
Data Hub > Query Service
Why it fails: Incorrect. The Query Service is for querying log data, not debugging active playbook script memory states.
B
Settings > Integrations > Instances logs
Why it fails: Incorrect. Integration instance logs show connection health, not specific playbook task execution runs.
C
Incidents > Audit Trail
Why it fails: Incorrect. The audit trail shows incident-level state changes, not granular script variable inputs/outputs.
D
Playbooks > Execution History > Task Details
Correct. Task Details within the playbook execution view display the exact inputs, raw outputs, and error messages for that specific run.

Question 3mediummultiple choice

You are troubleshooting an Attack Surface Management (ASM) scan in XSIAM where external IP ranges belonging to a newly acquired subsidiary are not showing up in the asset inventory. What is the most likely reason for this discrepancy?

Trap 1: Threat intelligence feeds have disabled automatic asset correlation…

Threat intelligence feeds enrich existing assets with indicators; they do not govern ASM discovery or correlation of external ranges. It tempts because feeds are integral to XSIAM and their configuration can affect detections, but the missing subsidiary ranges reflect scan scope, not feed-driven correlation settings.

Trap 2: The Log Forwarder agent is not installed on the subsidiary endpoints

Log Forwarder agents collect endpoint telemetry for detection, not external attack surface discovery; ASM scans internet-facing ranges without agents. It tempts because missing subsidiary data often stems from uninstalled forwarders, but that applies to endpoint logs, not external IP inventory.

Trap 3: The ingestion service for ASM requires manual CSV asset mapping…

ASM discovers external ranges by scanning them directly, so no manual CSV asset mapping is required; discovery precedes inventory population. It tempts because manual asset import exists for internal or on-premises assets, but newly acquired external IP ranges are found automatically once configured in the scan scope.

A
Threat intelligence feeds have disabled automatic asset correlation by default
Why it fails: Threat intelligence feeds enrich existing assets with indicators; they do not govern ASM discovery or correlation of external ranges. It tempts because feeds are integral to XSIAM and their configuration can affect detections, but the missing subsidiary ranges reflect scan scope, not feed-driven correlation settings.
B
The Log Forwarder agent is not installed on the subsidiary endpoints
Why it fails: Log Forwarder agents collect endpoint telemetry for detection, not external attack surface discovery; ASM scans internet-facing ranges without agents. It tempts because missing subsidiary data often stems from uninstalled forwarders, but that applies to endpoint logs, not external IP inventory.
C
The ingestion service for ASM requires manual CSV asset mapping before discovery runs
Why it fails: ASM discovers external ranges by scanning them directly, so no manual CSV asset mapping is required; discovery precedes inventory population. It tempts because manual asset import exists for internal or on-premises assets, but newly acquired external IP ranges are found automatically once configured in the scan scope.
D
The seed domains or IP ranges for the subsidiary have not been added to the ASM configuration scope
ASM only discovers and scans assets within its configured seed domains and IP ranges. Newly acquired subsidiary ranges absent from that scope are never enumerated, so they cannot appear in the asset inventory regardless of scan health.

Question 4hardmulti select

An administrator is troubleshooting an endpoint where the Cortex XDR agent is failing to connect to the XSIAM tenant through a corporate proxy server. Which THREE proxy configuration parameters must be correctly supplied to the agent installation or policy to ensure successful connectivity? (Choose three)

Trap 1: Primary domain controller NetBIOS name

The NetBIOS name identifies a Windows domain controller for legacy name resolution; it plays no part in proxy authentication or traversal. It is tempting because it is a real Windows networking value, and would be correct when joining a host to a domain rather than configuring an agent's proxy connection.

Trap 2: Local BGP autonomous system number (ASN)

BGP ASN is a routing protocol identifier exchanged between autonomous systems; the agent never uses it to reach a proxy. It is tempting because it is a genuine network parameter, and would be correct when configuring dynamic routing between network segments rather than endpoint proxy traversal.

A
Proxy authentication credentials (username and password) if required
Where the proxy demands authentication, the agent must present valid credentials to complete the CONNECT request. Supplying them satisfies the stem, as an unauthenticated agent is rejected by the proxy even when the address and port are correct.
B
Proxy server IP address or Fully Qualified Domain Name (FQDN)
The proxy's IP address or FQDN identifies the host the agent must route tenant traffic through. Supplying it satisfies the stem's connectivity requirement, since the agent cannot reach the XSIAM tenant via the proxy without resolving its address.
C
Primary domain controller NetBIOS name
Why it fails: The NetBIOS name identifies a Windows domain controller for legacy name resolution; it plays no part in proxy authentication or traversal. It is tempting because it is a real Windows networking value, and would be correct when joining a host to a domain rather than configuring an agent's proxy connection.
D
Proxy server TCP port number
The proxy's TCP port is the listening port the agent must target for outbound connections. Supplying it satisfies the stem's connectivity requirement, since an agent given only the proxy hostname cannot establish a session on the wrong port.
E
Local BGP autonomous system number (ASN)
Why it fails: BGP ASN is a routing protocol identifier exchanged between autonomous systems; the agent never uses it to reach a proxy. It is tempting because it is a genuine network parameter, and would be correct when configuring dynamic routing between network segments rather than endpoint proxy traversal.

Question 5hardmultiple choice

An analyst is investigating a Linux server where the Cortex XDR agent is installed but has not reported any events for several hours. The analyst confirms the agent process is running and the server has network connectivity. Which XSIAM feature should the analyst use first to verify whether the agent is properly registered and communicating with the tenant?

Trap 1: Agent Installations page, verifying the installation package used…

The Agent Installations page manages installation packages and deployment, not live endpoint status. It would not show whether the agent is currently communicating. Checking the package does not help diagnose a live connectivity problem; the analyst needs real-time endpoint status, which is found in Endpoint Management.

Trap 2: Incident Response view, searching for the endpoint's IP address to…

The Incident Response view shows alerts and incidents, not raw agent connectivity status. While it may indicate past activity, it does not provide real-time check-in information or registration status. Absence of alerts does not confirm the agent is offline, so this view is not the right first step to diagnose communication issues.

Trap 3: Threat Intelligence module, checking for any indicators associated…

Threat Intelligence focuses on external threat indicators and does not report endpoint agent health. It cannot confirm registration or last check-in time. Using it here would not address the agent communication issue; the analyst should instead look at endpoint status information in Endpoint Management.

A
Endpoint Management page, filtering by the endpoint's hostname to view its status and last check-in time.
The Endpoint Management page in XSIAM displays all registered endpoints with their current status, last check-in time, and agent version. Filtering by hostname allows the analyst to quickly confirm whether the agent is registered, online, and reporting. If the last check-in is stale, the issue is likely agent-server communication, and further troubleshooting can proceed from there.
B
Agent Installations page, verifying the installation package used for this server.
Why it fails: The Agent Installations page manages installation packages and deployment, not live endpoint status. It would not show whether the agent is currently communicating. Checking the package does not help diagnose a live connectivity problem; the analyst needs real-time endpoint status, which is found in Endpoint Management.
C
Incident Response view, searching for the endpoint's IP address to see if any alerts were generated.
Why it fails: The Incident Response view shows alerts and incidents, not raw agent connectivity status. While it may indicate past activity, it does not provide real-time check-in information or registration status. Absence of alerts does not confirm the agent is offline, so this view is not the right first step to diagnose communication issues.
D
Threat Intelligence module, checking for any indicators associated with the server.
Why it fails: Threat Intelligence focuses on external threat indicators and does not report endpoint agent health. It cannot confirm registration or last check-in time. Using it here would not address the agent communication issue; the analyst should instead look at endpoint status information in Endpoint Management.

Question 6hardmulti select

An administrator is troubleshooting a Windows endpoint where the Cortex XDR agent installed successfully but the endpoint never appears in the XSIAM Endpoints inventory. The endpoint has internet access. Which two conditions should the administrator verify to resolve the missing registration? (Choose two.)

Trap 1: Check whether the endpoint is assigned to a different endpoint…

Group assignment and policy conflicts affect behavior after an endpoint is known to the tenant; they presuppose the endpoint already appears in inventory. A never-registered endpoint has no group assignment to conflict with. Investigating group policy here addresses a later-stage configuration concern rather than the missing registration itself.

Trap 2: Confirm the endpoint has a valid, activated license for the…

Licensing governs which protection capabilities are enabled and reported, not whether an agent can appear in inventory at all. An unlicensed or partially licensed endpoint still registers and shows up, often flagged for missing modules. Focusing on license state diverts attention from the enrollment and connectivity faults that actually prevent registration.

Trap 3: Ensure the endpoint's operating system build is newer than the…

Operating system compatibility affects whether the agent installs and runs, but this endpoint already installed successfully, so the OS version is evidently acceptable. Checking it again does not explain a clean installation that simply fails to register. The problem lies in enrollment credentials or network reachability, not OS support level.

A
Check whether the endpoint is assigned to a different endpoint group with a conflicting policy.
Why it fails: Group assignment and policy conflicts affect behavior after an endpoint is known to the tenant; they presuppose the endpoint already appears in inventory. A never-registered endpoint has no group assignment to conflict with. Investigating group policy here addresses a later-stage configuration concern rather than the missing registration itself.
B
Confirm the endpoint has a valid, activated license for the endpoint protection module.
Why it fails: Licensing governs which protection capabilities are enabled and reported, not whether an agent can appear in inventory at all. An unlicensed or partially licensed endpoint still registers and shows up, often flagged for missing modules. Focusing on license state diverts attention from the enrollment and connectivity faults that actually prevent registration.
C
Ensure the endpoint's operating system build is newer than the agent's minimum supported version.
Why it fails: Operating system compatibility affects whether the agent installs and runs, but this endpoint already installed successfully, so the OS version is evidently acceptable. Checking it again does not explain a clean installation that simply fails to register. The problem lies in enrollment credentials or network reachability, not OS support level.
D
Verify outbound connectivity to the required XSIAM service endpoints and ports is permitted by the firewall and proxy.
Registration requires the agent to reach specific tenant service hostnames and ports. If a firewall or proxy blocks those destinations, the agent installs but its enrollment call fails silently, leaving the endpoint absent from the console. Confirming allowed egress, including proxy authentication, is essential to complete registration.
E
Confirm the agent installation package contains the correct tenant identifier and registration credentials.
The agent must be built with the tenant's identifier and enrollment credentials to register with the correct XSIAM instance. A package generated for a different tenant, or one whose registration token has expired, installs cleanly but cannot authenticate, so the endpoint never appears in inventory. Verifying these values is a fundamental first check.

Question 7hardmulti select

An administrator is troubleshooting a Windows endpoint where the Cortex XDR agent fails to start after a system update. The administrator needs to collect diagnostic information to determine the cause. Which two actions can be performed from the XSIAM management console to assist with this troubleshooting? (Choose two.)

Trap 1: Run a remote script on the endpoint to check the Windows Event Log…

Running remote scripts is a feature of Cortex XDR, but it is not performed directly from the Endpoint Management page for diagnostic purposes in this context. While possible via the Live Terminal or Action Center, the question specifies actions from the management console to assist troubleshooting; retrieving logs and checking status are the standard diagnostic actions available directly.

Trap 2: Initiate a remote agent upgrade to the latest version from the…

A remote agent upgrade might resolve issues if the failure is due to a bug fixed in a newer version, but it is not a diagnostic action. The administrator first needs to understand the cause. Upgrading without diagnosis could worsen the problem or fail if the agent cannot start. This action is not primarily for collecting diagnostic information.

Trap 3: Reset the agent's registration by generating a new installation…

Reinstalling the agent is a remediation step, not a diagnostic one. It does not help determine why the agent failed to start and may disrupt the endpoint further. The administrator should first collect logs and status to diagnose the root cause before considering reinstallation.

A
Run a remote script on the endpoint to check the Windows Event Log for agent-related errors.
Why it fails: Running remote scripts is a feature of Cortex XDR, but it is not performed directly from the Endpoint Management page for diagnostic purposes in this context. While possible via the Live Terminal or Action Center, the question specifies actions from the management console to assist troubleshooting; retrieving logs and checking status are the standard diagnostic actions available directly.
B
View the agent's operational status and last check-in time in the Endpoint Management page.
The Endpoint Management page shows the agent's current status, including whether it is running, stopped, or failed to start, along with the last check-in time. This information helps determine if the agent is completely down or intermittently failing. Combined with other data, it guides further troubleshooting steps.
C
Initiate a remote agent upgrade to the latest version from the Endpoint Management page.
Why it fails: A remote agent upgrade might resolve issues if the failure is due to a bug fixed in a newer version, but it is not a diagnostic action. The administrator first needs to understand the cause. Upgrading without diagnosis could worsen the problem or fail if the agent cannot start. This action is not primarily for collecting diagnostic information.
D
Retrieve the agent diagnostic logs from the endpoint via the Endpoint Management page.
The Endpoint Management page allows administrators to request and download agent diagnostic logs remotely. These logs contain detailed information about agent startup, errors, and communication issues. In this scenario, retrieving the logs would provide insight into why the agent fails to start after the system update, enabling targeted remediation without requiring local access.
E
Reset the agent's registration by generating a new installation package and reinstalling.
Why it fails: Reinstalling the agent is a remediation step, not a diagnostic one. It does not help determine why the agent failed to start and may disrupt the endpoint further. The administrator should first collect logs and status to diagnose the root cause before considering reinstallation.

Question 8hardmultiple choice

An analyst is troubleshooting a correlation rule that is failing to trigger incidents despite matching raw logs. Where can the analyst test and debug the rule logic against historical or sample log data in XSIAM?

Trap 1: Endpoint isolation diagnostics log

Endpoint isolation diagnostics records agent containment activity, not rule evaluation, so it cannot replay logs against correlation logic. It is tempting because it is a troubleshooting view, but rule testing against historical or sample data belongs in the XSIAM correlation rule test interface.

Trap 2: Playbook task debugger console

The playbook task debugger executes and traces playbook tasks, not correlation rule logic, so it cannot show why a rule fails to match logs. It is tempting as a debugging tool, but playbooks run after incidents are generated, whereas rule testing occurs beforehand.

Trap 3: Agent diagnostic package utility

The agent diagnostic package collects endpoint logs for support, not rule logic testing. It tempts because diagnostics sound like debugging, but correlation rule testing against historical or sample logs happens in the rule editor's test function, which evaluates logic directly rather than gathering agent telemetry.

A
Endpoint isolation diagnostics log
Why it fails: Endpoint isolation diagnostics records agent containment activity, not rule evaluation, so it cannot replay logs against correlation logic. It is tempting because it is a troubleshooting view, but rule testing against historical or sample data belongs in the XSIAM correlation rule test interface.
B
Playbook task debugger console
Why it fails: The playbook task debugger executes and traces playbook tasks, not correlation rule logic, so it cannot show why a rule fails to match logs. It is tempting as a debugging tool, but playbooks run after incidents are generated, whereas rule testing occurs beforehand.
C
Agent diagnostic package utility
Why it fails: The agent diagnostic package collects endpoint logs for support, not rule logic testing. It tempts because diagnostics sound like debugging, but correlation rule testing against historical or sample logs happens in the rule editor's test function, which evaluates logic directly rather than gathering agent telemetry.
D
Correlation Rule Editor test and simulation panel
The Correlation Rule Editor's test and simulation panel evaluates rule logic against historical or sample logs without generating live incidents, directly satisfying the stem's requirement to debug why matching raw logs fail to trigger. It exposes each condition's evaluation, revealing the faulty clause, whereas live monitoring alone cannot isolate logic errors.

Read the full network assurance explanation →

Question 9hardmultiple choice

An analyst observes that a specific endpoint has stopped generating endpoint telemetry events (such as process execution and file creation logs) into XSIAM, although the endpoint is powered on and connected to the corporate network. Upon checking the agent, the service is running. Which troubleshooting step should the analyst perform next to diagnose endpoint event streaming issues?

Trap 1: Modify the XQL ingestion parser rules for the endpoint asset…

Parser rules transform events already received by XSIAM; they cannot cause an endpoint's agent to stop sending process and file telemetry. Parser edits suit correcting field extraction or normalisation once events arrive, not diagnosing missing ingestion.

Trap 2: Purge all historical alerts from the Incident Viewer to free up…

Purging alerts addresses neither agent-to-broker connectivity nor event forwarding, since the Incident Viewer holds already-ingested detections and has no bearing on telemetry transport. It tempts because clearing backlog can restore visibility when the console itself is saturated, which is the right move for a stalled UI, not a silent endpoint.

Trap 3: Run an immediate software upgrade of the XSIAM tenant license key.

A licence key governs entitlement and feature access, not per-endpoint event forwarding, so upgrading it cannot resume telemetry from one silent agent. Licence changes suit tenant-wide entitlement or expiry problems, not a single endpoint's streaming failure.

A
Modify the XQL ingestion parser rules for the endpoint asset dataset.
Why it fails: Parser rules transform events already received by XSIAM; they cannot cause an endpoint's agent to stop sending process and file telemetry. Parser edits suit correcting field extraction or normalisation once events arrive, not diagnosing missing ingestion.
B
Purge all historical alerts from the Incident Viewer to free up ingestion buffers.
Why it fails: Purging alerts addresses neither agent-to-broker connectivity nor event forwarding, since the Incident Viewer holds already-ingested detections and has no bearing on telemetry transport. It tempts because clearing backlog can restore visibility when the console itself is saturated, which is the right move for a stalled UI, not a silent endpoint.
C
Inspect the local agent log files on the endpoint to identify communication or buffering errors with the XSIAM backend.
Since the service runs but no telemetry reaches XSIAM, the fault lies in the agent's outbound communication or internal buffering. Local agent logs record connection failures, queue overflows and backend errors, giving the specific diagnostic evidence needed to pinpoint why events are not streaming.
D
Run an immediate software upgrade of the XSIAM tenant license key.
Why it fails: A licence key governs entitlement and feature access, not per-endpoint event forwarding, so upgrading it cannot resume telemetry from one silent agent. Licence changes suit tenant-wide entitlement or expiry problems, not a single endpoint's streaming failure.

Read the full Ansible explanation →

Question 10hardmulti select

You are troubleshooting a Cortex XSIAM playbook that unexpectedly stopped executing after a script task returned an error. You want to understand how the playbook engine handles task-level errors so you can design more resilient flows. Which TWO statements accurately describe how task errors and playbook continuation behave in Cortex XSIAM? (Choose two.)

Trap 1: By default, when a task fails, the entire playbook run is…

While an unhandled failure can stop a playbook, Cortex XSIAM does not treat immediate termination of the whole run as the universal default behavior you can rely on. Tasks can be configured with error handling and continuation logic, and the engine distinguishes between failing a task and failing the run. Treating termination as the default oversimplifies how the engine behaves.

Trap 2: Once a task fails, the playbook cannot reference any output from…

This is incorrect because failed tasks still produce a result object, including error details, that later tasks can access when the flow is configured to continue. The output may not contain the expected success data, but the error context itself remains referenceable. Claiming outputs are never available after failure misstates how the engine exposes task results.

Trap 3: A failed task always automatically retries the exact same task a…

Cortex XSIAM does not universally auto-retry every failed task a fixed number of times. Retry behavior must be designed, for example by building loop or retry logic, or by configuring task behavior, rather than being an unconditional engine default. Assuming automatic retries exist can lead you to omit needed error handling and leave gaps in resilience.

A
Error information from a failed task, such as the error message, is available in the task result and can be referenced by later tasks in the playbook.
When a task fails, Cortex XSIAM captures the error details in the task result context, so downstream tasks can reference that information. This enables patterns such as branching to a remediation task that reads the error message and includes it in a ticket or notification. It is essential for building informative, self-documenting error-handling flows.
B
By default, when a task fails, the entire playbook run is immediately terminated and no subsequent tasks execute.
Why it fails: While an unhandled failure can stop a playbook, Cortex XSIAM does not treat immediate termination of the whole run as the universal default behavior you can rely on. Tasks can be configured with error handling and continuation logic, and the engine distinguishes between failing a task and failing the run. Treating termination as the default oversimplifies how the engine behaves.
C
A task can be configured so that when it fails, the playbook continues along a designated error path instead of stopping the run.
Cortex XSIAM allows you to define error handling on tasks, so a failing task can branch to a specific continuation path rather than halting the entire playbook. This lets you log the failure, notify an analyst, or attempt remediation while the rest of the playbook still executes. This is the core mechanism for building resilient playbooks that tolerate individual task failures.
D
Once a task fails, the playbook cannot reference any output from that task anywhere later in the run under any configuration.
Why it fails: This is incorrect because failed tasks still produce a result object, including error details, that later tasks can access when the flow is configured to continue. The output may not contain the expected success data, but the error context itself remains referenceable. Claiming outputs are never available after failure misstates how the engine exposes task results.
E
A failed task always automatically retries the exact same task a fixed number of times before the playbook moves on.
Why it fails: Cortex XSIAM does not universally auto-retry every failed task a fixed number of times. Retry behavior must be designed, for example by building loop or retry logic, or by configuring task behavior, rather than being an unconditional engine default. Assuming automatic retries exist can lead you to omit needed error handling and leave gaps in resilience.

Question 11mediummulti select

An administrator is reviewing endpoint agent diagnostic tools available within XSIAM. Which THREE actions can be performed directly from the XSIAM console to troubleshoot or manage an endpoint agent? (Choose three)

Trap 1: Reflash the endpoint hardware BIOS remotely.

BIOS reflashing happens at firmware level through vendor tooling on the device, not through XSIAM's agent management channel, which handles isolate, quarantine, log retrieval and uninstall. It is tempting because firmware compromise is a genuine attack vector, so reflashing would be correct if the question covered hardware-level remediation rather than console agent actions.

Trap 2: Format the primary OS drive and reinstall Windows.

XSIAM's console offers agent actions such as isolate, quarantine, retrieve logs and uninstall; wiping a drive and reinstalling Windows is OS deployment, outside agent diagnostics. It is tempting because full remediation of a compromised host sometimes requires reimaging, which would be correct if the question asked about endpoint recovery rather than agent troubleshooting.

A
Reflash the endpoint hardware BIOS remotely.
Why it fails: BIOS reflashing happens at firmware level through vendor tooling on the device, not through XSIAM's agent management channel, which handles isolate, quarantine, log retrieval and uninstall. It is tempting because firmware compromise is a genuine attack vector, so reflashing would be correct if the question covered hardware-level remediation rather than console agent actions.
B
Trigger a remote restart of the Cortex XDR agent service.
The XDR agent service can be restarted remotely from the XSIAM console via the endpoint's action menu, forcing the agent to reinitialise without local access. This satisfies the stem's requirement for agent troubleshooting and management actions performed directly from the console.
C
Execute osquery-based Live Queries against the endpoint.
Live Queries run osquery SQL against the endpoint from the XSIAM console, returning process, file and registry telemetry on demand. This satisfies the stem's requirement for console-based agent diagnostics, providing investigation data without disrupting the endpoint or requiring local access.
D
Format the primary OS drive and reinstall Windows.
Why it fails: XSIAM's console offers agent actions such as isolate, quarantine, retrieve logs and uninstall; wiping a drive and reinstalling Windows is OS deployment, outside agent diagnostics. It is tempting because full remediation of a compromised host sometimes requires reimaging, which would be correct if the question asked about endpoint recovery rather than agent troubleshooting.
E
Initiate Network Isolation to contain a compromised host.
Network Isolation is a direct endpoint response action available from the XSIAM console, containing a compromised host by cutting its network connectivity. This satisfies the containment requirement, halting lateral movement and command-and-control traffic while preserving the agent for further investigation.