Troubleshooting practice questions

Run the `xdrctl troubleshoot` command from any managed Windows endpoint agent console.

Why it fails: The xdrctl troubleshoot command runs on the Broker VM console itself, not from a managed Windows endpoint agent, so it cannot inspect the failing appliance. It tempts because xdrctl is a real diagnostic tool, which suits troubleshooting the endpoint agent rather than Broker VM ingestion.

Reset the cloud tenant encryption keys under General Settings.

Why it fails: Resetting cloud tenant encryption keys addresses key management, not syslog connectivity, and could disrupt ingestion further. It tempts because key operations sit under General Settings where administrators expect tenant-wide fixes, which suits genuine key rotation or recovery scenarios rather than diagnosing a broken log source.

Open the XSIAM Incident Graph to view packet captures from the Broker VM IP.

Why it fails: The Incident Graph visualises correlated alerts and incidents; it does not capture packets from the Broker VM interface. It tempts because packet-level evidence is genuinely useful for network faults, which suits investigating an already-detected incident rather than first-line checks on a silent syslog feed.

In the Cortex XSIAM tenant UI under Incident Response settings.

Why it fails: Proxy settings for Broker VM content downloads are configured locally on the Broker VM, not in the tenant UI, so this location never reaches the outbound update path. It is tempting because the tenant UI centralises many agent and integration settings, but it would be correct for tenant-level incident response configuration instead.

By editing the local firewall rules using iptables to forward port 80 to port 3128.

Why it fails: iptables NAT redirection cannot supply proxy credentials or the upstream proxy's address, so the Broker VM still cannot reach the Cortex XSIAM cloud through the enterprise proxy. Port forwarding is for transparent interception, which would be the right approach only where clients cannot be configured and the proxy accepts unauthenticated transparent traffic.

By modifying the Windows Registry on the underlying host operating system.

Why it fails: The Broker VM runs as a Linux-based virtual appliance, so there is no Windows Registry to edit; proxy settings belong in the Broker VM's own configuration interface. Registry-based proxy configuration is for Windows endpoints or servers, which would be the correct target only if the Broker VM were Windows-hosted.

The Broker VM operating system automatically shuts down all network interfaces after 10 minutes of clock discrepancy.

Why it fails: No such watchdog exists; the Broker VM does not disable its network interfaces on clock drift. It tempts as a dramatic explanation for total loss of connectivity. In reality, TLS certificate validation fails when the clock skews beyond the certificate validity window, breaking the broker's authenticated channel to Cortex XSIAM.

Log collection collectors stop accepting UDP packets if the system time is set to UTC instead of local time.

Why it fails: Collectors accept UDP syslog regardless of whether the host clock is UTC or local; timezone alone does not gate packet reception. It tempts because time settings are involved. The genuine failure is certificate validation during the TLS handshake to Cortex XSIAM, which breaks when the system clock is inaccurate.

The XSIAM licensing server revokes the Broker VM activation token if NTP is not reachable every 60 seconds.

Why it fails: XSIAM does not revoke Broker VM activation tokens based on NTP polling frequency; no 60-second licensing heartbeat exists. It tempts because licensing checks are a familiar cause of disconnection. The actual mechanism is TLS handshake failure: skewed system time invalidates certificate validity periods, so the broker cannot establish its secure connection.

Change the tenant license key to an enterprise tier.

Why it fails: Licence tier governs which features and data sources are enabled, not whether a syntactically valid BIOC matches logs already present in the Data Lake. It is tempting because some detections require higher tiers, so upgrading would be correct if the rule depended on a feature the current licence excludes.

Reboot the XSIAM management cloud cluster master node via SSH.

Why it fails: Rebooting the cluster master restarts services without exposing why the BIOC failed to match, and may disrupt other tenants. It is tempting because a hung correlation engine could stop alert generation, making a restart valid when the platform itself is unresponsive rather than when a single rule silently fails to match.

Disable the default Cortex XDR agent prevention modules.

Why it fails: Agent prevention modules govern endpoint blocking behaviour, not cloud-side BIOC evaluation against Cortex Data Lake logs, so disabling them changes nothing about rule triggering. It is tempting because prevention settings can suppress alerts, making this valid when endpoint-generated alerts are missing rather than cloud log-based BIOC rules.

Reinstall the local printer drivers on the administrator's laptop.

Why it fails: Printer drivers are unrelated to API data collection; the fault lies in Broker VM connectivity, credentials or parsing. Reinstalling them is tempting because driver corruption genuinely breaks local printing, so it would be the right step for a workstation that cannot print, not for a stalled integration.

Format the Broker VM Docker container storage volumes.

Why it fails: Formatting the Broker VM's Docker volumes destroys the container configuration and cached state, worsening the outage rather than diagnosing it. It is tempting because rebuilding a corrupted container can resolve deployment faults, so it would be correct when a Broker VM is irrecoverably broken, not merely failing to collect data.

Cloud Identity > Integrations > Status

Why it fails: Cloud Identity > Integrations > Status shows identity provider integration health, not Broker VM operational state. It is tempting because integrations have status pages, but remote-site Broker VMs are infrastructure components listed under Settings > Configurations > Broker VMs.

Dashboards > Incident Management > Overview

Why it fails: Dashboards > Incident Management > Overview reports alert and case metrics, not Broker VM health. It is tempting because dashboards aggregate operational data, but broker status lives under the dedicated Broker VMs or data collector health view in settings, not incident management.

Investigate > Endpoint Security > Collectors

Why it fails: Investigate > Endpoint Security > Collectors lists endpoint agents reporting telemetry, not Broker VMs deployed at remote sites. It is tempting because both are collector-related, but Broker VM health is managed under Settings > Configurations > Broker VMs, not the endpoint investigation view.

The XSIAM tenant billing dashboard to verify license usage.

Why it fails: The billing dashboard reports licence consumption and entitlement, not packet receipt. It cannot reveal whether syslog arrived at the Broker VM. It would be the right check when investigating licence overage or data ingestion quota problems, not a missing-log ingestion path.

The active firewall security policy rulebase.

Why it fails: Firewall policy rules govern traffic inspection and logging decisions, not syslog delivery to the Broker VM. Checking the rulebase cannot confirm whether raw packets arrive. It would be the right place to verify that the firewall generates and forwards the relevant log types in the first place, but the stem asks about receipt at the Broker.

The endpoint cytool diagnostic utility on managed servers.

Why it fails: cytool is the Cortex XDR endpoint agent diagnostic utility, running on managed endpoints rather than the Broker VM. It cannot show whether syslog packets reached the Broker. It would be correct for troubleshooting endpoint agent connectivity or policy issues on managed servers, not firewall syslog ingestion.

Restart the Broker VM service and re-register the endpoint agents to force a fresh connection.

Why it fails: Restarting services and re-registering agents are disruptive remediation steps, not diagnostic ones. They may temporarily mask a collection issue and will not help if the real problem is parsing. Because the Broker VM already shows healthy connectivity, this action risks unnecessary downtime and does not answer whether events are being parsed or received, so it is inappropriate as a first step.

Use the Data Ingestion dashboard to check the ingestion rate and error counts for the endpoint telemetry dataset.

Why it fails: The Data Ingestion dashboard reports volume and errors, which can confirm a drop, but it does not directly reveal whether parsing or collection is the root cause. Error counts may be absent even when parsing silently drops fields. Starting here provides situational awareness but not the granular parsing versus collection distinction the engineer needs, so it is a weaker first action than dataset-level inspection.

Open the Broker VM's local log viewer and inspect the raw payload arriving from the endpoint agents.

Why it fails: The Broker VM local log viewer can confirm that data is arriving, but it does not show how XSIAM parses or maps the events. If the payload is present locally, the failure could still be in the parsing pipeline. Inspecting raw payloads alone will not distinguish a collection problem from a parsing problem, so it is not the most efficient first step for this specific diagnosis.

Move the API call to a separate playbook that runs on a schedule instead of on demand

Why it fails: Scheduling the enrichment decouples it from the incident, so the playbook may run before the data is refreshed. This introduces staleness and does not address the timeout itself. The scenario requires the enrichment during incident response, so deferring it to a scheduled job would break the intended workflow rather than fix the reliability problem.

Convert the script from Python to PowerShell to change its network stack

Why it fails: Changing the scripting language does not resolve network latency or transient API failures, and it forces a costly rewrite. The underlying HTTP behavior and timeouts would remain governed by the same network conditions. This is a distractor that confuses implementation language with reliability engineering, and it adds risk without addressing the root cause.

Disable the playbook's error handling so failures are silently ignored

Why it fails: Suppressing errors hides real failures and can let the playbook continue with missing enrichment data, producing incorrect decisions. It does not make the script more resilient; it merely conceals the symptom. Auditors and incident reviewers would also lose visibility into recurring API problems, which is the opposite of good operational practice.

Verify firewall rules between the syslog source and the Broker VM

Why it fails: While firewall rules are important, the scenario states the Broker VM is reachable and the source is configured. If the Broker VM is reachable, basic connectivity may be fine, but the specific port could be blocked. However, checking the Broker VM's listener status is more direct and less time-consuming than reviewing firewall rules.

Restart the syslog source device

Why it fails: Restarting the syslog source is a disruptive action that should not be the first step. The issue could be on the Broker VM side. Restarting the source without diagnosis may temporarily resolve a transient issue but does not identify the root cause. It is better to check the Broker VM first.

Re-register the Broker VM with Cortex XSIAM

Why it fails: Re-registering the Broker VM is a drastic step that could disrupt other services. It should only be done if the Broker VM is not communicating with XSIAM at all. The issue here is log reception, not registration. Re-registration would not address a syslog listener problem and could cause additional downtime.

The integration command requires an API key that is only available in the War Room context, not in playbooks.

Why it fails: API keys and other credentials are stored in the integration instance configuration and are accessible both manually and from playbooks. There is no separate context restriction that would make credentials available only in the War Room. If the command works manually, the credentials are correctly configured. The failure within the playbook is not due to credential availability but likely due to how the task invokes the command.

The playbook runs in a different Docker container that does not have network access to the external API.

Why it fails: Cortex XSIAM playbooks and manual commands both execute in Docker containers managed by the platform. Network access is determined by the integration instance's proxy settings, not by the execution context. If manual execution works, the container has network access. Playbooks use the same infrastructure, so there is no inherent network difference. The failure is more likely due to task configuration rather than container networking.

The integration instance 'TI-Platform' is not enabled for use in playbooks.

Why it fails: Integration instances in Cortex XSIAM do not have a specific setting to enable or disable their use in playbooks. If the instance is configured and working manually, it is available to playbooks. The issue is more likely related to how the playbook task references the instance or passes arguments. This option describes a non-existent configuration setting, so it cannot be the cause.

Cortex XDR Agent endpoint quarantine logs

Why it fails: Cortex XDR Agent quarantine logs record endpoint isolation actions, not integration-instance failures, so they cannot expose API authentication errors, connector timeouts or broker connectivity faults. They are tempting because quarantine auditing genuinely matters when investigating malware containment on endpoints — the right choice when an endpoint's isolation state, not an integration's health, is in question.

The local BIOS event log of the client workstation

Why it fails: The workstation BIOS event log records hardware and firmware events, bearing no relation to a server-side integration instance's failures. It suits diagnosing physical hardware faults; XSIAM integration logs and broker diagnostics reveal the actual root cause.

The Cortex XDR agent version is too new for the cloud tenant and must be downgraded.

Why it fails: Agent version mismatches typically surface as unsupported-version or handshake errors, not certificate pinning verification failures. Pinning validates the server certificate against a trusted chain, so the fault lies in the certificate presented by the console or an intercepting proxy, not the agent build.

The local firewall is blocking UDP port 514 outbound from the endpoint.

Why it fails: Blocking UDP 514 would disrupt syslog forwarding, not TLS connectivity to the management console, which uses TCP 443. Certificate pinning verification failures occur during the TLS handshake when the presented certificate does not match the pinned value, so a UDP port block cannot cause this log entry.

The XSIAM tenant license has expired, causing all agents to enter a permanent lock state.

Why it fails: License expiry blocks console access and agent check-ins, but it does not produce certificate pinning verification failures in local logs. Pinning errors indicate a certificate chain mismatch, such as an expired or replaced server certificate or TLS inspection. Licensing is tempting because it halts connectivity broadly, yet the log signature points elsewhere.

The Broker VM requires a manual firmware downgrade to support legacy API protocols

Why it fails: Broker VM firmware downgrades are not a supported remediation for authentication errors; the Broker forwards API traffic and its firmware version does not alter credential validation or OAuth token exchange. It is tempting because Broker VM connectivity problems do block log ingestion, so it would be correct if the test failed with a network timeout rather than an authentication rejection.

The Cortex XDR agent service on endpoints has stopped responding

Why it fails: A stopped Cortex XDR agent affects endpoint telemetry collection, not API authentication, so it cannot cause a credential rejection during integration testing. It is tempting because agent health is a frequent ingestion problem, and would be the right diagnosis if logs were arriving but endpoints appeared offline.

The XQL query builder cache is corrupted and requires a database purge

Why it fails: XQL query builder cache corruption would affect query performance or saved query retrieval, not API authentication handshakes. The cache is rebuilt automatically and never gates credential validation. It is tempting because cache issues do cause intermittent query failures, so it would be the right answer if searches returned stale or malformed results rather than the integration test failing at authentication.

Stop the entire XSIAM tenant, wipe the database, and re-import all log sources from scratch.

Why it fails: Stopping the tenant and wiping the database destroys ingested data and halts all detection, far exceeding a parser field-mapping fix. It is tempting because full re-imports genuinely resolve corrupted datasets or schema drift during initial onboarding, where historical replay is acceptable. Here, only the parser definition needs editing and republishing.

Disable data ingestion globally while rewriting the SQL database schema.

Why it fails: Disabling ingestion globally halts the live data pipeline, and rewriting an SQL database schema addresses storage structure, not parser field extraction — Cortex XSIAM parsers are edited in the Broker VM or parser editor, not via SQL. It tempts administrators planning offline schema migrations during maintenance windows, where ingestion downtime is acceptable.

Deploy a local text-editor plugin to every Broker VM via SSH to modify underlying regex config files.

Why it fails: Editing regex files directly on each Broker VM bypasses version control and creates drift, and SSH changes risk ingestion gaps. Parser updates belong in the platform's central parser management interface, which supports testing and staged rollout; local edits suit isolated lab debugging only.

Modify the global tenant encryption keys under General Settings.

Why it fails: Encryption key settings govern tenant data protection and have no bearing on Docker bridge or overlay networking on the Broker VM host. It is tempting because General Settings is a familiar administrative area, but the fault is local container network corruption requiring a host-level reset script.

Execute an XQL query with the `reset_broker` command.

Why it fails: XQL is a query language for searching and correlating telemetry; it has no `reset_broker` command and cannot restart Docker networking. It is tempting because XQL is central to XSIAM operations, but it reads data rather than executing host-level remediation scripts on the Broker VM.

Run the `xdrctl uninstall` command on every managed Windows endpoint.

Why it fails: `xdrctl uninstall` removes the Cortex XDR agent from endpoints and does not touch the Broker VM's Docker networking. It is tempting because xdrctl is a genuine administrative command, but it operates on endpoint agents, whereas the fault lies in the Broker VM's local container stack.

Create a new playbook to manually map the fields in the alert.

Why it fails: Playbooks act on alerts after ingestion, so they cannot alter how raw log fields are parsed into XDM. Field mapping happens in the parser or data model configuration, which is where the transformation must be debugged. Playbooks are the right tool for automating alert triage and response actions once normalised events already exist.

Modify the ingestion configuration to change the vendor product type.

Why it fails: Changing vendor and product type alters which parser and data model apply, not how the existing mapping transforms fields, so the error persists or shifts. It is tempting because product type selects the parser, but debugging a mapping fault requires inspecting the parsing rules and XDM field mappings directly.

Update the Data Collector version on the server.

Why it fails: Updating the Data Collector version changes ingestion software, not the parsing rules that map fields to XDM. A version mismatch would affect collection or forwarding, not field-level transformation. Collector upgrades are the correct action when logs fail to arrive or the broker connection breaks, not when mapping is wrong.

Direct Syslog forwarding from AWS VPC to Broker VM

Why it fails: CloudTrail does not emit syslog; it writes JSON log files to an S3 bucket, which XSIAM pulls through its API-based data source. VPC syslog forwarding suits network flow or firewall logs generated by appliances, not CloudTrail's S3-delivered audit events, so no data reaches the query builder.

Scheduled SCP file transfer to a Broker VM SFTP directory

Why it fails: XSIAM ingests CloudTrail natively through an API-based Amazon S3 data source pulling log objects, not scheduled SCP transfers into a Broker VM SFTP directory. SFTP polling suits on-premises appliances or legacy systems that can only push files, whereas CloudTrail delivers JSON objects to S3 for API retrieval.

Cortex XDR Agent polling AWS metadata

Why it fails: The Cortex XDR Agent runs on endpoints, not AWS control-plane services, so it cannot poll CloudTrail metadata; CloudTrail events are retrieved by an API-based S3 data source. Agent polling suits endpoint telemetry collection, such as process and network events from managed hosts, not cloud audit logs.

Network firewall logs

Why it fails: Firewall logs can show whether traffic is being blocked, but they do not reveal application-layer issues such as certificate validation failures or agent misconfigurations. Since the administrator already verified network connectivity, firewall logs are less likely to pinpoint the root cause. The agent log is more appropriate for diagnosing why the agent itself is failing to communicate.

Windows Event Log (Application)

Why it fails: While the Windows Event Log may contain some service start/stop events, it does not provide the detailed communication diagnostics that the Cortex XDR agent log does. The agent logs its own connection attempts, errors, and heartbeats in traps.log, making that a more direct and informative source. Checking the Windows Event Log first would likely be inefficient and miss specific agent-level errors.

XSIAM tenant audit log

Why it fails: The XSIAM tenant audit log records actions performed within the console, such as configuration changes and user activity. It does not contain endpoint-side communication errors. While it might show if the agent was disabled or if there were policy changes, it lacks the granular connection details found in the agent log. Therefore, it is not the first place to check for this issue.

The Data Stitching execution summary report

Why it fails: The Data Stitching execution summary reports correlation and stitching outcomes, not integration API request traces, so it cannot show credential rejections or network timeouts. It is tempting because it is an XSIAM execution report, but it is the right place only when diagnosing data-stitching rule behaviour rather than connector connectivity.

The Endpoint Agent audit trail under Cortex XDR > Agents

Why it fails: The Endpoint Agent audit trail records endpoint agent activity on managed hosts, not server-side integration connector calls, so it holds no API request or timeout detail. It is tempting as a Cortex XDR log location, but it is correct only when investigating endpoint agent actions such as scans or isolations.

The Broker VM system log file (/var/log/broker/broker.log)

Why it fails: The Broker VM broker.log records broker infrastructure and data-collection activity, not the integration instance's outbound API calls, so credential failures and timeouts are absent. It is tempting because the broker relays traffic, but it is correct only when diagnosing broker connectivity or collection issues.