Troubleshooting Scenario Questions

Run a Live Terminal session and execute a log collection script

Why it fails: Live Terminal provides interactive shell access for investigations, but it is not the dedicated mechanism for retrieving agent diagnostic logs. While possible, it is less efficient and may not package logs in the expected format for support analysis.

Export the endpoint's alert history to a CSV file

Why it fails: Exporting alert history provides a record of detections but does not include the agent's internal diagnostic logs needed to understand why events were or were not detected. It is a different data set and insufficient for this troubleshooting task.

Configure a new policy that enables verbose logging and wait for logs to appear in the console

Why it fails: Enabling verbose logging may increase detail but does not immediately retrieve existing logs; it also requires a policy change and time for new data. The analyst needs current diagnostic logs, which the Retrieve Agent Logs action provides directly.

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.

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.

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.

Data Hub > Query Service

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

Settings > Integrations > Instances logs

Why it fails: Incorrect. Integration instance logs show connection health, not specific playbook task execution runs.

Incidents > Audit Trail

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

comp count(dst_ip) as dest_count by src_host | filter dest_count > 15

Why it fails: Using count rather than count_distinct totals every destination event, so repeated connections to the same IP inflate the number. A host hitting one destination 20 times would incorrectly appear to exceed the threshold. It also never buckets by hour, so the per-hour requirement is not met.

stats max(dst_ip) as dest_count by src_host | filter dest_count > 15

Why it fails: The max aggregator returns the highest destination value, not the number of unique destinations, so the comparison to 15 is meaningless. There is also no hourly binning, meaning the result would not represent a per-hour count and would misrepresent lateral-movement volume entirely.

dedup dst_ip by src_host | comp count() as dest_count by src_host | filter dest_count > 15

Why it fails: dedup removes duplicate destination rows, but the subsequent count() tallies remaining events rather than unique destinations in a time bucket, and no hourly grouping exists. The pipeline cannot answer distinct destinations per hour and would also discard legitimate repeat-visit evidence needed for the investigation.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Run a full antivirus scan on the endpoint using the XSIAM agent

Why it fails: A full antivirus scan may detect and remove some malware, but it does not isolate the endpoint from the network, allowing potential ongoing exfiltration or lateral movement. It also does not guarantee preservation of volatile evidence. This action is not a containment measure and is not the appropriate first response for a compromised endpoint.

Disable the endpoint's user account in Active Directory

Why it fails: Disabling the user account prevents further authentication but does not stop the compromised endpoint from communicating with command-and-control servers or spreading laterally. It also does not provide a means to remotely investigate the endpoint. This action is insufficient for containment and does not address the active threat on the device.

Shut down the endpoint to prevent further damage

Why it fails: Shutting down the endpoint destroys volatile evidence such as memory-resident malware and active network connections, which are critical for investigation. It also prevents remote investigation. While it stops the immediate threat, it is a heavy-handed action that hinders forensic analysis. XSIAM provides more surgical containment options.

Disable the agent's kernel-level protection features to allow it to connect.

Why it fails: Disabling kernel-level protection features would reduce the agent's security capabilities and is not a recommended troubleshooting step. It could leave the server vulnerable. The disconnection might be due to other reasons such as network issues or certificate problems. The analyst should first investigate the cause before making configuration changes that weaken security.

Reinstall the Cortex XDR agent with the latest version from the XSIAM console.

Why it fails: Reinstalling the agent without first diagnosing the issue could be disruptive to the critical server and may not resolve the problem if the root cause is a kernel incompatibility that persists in the new version. It is better to check logs first to understand why the agent is disconnected. Reinstallation should be considered after identifying the cause.

Verify that the server's firewall allows outbound communication on port 443 to the XSIAM tenant.

Why it fails: While firewall rules are a common cause of disconnection, the scenario specifically mentions a suspected compatibility issue with kernel modules. Checking firewall rules is a good general step, but given the context, it is not the most appropriate first step. The analyst should focus on the agent's local logs to confirm the compatibility issue before checking network connectivity.

Update the local Active Directory Group Policy Objects

Why it fails: Group Policy Objects configure Windows domain settings; they cannot query XSIAM telemetry or threat intelligence. It is tempting because Group Policy is a genuine administrative control for endpoint configuration, and it would be the right answer if the task were enforcing a security baseline across domain-joined machines.

Reboot the core XSIAM ingestion server to force log re-indexing

Why it fails: Rebooting the ingestion server disrupts collection and forces no useful re-indexing; it does not surface threat intelligence matches for investigation. It suits recovering a stalled broker or appliance. Analysts instead query the indicator matches in the XSIAM console or pivot on the associated entity.

Run a hardware diagnostic script on network switches

Why it fails: Hardware diagnostics on switches inspect device health, not XSIAM's correlation of network telemetry against threat intelligence indicators. It suits troubleshooting physical link or port faults. Analysts instead query threat intelligence matches in the XSIAM console or pivot on the associated indicator.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.