Scenario practice questions

An XSIAM Analyst is reviewing the Analytics page and needs to understand the difference between standard alerts and incident-bound alerts. Which of the following best describes the role of analytics in XSIAM's alerting process?

Trap 1: Analytics replace the need for correlation rules by directly…

Analytics raise and enrich alerts for analyst triage; they do not close false positives, which requires detection rules, exclusions or automation playbooks. It tempts because analytics reduce noise, but correlation rules still bind alerts into incidents, and closure is a separate response action.

Trap 2: Analytics are exclusively used for reporting compliance and do not…

Analytics drive the active alert queue by generating standard and incident-bound alerts; compliance reporting is a separate function. It tempts because analytics data feeds dashboards and reports, but their primary role is alert generation and correlation into incidents, not exclusively regulatory reporting.

Trap 3: Analytics only generate raw logs, requiring manual rule creation to…

Analytics consume ingested logs and telemetry to generate alerts directly; no manual rule creation is needed to produce them. It tempts because raw log ingestion underpins analytics, but the Analytics page outputs alerts and incident-bound alerts, not just unprocessed logs awaiting hand-built rules.

A
Analytics automatically evaluate telemetry to generate structured alerts that contribute to security incidents.
Analytics continuously parse ingested telemetry, applying detection logic to produce structured alerts. Those alerts then feed incident creation, so analytics form the evaluation layer between raw data and incidents, satisfying the requirement to describe their role in XSIAM's alerting pipeline.
B
Analytics replace the need for correlation rules by directly closing false positives.
Why it fails: Analytics raise and enrich alerts for analyst triage; they do not close false positives, which requires detection rules, exclusions or automation playbooks. It tempts because analytics reduce noise, but correlation rules still bind alerts into incidents, and closure is a separate response action.
C
Analytics are exclusively used for reporting compliance and do not affect the active alert queue.
Why it fails: Analytics drive the active alert queue by generating standard and incident-bound alerts; compliance reporting is a separate function. It tempts because analytics data feeds dashboards and reports, but their primary role is alert generation and correlation into incidents, not exclusively regulatory reporting.
D
Analytics only generate raw logs, requiring manual rule creation to produce alerts.
Why it fails: Analytics consume ingested logs and telemetry to generate alerts directly; no manual rule creation is needed to produce them. It tempts because raw log ingestion underpins analytics, but the Analytics page outputs alerts and incident-bound alerts, not just unprocessed logs awaiting hand-built rules.

Question 2mediummultiple choice

An administrator is preparing to enable the Cortex XDR agent's malware protection module on a set of Windows engineering workstations that run custom compiled binaries not seen elsewhere in the organization. The administrator wants to avoid disrupting legitimate builds while still catching malicious executables. Which approach best balances protection and operational continuity?

Trap 1: Enable the malware protection module in report-only mode for the…

Report-only mode logs detections without blocking them, which means malicious executables would still be allowed to run. While it avoids disrupting legitimate builds, it also removes the protection the administrator is trying to enable, making it a poor balance between security and operational continuity.

Trap 2: Enable blocking mode and create a wildcard path exclusion for the…

A directory-wide wildcard exclusion would allow any file placed in that path to execute without malware scanning, including malicious files dropped there by an attacker. This is broader than necessary and creates a significant blind spot, whereas allowlisting individual hashes keeps protection intact for all other content.

Trap 3: Leave the malware protection module disabled and rely solely on…

Disabling malware protection removes signature and reputation-based detection entirely, leaving only behavioral analytics. The custom binaries would not be disrupted, but known malicious files with established signatures could execute, which is an unacceptable reduction in protection for engineering workstations with build privileges.

A
Enable the malware protection module in report-only mode for the entire workstation group.
Why it fails: Report-only mode logs detections without blocking them, which means malicious executables would still be allowed to run. While it avoids disrupting legitimate builds, it also removes the protection the administrator is trying to enable, making it a poor balance between security and operational continuity.
B
Enable blocking mode and create a wildcard path exclusion for the directory where the custom binaries are compiled.
Why it fails: A directory-wide wildcard exclusion would allow any file placed in that path to execute without malware scanning, including malicious files dropped there by an attacker. This is broader than necessary and creates a significant blind spot, whereas allowlisting individual hashes keeps protection intact for all other content.
C
Leave the malware protection module disabled and rely solely on behavioral threat protection.
Why it fails: Disabling malware protection removes signature and reputation-based detection entirely, leaving only behavioral analytics. The custom binaries would not be disrupted, but known malicious files with established signatures could execute, which is an unacceptable reduction in protection for engineering workstations with build privileges.
D
Enable the malware protection module in blocking mode and add a hash-based allowlist for the known legitimate custom binaries.
Hash-based allowlisting lets the administrator permit specific known-good custom binaries while keeping malware protection in blocking mode for everything else. This preserves strong protection across the workstation fleet and avoids disrupting builds, because only the explicitly approved artifacts are exempted from blocking.

Read the full Ansible explanation →

Question 3hardmultiple choice

A playbook is designed to isolate an endpoint when a malware incident is detected. The isolation task occasionally fails because the endpoint is offline. The analyst wants the playbook to continue processing other tasks and record the failure for later review instead of stopping the entire playbook. Which playbook task configuration should the analyst apply?

Trap 1: Change the task's execution mode to 'Run in parallel' so that other…

Running the task in parallel changes when it executes relative to other tasks, but it does not change how a task failure affects the playbook. A failed task can still halt the playbook or leave the failure unrecorded. Parallel execution is about concurrency, not error handling, so it does not satisfy the requirement to continue and record the failure.

Trap 2: Add a conditional task before the isolation task that verifies the…

A pre-check can avoid attempting isolation on an offline endpoint, but it does not record a failure when isolation is needed and cannot be performed. It also does not help if the endpoint goes offline after the check. The requirement is to continue processing and record the failure, which this approach does not accomplish.

Trap 3: Wrap the isolation task in a loop that retries until the endpoint…

A retry loop may eventually succeed if the endpoint returns, but it does not allow the playbook to continue other tasks while waiting, and it can block the playbook indefinitely. The requirement is to continue processing and record the failure, not to wait for the endpoint. This approach also risks timeouts and does not provide a clear failure record.

A
Change the task's execution mode to 'Run in parallel' so that other tasks execute regardless of the isolation outcome.
Why it fails: Running the task in parallel changes when it executes relative to other tasks, but it does not change how a task failure affects the playbook. A failed task can still halt the playbook or leave the failure unrecorded. Parallel execution is about concurrency, not error handling, so it does not satisfy the requirement to continue and record the failure.
B
Set the task's 'Continue on error' property to true and add a subsequent task that checks the task result for failure.
Enabling 'Continue on error' allows the playbook to proceed even if the isolation task fails, and a later task can inspect the result to log or remediate the failure. This matches the requirement to keep the playbook running while capturing the failure for review. It is the standard XSIAM mechanism for non-blocking error handling within a playbook.
C
Add a conditional task before the isolation task that verifies the endpoint is online, and skip isolation if it is not.
Why it fails: A pre-check can avoid attempting isolation on an offline endpoint, but it does not record a failure when isolation is needed and cannot be performed. It also does not help if the endpoint goes offline after the check. The requirement is to continue processing and record the failure, which this approach does not accomplish.
D
Wrap the isolation task in a loop that retries until the endpoint comes online.
Why it fails: A retry loop may eventually succeed if the endpoint returns, but it does not allow the playbook to continue other tasks while waiting, and it can block the playbook indefinitely. The requirement is to continue processing and record the failure, not to wait for the endpoint. This approach also risks timeouts and does not provide a clear failure record.

Question 4mediummultiple choice

An XSIAM analyst is investigating a malware incident where the endpoint has been isolated from the network. The analyst needs to retrieve a copy of a suspicious executable from the endpoint for further analysis in a sandbox. Which XSIAM capability should the analyst use to obtain the file?

Trap 1: XSIAM Action Center

The Action Center is a centralized interface for managing response actions across integrated tools, but it does not itself perform file retrieval. It may be used to initiate a file retrieval playbook, but the actual capability resides in Cortex XDR File Retrieval. Thus, it is not the direct feature for obtaining the file.

Trap 2: Cortex XDR Live Terminal

Live Terminal provides an interactive shell on the endpoint for running commands, but it does not directly facilitate file retrieval to the analyst's workstation. The analyst could use it to copy the file to a share, but that requires additional steps and is not the primary purpose. It is not the most efficient or intended method for extracting a file for sandbox analysis.

Trap 3: XSIAM Query Builder

The Query Builder is used to create and run XQL queries against collected data, not to retrieve files from endpoints. While it can help identify file paths or hashes, it cannot extract the actual file. Therefore, it is not suitable for obtaining the executable for sandbox analysis.

A
XSIAM Action Center
Why it fails: The Action Center is a centralized interface for managing response actions across integrated tools, but it does not itself perform file retrieval. It may be used to initiate a file retrieval playbook, but the actual capability resides in Cortex XDR File Retrieval. Thus, it is not the direct feature for obtaining the file.
B
Cortex XDR Live Terminal
Why it fails: Live Terminal provides an interactive shell on the endpoint for running commands, but it does not directly facilitate file retrieval to the analyst's workstation. The analyst could use it to copy the file to a share, but that requires additional steps and is not the primary purpose. It is not the most efficient or intended method for extracting a file for sandbox analysis.
C
XSIAM Query Builder
Why it fails: The Query Builder is used to create and run XQL queries against collected data, not to retrieve files from endpoints. While it can help identify file paths or hashes, it cannot extract the actual file. Therefore, it is not suitable for obtaining the executable for sandbox analysis.
D
Cortex XDR File Retrieval
Cortex XDR File Retrieval allows analysts to securely pull files from endpoints, even if they are isolated. This is the intended feature for obtaining suspicious files for offline analysis. It preserves the chain of custody and integrates with the incident response workflow, making it the correct choice for retrieving the executable.

Question 5easymultiple choice

An analyst notices that a specific analytic is generating a high volume of false positive alerts. The analyst wants to reduce the noise without disabling the analytic entirely. Which XSIAM feature should the analyst use to suppress these alerts based on specific conditions?

Trap 1: Analytic tuning parameters

Analytic tuning parameters are used to adjust the sensitivity of an analytic, such as thresholds or time windows, but they do not provide granular suppression based on specific conditions. Tuning might reduce volume but could also impact true positives. Exception rules offer precise, condition-based suppression without altering the analytic's core logic. Therefore, tuning is not the most targeted solution for this scenario.

Trap 2: Correlation rules

Correlation rules are used to group multiple alerts into incidents, not to suppress individual alerts. They define how alerts are aggregated, but they do not filter out false positives at the alert generation level. Using correlation rules to address false positives would not prevent the alerts from being created; it would only affect how they are bundled. Therefore, this is not the correct feature for suppressing specific alert conditions.

Trap 3: Custom prioritization rules

Custom prioritization rules adjust incident scores based on conditions but do not suppress alerts. They can influence which incidents are prioritized, but the underlying alerts are still generated and visible. To reduce noise from false positives, suppression must occur at the alert creation stage, which custom prioritization does not control. Thus, this feature is not suitable for the analyst's goal.

A
Analytic tuning parameters
Why it fails: Analytic tuning parameters are used to adjust the sensitivity of an analytic, such as thresholds or time windows, but they do not provide granular suppression based on specific conditions. Tuning might reduce volume but could also impact true positives. Exception rules offer precise, condition-based suppression without altering the analytic's core logic. Therefore, tuning is not the most targeted solution for this scenario.
B
Correlation rules
Why it fails: Correlation rules are used to group multiple alerts into incidents, not to suppress individual alerts. They define how alerts are aggregated, but they do not filter out false positives at the alert generation level. Using correlation rules to address false positives would not prevent the alerts from being created; it would only affect how they are bundled. Therefore, this is not the correct feature for suppressing specific alert conditions.
C
Custom prioritization rules
Why it fails: Custom prioritization rules adjust incident scores based on conditions but do not suppress alerts. They can influence which incidents are prioritized, but the underlying alerts are still generated and visible. To reduce noise from false positives, suppression must occur at the alert creation stage, which custom prioritization does not control. Thus, this feature is not suitable for the analyst's goal.
D
Exception rules
Exception rules in XSIAM allow analysts to define conditions under which an alert is not generated or is automatically closed. They are designed to suppress false positives without disabling the analytic. By creating an exception rule that matches the benign activity, the analyst can prevent those alerts from appearing. This is the recommended approach for reducing noise while maintaining detection coverage.

Question 6mediummultiple choice

An analyst is investigating an incident in XSIAM where a single high-severity alert was generated, but the incident detail view shows three related alerts grouped together. The analyst needs to determine why these alerts were correlated into one incident rather than appearing as separate incidents. Which XSIAM mechanism is responsible for automatically grouping related alerts into a single incident?

Trap 1: BIOC indicator matching that triggers deduplication of identical…

BIOC (Behavioral Indicator of Compromise) matching in XSIAM identifies malicious behavior patterns and generates alerts when those patterns are detected. While BIOCs can produce alerts, they do not deduplicate or group distinct alerts into incidents. Deduplication removes exact duplicates, whereas the scenario involves three related but distinct alerts being correlated into one incident through entity and time-based grouping.

Trap 2: Alert exclusion rules configured in the Analytics settings

Alert exclusion rules in XSIAM are designed to suppress or filter out alerts that match specific criteria, preventing them from being generated or displayed. They do not perform correlation or grouping of multiple alerts into a single incident. Exclusion rules reduce noise by removing alerts entirely, whereas the scenario describes multiple alerts being combined into one incident, which is a correlation function, not an exclusion function.

Trap 3: Custom prioritization rules that assign severity scores to incoming…

Custom prioritization rules in XSIAM determine the severity and priority assigned to alerts based on defined criteria such as asset criticality or alert type. They influence scoring and ranking but do not perform the grouping or correlation of multiple alerts into a single incident. The scenario describes alerts being combined, which is a correlation outcome, not a prioritization outcome.

A
Incident grouping and correlation logic based on shared entities and time proximity
XSIAM automatically correlates alerts into incidents by evaluating shared entities such as the same host, user account, or IP address, along with temporal proximity. When multiple alerts reference overlapping indicators within a defined window, the correlation engine groups them into a single incident. This explains why three related alerts appear under one incident rather than as separate entries, matching the described behavior.
B
BIOC indicator matching that triggers deduplication of identical alerts
Why it fails: BIOC (Behavioral Indicator of Compromise) matching in XSIAM identifies malicious behavior patterns and generates alerts when those patterns are detected. While BIOCs can produce alerts, they do not deduplicate or group distinct alerts into incidents. Deduplication removes exact duplicates, whereas the scenario involves three related but distinct alerts being correlated into one incident through entity and time-based grouping.
C
Alert exclusion rules configured in the Analytics settings
Why it fails: Alert exclusion rules in XSIAM are designed to suppress or filter out alerts that match specific criteria, preventing them from being generated or displayed. They do not perform correlation or grouping of multiple alerts into a single incident. Exclusion rules reduce noise by removing alerts entirely, whereas the scenario describes multiple alerts being combined into one incident, which is a correlation function, not an exclusion function.
D
Custom prioritization rules that assign severity scores to incoming alerts
Why it fails: Custom prioritization rules in XSIAM determine the severity and priority assigned to alerts based on defined criteria such as asset criticality or alert type. They influence scoring and ranking but do not perform the grouping or correlation of multiple alerts into a single incident. The scenario describes alerts being combined, which is a correlation outcome, not a prioritization outcome.

Read the full Ansible explanation →

Question 7easymultiple choice

A security team wants a Cortex XSIAM playbook to run automatically the moment a new high-severity incident is created, without any analyst clicking a button. Which configuration makes the playbook start on its own when the incident is generated?

Trap 1: Add the playbook to a dashboard widget that refreshes whenever a…

Dashboard widgets visualize data such as incident counts and trends; they do not execute playbooks. Adding the playbook reference to a widget would at most display status information, and refreshing the widget would not start any automation, so new high-severity incidents would still sit without a response until someone acted manually.

Trap 2: Create a scheduled job that launches the playbook every minute to…

A recurring scheduled job would launch the playbook on a timer rather than in response to incident creation, adding up to a minute of latency and running the playbook even when no new incident exists. This is less precise than binding the playbook to the incident type, and it can produce unnecessary executions that complicate auditing.

Trap 3: Publish the playbook to the marketplace so subscribers receive it…

Publishing to the marketplace distributes content to other tenants; it does not wire the playbook to this organization's incident creation events. The team's own incidents would still not trigger the playbook automatically, because marketplace publication is a sharing mechanism rather than an execution trigger, leaving the desired hands-off automation unfulfilled.

A
Attach the playbook to the incident type so it triggers automatically when a matching incident is created
Associating a playbook with an incident type causes Cortex XSIAM to launch it automatically whenever an incident of that type is created, which is exactly the unattended, event-driven start the team wants. No analyst action is needed, and every new high-severity incident of the configured type gets the same automated response.
B
Add the playbook to a dashboard widget that refreshes whenever a new incident appears
Why it fails: Dashboard widgets visualize data such as incident counts and trends; they do not execute playbooks. Adding the playbook reference to a widget would at most display status information, and refreshing the widget would not start any automation, so new high-severity incidents would still sit without a response until someone acted manually.
C
Create a scheduled job that launches the playbook every minute to check for new incidents
Why it fails: A recurring scheduled job would launch the playbook on a timer rather than in response to incident creation, adding up to a minute of latency and running the playbook even when no new incident exists. This is less precise than binding the playbook to the incident type, and it can produce unnecessary executions that complicate auditing.
D
Publish the playbook to the marketplace so subscribers receive it and run it on new incidents
Why it fails: Publishing to the marketplace distributes content to other tenants; it does not wire the playbook to this organization's incident creation events. The team's own incidents would still not trigger the playbook automatically, because marketplace publication is a sharing mechanism rather than an execution trigger, leaving the desired hands-off automation unfulfilled.

Question 8hardmulti select

An analyst is building an XQL query that pulls from a dataset with millions of events and must reduce the volume of data returned to the console while still preserving counts for reporting. Which TWO statements about XQL pipeline behavior are accurate in this scenario? (Choose two.)

Trap 1: Field selection stages do not affect performance because XSIAM…

Selecting only needed fields reduces the data carried through the pipeline and returned to the console, which lowers transfer and rendering cost. The claim that all fields are always materialized regardless of the query is inaccurate; narrowing columns is a recognized efficiency practice when handling large datasets.

Trap 2: Adding a `limit` stage at the very start of the pipeline guarantees…

A `limit` stage truncates the stream to the specified number of rows, so any stage after it, including aggregation, only sees those retained rows. Placing it first would discard most events and produce counts that do not represent the full dataset, defeating the reporting requirement entirely.

Trap 3: The `dedup` stage preserves every duplicate event while adding a…

`dedup` removes duplicate events and keeps representative rows; it does not retain all duplicates and does not add a count column. Counts come from aggregation functions in a `stats` stage. Relying on dedup for counting would therefore lose the very events needed to compute accurate totals.

A
Using `stats` with a grouping field collapses matching events into aggregated rows, so the returned row count is typically far smaller than the input event count.
Aggregation groups many events into one output row per distinct group value, so the result set size is bounded by the number of unique group combinations rather than raw event volume. This is exactly how an analyst preserves counts for reporting while dramatically reducing what is returned to the console.
B
Field selection stages do not affect performance because XSIAM always materializes every field from storage regardless of the query.
Why it fails: Selecting only needed fields reduces the data carried through the pipeline and returned to the console, which lowers transfer and rendering cost. The claim that all fields are always materialized regardless of the query is inaccurate; narrowing columns is a recognized efficiency practice when handling large datasets.
C
Placing a `filter` stage as early as possible reduces the number of events processed by later stages, improving query efficiency.
XQL pipelines process events stage by stage, so filtering early shrinks the working set before expensive operations like aggregation or joins run. This reduces compute and memory pressure and returns results faster. In a multi-million-event dataset, early filtering is the single most effective optimization the analyst can apply.
D
Adding a `limit` stage at the very start of the pipeline guarantees the aggregation still sees every original event.
Why it fails: A `limit` stage truncates the stream to the specified number of rows, so any stage after it, including aggregation, only sees those retained rows. Placing it first would discard most events and produce counts that do not represent the full dataset, defeating the reporting requirement entirely.
E
The `dedup` stage preserves every duplicate event while adding a count column for each repeated value.
Why it fails: `dedup` removes duplicate events and keeps representative rows; it does not retain all duplicates and does not add a count column. Counts come from aggregation functions in a `stats` stage. Relying on dedup for counting would therefore lose the very events needed to compute accurate totals.

Question 9hardmultiple choice

A Cortex XDR agent on a Linux server is repeatedly triggering behavioral threat protection alerts for a legitimate backup script that spawns shell commands and reads many files. The administrator wants to suppress these false positives without weakening protection against actual malicious behavior. Which action is most appropriate?

Trap 1: Disable behavioral threat protection on the Linux server group.

Disabling behavioral threat protection for the entire server group removes detection for all behavioral attack techniques, not just the backup script. This is a drastic overreach that would leave the servers exposed to fileless malware, credential theft, and other behaviors the module is designed to catch.

Trap 2: Change the agent's action for behavioral threat protection from…

Switching to report-only reduces enforcement for every behavioral detection, not only the backup script. Malicious behaviors would still be logged but not blocked, which weakens the security posture across the board and is not justified by a single legitimate script generating false positives.

Trap 3: Create an alert exclusion that hides all behavioral threat…

An alert exclusion that hides all behavioral alerts from the server would conceal genuine detections along with the false positives, creating a dangerous visibility gap. Exclusions should be narrowly scoped to the offending process rather than applied to an entire alert category for the host.

A
Disable behavioral threat protection on the Linux server group.
Why it fails: Disabling behavioral threat protection for the entire server group removes detection for all behavioral attack techniques, not just the backup script. This is a drastic overreach that would leave the servers exposed to fileless malware, credential theft, and other behaviors the module is designed to catch.
B
Add a Behavioral Threat Protection exception scoped to the specific backup script's path and command line.
Scoping an exception to the exact path and command line of the legitimate backup script suppresses the false positives while leaving behavioral detection active for all other processes. This is the most precise mitigation and preserves protection against genuinely malicious activity on the server.
C
Change the agent's action for behavioral threat protection from blocking to report-only.
Why it fails: Switching to report-only reduces enforcement for every behavioral detection, not only the backup script. Malicious behaviors would still be logged but not blocked, which weakens the security posture across the board and is not justified by a single legitimate script generating false positives.
D
Create an alert exclusion that hides all behavioral threat protection alerts originating from the server.
Why it fails: An alert exclusion that hides all behavioral alerts from the server would conceal genuine detections along with the false positives, creating a dangerous visibility gap. Exclusions should be narrowly scoped to the offending process rather than applied to an entire alert category for the host.

Question 10easymultiple choice

An analyst notices that a Cortex XDR agent on a macOS endpoint is repeatedly disconnecting from the XSIAM tenant. The endpoint is behind a proxy that requires authentication. Which configuration should the analyst verify on the agent to ensure it can authenticate to the proxy and maintain connectivity?

Trap 1: The agent's content update schedule to ensure it aligns with proxy…

Content update schedule affects when signatures are fetched, not the agent's ability to maintain a persistent connection through an authenticated proxy. Misaligned schedules would cause delayed updates, not repeated disconnections. The core issue is proxy authentication, which is handled by the agent's proxy configuration, not the update schedule.

Trap 2: The macOS network settings to ensure the proxy is configured…

While system-wide proxy settings may affect some applications, the Cortex XDR agent uses its own proxy configuration defined in the endpoint policy. Relying on macOS system proxy settings does not guarantee the agent uses them, especially if the agent is configured to bypass system proxies. The agent-specific settings must be checked and configured correctly.

Trap 3: The XSIAM tenant's allowed IP list to include the proxy's external…

The tenant's allowed IP list, if used, restricts which IPs can connect to the tenant. However, the agent connects outbound through the proxy, so the proxy's external IP would need to be allowed if such a list exists. But the scenario specifies the proxy requires authentication, so the immediate issue is credentials, not IP filtering. Verifying the allowed IP list is secondary and not the primary fix.

A
The agent's content update schedule to ensure it aligns with proxy authentication windows.
Why it fails: Content update schedule affects when signatures are fetched, not the agent's ability to maintain a persistent connection through an authenticated proxy. Misaligned schedules would cause delayed updates, not repeated disconnections. The core issue is proxy authentication, which is handled by the agent's proxy configuration, not the update schedule.
B
The macOS network settings to ensure the proxy is configured system-wide.
Why it fails: While system-wide proxy settings may affect some applications, the Cortex XDR agent uses its own proxy configuration defined in the endpoint policy. Relying on macOS system proxy settings does not guarantee the agent uses them, especially if the agent is configured to bypass system proxies. The agent-specific settings must be checked and configured correctly.
C
The agent's proxy settings in the endpoint policy, including proxy address, port, and credentials.
Cortex XDR agents can be configured to use a proxy for outbound communication. If the proxy requires authentication, the agent policy must include the proxy address, port, and credentials. Without correct credentials, the agent cannot establish a connection, leading to repeated disconnects. Verifying these settings is the first step to restore connectivity in this scenario.
D
The XSIAM tenant's allowed IP list to include the proxy's external IP address.
Why it fails: The tenant's allowed IP list, if used, restricts which IPs can connect to the tenant. However, the agent connects outbound through the proxy, so the proxy's external IP would need to be allowed if such a list exists. But the scenario specifies the proxy requires authentication, so the immediate issue is credentials, not IP filtering. Verifying the allowed IP list is secondary and not the primary fix.