Scenario practice questions

An administrator is troubleshooting a scenario where Cortex XDR incident severities appear misaligned with organizational priority. Which THREE components or features can the administrator adjust to tune incident scoring and severity? (Choose three)

Trap 1: Reinstall the Cortex XDR Agent on all high-priority servers.

Reinstalling agents changes nothing about how incidents are scored; severity derives from BIOC rules, alert sources, and scoring configuration. It is tempting because agent faults can cause missing or malformed alerts, and reinstallation would be correct when an endpoint reports no telemetry at all.

Trap 2: Modify the Broker VM packet buffer size.

Broker VM packet buffer sizing governs traffic capture and forwarding performance, not the analytics that compute incident scores. It is tempting because Broker VM tuning affects data reaching the console, and it would be correct when resolving dropped packets or collection throughput problems rather than severity misalignment.

A
Reinstall the Cortex XDR Agent on all high-priority servers.
Why it fails: Reinstalling agents changes nothing about how incidents are scored; severity derives from BIOC rules, alert sources, and scoring configuration. It is tempting because agent faults can cause missing or malformed alerts, and reinstallation would be correct when an endpoint reports no telemetry at all.
B
Modify the Broker VM packet buffer size.
Why it fails: Broker VM packet buffer sizing governs traffic capture and forwarding performance, not the analytics that compute incident scores. It is tempting because Broker VM tuning affects data reaching the console, and it would be correct when resolving dropped packets or collection throughput problems rather than severity misalignment.
C
Create exceptions for known benign alerts to prevent them from inflating incident priority scores.
Exceptions suppress known benign alerts so they no longer contribute weight to incident scoring, preventing false positives from inflating severity. This satisfies the misalignment constraint by removing noise that skews the aggregate score away from genuine organisational priority.
D
Modify individual BIOC or Analytics alert severities to reflect their true operational impact.
Adjusting individual BIOC or Analytics alert severities changes the weight each detection contributes to incident scoring, so operational impact is reflected accurately. This satisfies the misalignment constraint at the source rather than only at the aggregation layer.
E
Configure Incident Scoring rules to adjust how individual alert weights contribute to overall incident severity.
Incident Scoring rules let the administrator reweight individual alert contributions, directly altering how aggregated alerts roll up into incident severity. This satisfies the misalignment constraint by recalibrating the scoring model to match organisational priority rather than default vendor weightings.

Read the full network assurance explanation →

Question 2hardmultiple choice

An administrator is troubleshooting a scenario where Cortex XDR Agent data is not appearing in the management console. Firewall rules restrict outbound traffic. Which destination port and protocol must be opened outbound from the endpoints to the Cortex XDR management console for agent telemetry?

Trap 1: TCP port 389 and 636

TCP 389 and 636 carry LDAP and LDAPS directory queries, not Cortex XDR agent telemetry, which travels over TCP 443 to the management console. Permitting them leaves agent data blocked. These ports are correct when the agent queries an LDAP directory for user or group resolution.

Trap 2: TCP port 22 and 8080

Cortex XDR agents send telemetry to the management console over TCP 443; port 22 is SSH and 8080 is an alternative HTTP port, neither used for agent check-in. Opening them leaves telemetry blocked. These ports would suit administration or proxy scenarios, not agent-to-console communication.

Trap 3: UDP port 514

UDP 514 carries syslog forwarding, typically from appliances to a collector, not Cortex XDR agent telemetry, which uses TCP 443 to the management console. Allowing 514 leaves agent data blocked. It would be correct when configuring syslog export to an external SIEM.

A
TCP port 389 and 636
Why it fails: TCP 389 and 636 carry LDAP and LDAPS directory queries, not Cortex XDR agent telemetry, which travels over TCP 443 to the management console. Permitting them leaves agent data blocked. These ports are correct when the agent queries an LDAP directory for user or group resolution.
B
TCP port 22 and 8080
Why it fails: Cortex XDR agents send telemetry to the management console over TCP 443; port 22 is SSH and 8080 is an alternative HTTP port, neither used for agent check-in. Opening them leaves telemetry blocked. These ports would suit administration or proxy scenarios, not agent-to-console communication.
C
TCP port 443
TCP 443 outbound satisfies the firewall constraint because Cortex XDR agents transmit telemetry to the management console over TLS-encrypted HTTPS, which uses TCP 443. Permitting this port allows agent registration, heartbeat, and event uploads through restricted egress rules without exposing additional ports.
D
UDP port 514
Why it fails: UDP 514 carries syslog forwarding, typically from appliances to a collector, not Cortex XDR agent telemetry, which uses TCP 443 to the management console. Allowing 514 leaves agent data blocked. It would be correct when configuring syslog export to an external SIEM.

Question 3hardmultiple choice

An XDR engineer needs to automate the enrichment of Cortex XDR incidents with threat intelligence from an external MISP instance. The MISP API requires an authentication key and returns JSON. Which Cortex XDR automation component should be used to create a custom integration that queries MISP and updates incident fields?

Trap 1: Cortex XDR Scripts

Cortex XDR Scripts are primarily used for endpoint response actions and live terminal commands. They are not designed to make external API calls to systems like MISP or to update incident fields with returned JSON data, so they are not suitable for this integration scenario.

Trap 2: Cortex XDR Dashboards

Dashboards are visualization tools for displaying aggregated data and do not execute API calls or modify incident fields. They cannot authenticate to MISP or process JSON responses, so they are not appropriate for building a custom threat intelligence integration in this scenario.

Trap 3: Cortex XDR Playbooks

Playbooks orchestrate automated response workflows but rely on integrations to perform the actual API calls. Without a custom integration to query MISP, a playbook alone cannot authenticate to MISP or parse its JSON responses, so it does not fulfill the requirement in this scenario.

A
Cortex XDR Scripts
Why it fails: Cortex XDR Scripts are primarily used for endpoint response actions and live terminal commands. They are not designed to make external API calls to systems like MISP or to update incident fields with returned JSON data, so they are not suitable for this integration scenario.
B
Cortex XDR Dashboards
Why it fails: Dashboards are visualization tools for displaying aggregated data and do not execute API calls or modify incident fields. They cannot authenticate to MISP or process JSON responses, so they are not appropriate for building a custom threat intelligence integration in this scenario.
C
Cortex XDR Integrations
Cortex XDR Integrations allow engineers to define custom commands that make external API calls, handle authentication, and parse JSON responses. This is the correct component to query MISP using its API key and to update incident fields with the returned threat intelligence in this scenario.
D
Cortex XDR Playbooks
Why it fails: Playbooks orchestrate automated response workflows but rely on integrations to perform the actual API calls. Without a custom integration to query MISP, a playbook alone cannot authenticate to MISP or parse its JSON responses, so it does not fulfill the requirement in this scenario.

Question 4hardmultiple choice

An XDR engineer is tuning the noise generated by a custom BIOC rule that fires on process executions containing the string 'powershell'. The engineer wants to suppress alerts only when the parent process is a known software deployment agent and the command line also contains 'Invoke-WebRequest'. Which mechanism should be used to implement this narrowly scoped exception without disabling the rule?

Trap 1: Configure a suppression window on the BIOC rule so that duplicate…

Suppression windows reduce duplicate alert volume but do not distinguish benign from malicious activity. The deployment agent would still generate one alert per day per endpoint, and genuine malicious powershell activity could be hidden within the same suppression window, so this does not address the root cause of the false positives.

Trap 2: Disable the BIOC rule temporarily and create a separate…

Disabling the original rule removes detection coverage for all malicious uses of powershell, which is unacceptable. Creating a separate low-severity rule does not suppress the noisy alerts from the original rule; it merely adds another detection. This approach sacrifices security visibility instead of performing precise tuning.

Trap 3: Create an Alert Exclusion rule in the Cortex XDR Exclusions policy…

Alert Exclusions in Cortex XDR apply to alerts generated by built-in analytics and endpoint protection modules, not to custom BIOC rules that the engineer authored. Relying on this mechanism would either fail to suppress the custom BIOC alerts or suppress far more than intended, making it unsuitable for this narrowly scoped tuning.

A
Configure a suppression window on the BIOC rule so that duplicate alerts from the same endpoint are collapsed within a 24-hour period.
Why it fails: Suppression windows reduce duplicate alert volume but do not distinguish benign from malicious activity. The deployment agent would still generate one alert per day per endpoint, and genuine malicious powershell activity could be hidden within the same suppression window, so this does not address the root cause of the false positives.
B
Disable the BIOC rule temporarily and create a separate lower-severity rule that only matches the legitimate deployment agent behavior.
Why it fails: Disabling the original rule removes detection coverage for all malicious uses of powershell, which is unacceptable. Creating a separate low-severity rule does not suppress the noisy alerts from the original rule; it merely adds another detection. This approach sacrifices security visibility instead of performing precise tuning.
C
Create an Alert Exclusion rule in the Cortex XDR Exclusions policy that matches the BIOC rule name and the deployment agent process.
Why it fails: Alert Exclusions in Cortex XDR apply to alerts generated by built-in analytics and endpoint protection modules, not to custom BIOC rules that the engineer authored. Relying on this mechanism would either fail to suppress the custom BIOC alerts or suppress far more than intended, making it unsuitable for this narrowly scoped tuning.
D
Modify the BIOC rule condition to add an exclusion clause matching the deployment agent as parent process and 'Invoke-WebRequest' in the command line.
Adding a narrowly scoped exclusion clause directly inside the BIOC rule condition preserves the original detection logic for all other cases while preventing alerts only for the specific combination of parent process and command-line content. This is the most precise tuning method and keeps the rule active for genuine threats.

Question 5easymulti select

An administrator is planning an automated deployment of Cortex XDR agents using an enterprise software distribution tool. Which TWO advantages does using an MSI package offer over an EXE package in this scenario? (Choose two)

Trap 1: Built-in capability to execute shell scripts on Linux servers

MSI is a Windows Installer package format; it carries no Linux shell-script execution capability, and Cortex XDR deploys to Linux via RPM or DEB packages instead. It is tempting because MSI supports custom actions, which can run scripts, but those actions execute on Windows only and are not a cross-platform deployment mechanism.

Trap 2: Automatic conversion of EXE payloads into macOS PKG files

MSI is a Windows-only packaging standard and cannot convert EXE payloads into macOS PKG files; macOS deployment requires a separate PKG built for that platform. It is tempting because MSI and PKG both support silent, scriptable installation, so administrators may assume one format can be transformed into the other.

Trap 3: Exemption from all Windows User Account Control (UAC) prompts…

MSI packages still trigger UAC elevation when they write to protected locations or install services; administrative rights are required, and no package format grants blanket UAC exemption. It is tempting because silent installation via msiexec with /qn suppresses prompts during deployment, but that relies on the distribution tool already running with elevated privileges.

A
Standardized installation parameters and property passing (e.g., /qn, /norestart)
MSI packages support standardised command-line properties such as /qn and /norestart, letting the distribution tool deploy silently and suppress reboots. This enables unattended, consistent installation across the estate, unlike EXE installers whose parameters vary by vendor.
B
Built-in capability to execute shell scripts on Linux servers
Why it fails: MSI is a Windows Installer package format; it carries no Linux shell-script execution capability, and Cortex XDR deploys to Linux via RPM or DEB packages instead. It is tempting because MSI supports custom actions, which can run scripts, but those actions execute on Windows only and are not a cross-platform deployment mechanism.
C
Automatic conversion of EXE payloads into macOS PKG files
Why it fails: MSI is a Windows-only packaging standard and cannot convert EXE payloads into macOS PKG files; macOS deployment requires a separate PKG built for that platform. It is tempting because MSI and PKG both support silent, scriptable installation, so administrators may assume one format can be transformed into the other.
D
Native support for application transforms (.MST files) for customization
MSI packages support transforms (.MST files), letting the distribution tool apply environment-specific customisations such as installation keys, server addresses, or proxy settings at deployment time without repackaging the base installer, which EXE-based installers cannot do natively.
E
Exemption from all Windows User Account Control (UAC) prompts without admin rights
Why it fails: MSI packages still trigger UAC elevation when they write to protected locations or install services; administrative rights are required, and no package format grants blanket UAC exemption. It is tempting because silent installation via msiexec with /qn suppresses prompts during deployment, but that relies on the distribution tool already running with elevated privileges.

Review the full routing breakdown →

Question 6hardmulti select

An administrator is planning a Cortex XDR deployment across a segmented network architecture where endpoints reside in a zone without direct internet access, but have access to a local proxy. Which TWO configuration steps are required to route agent traffic through this proxy? (Choose two)

Trap 1: Disable TLS encryption on the proxy to allow raw packet inspection…

Disabling TLS breaks secure communication between the agent and the cloud tenant.

Trap 2: Change the endpoint default gateway to point directly to the Cortex…

Default gateways operate at Layer 3 and cannot route traffic directly to cloud management consoles without proper IP routing.

Trap 3: Install a local Microsoft Exchange server on the proxy to handle…

Exchange servers are unrelated to proxy routing for Cortex XDR agents.

A
Disable TLS encryption on the proxy to allow raw packet inspection of agent heartbeats
Why it fails: Disabling TLS breaks secure communication between the agent and the cloud tenant.
B
Specify the proxy server address and port during the agent installation command or via agent settings
Endpoints without direct internet access must forward agent traffic to the local proxy. Supplying the proxy address and port during installation, or through agent settings, directs that traffic correctly, satisfying the segmented-network constraint without requiring direct egress.
C
Change the endpoint default gateway to point directly to the Cortex XDR management console
Why it fails: Default gateways operate at Layer 3 and cannot route traffic directly to cloud management consoles without proper IP routing.
D
Install a local Microsoft Exchange server on the proxy to handle email-based alert notifications
Why it fails: Exchange servers are unrelated to proxy routing for Cortex XDR agents.
E
Configure the local proxy to allow outbound HTTPS (TCP 443) traffic to the Cortex XDR cloud URLs/FQN Ds
The proxy must be permitted to reach Cortex XDR cloud FQDNs over outbound HTTPS on TCP 443; otherwise agents in the isolated zone cannot register, fetch policies, or upload telemetry, so this egress rule is a required configuration step.

Question 7hardmulti select

An administrator is planning the deployment of Cortex XDR agent tamper protection. Which TWO administrative actions or scenarios are protected against when tamper protection is enabled on endpoints? (Choose two)

Trap 1: Standard user printing jobs sent to network printers

Printing is unrelated to agent integrity; tamper protection guards the Cortex XDR agent's processes, files and services against unauthorised modification or removal. It is tempting as an endpoint activity, but print spooling neither alters nor disables the agent, so no protection applies.

Trap 2: Normal operating system scheduled reboots initiated by the system…

Administrator-initiated reboots are a legitimate operating system function and do not constitute tampering with the agent; protection targets attempts to stop, delete or alter it. It is tempting because reboots affect the agent's running state, yet authorised system restarts are not blocked.

Trap 3: Standard automatic content updates pushed by the authorized Cortex…

Tamper protection blocks local attempts to disable, uninstall or modify the agent; authorised cloud-delivered content updates are explicitly permitted and must continue. It is tempting because updates touch the agent, but they originate from the trusted tenant, so protection does not obstruct them.

A
Standard user printing jobs sent to network printers
Why it fails: Printing is unrelated to agent integrity; tamper protection guards the Cortex XDR agent's processes, files and services against unauthorised modification or removal. It is tempting as an endpoint activity, but print spooling neither alters nor disables the agent, so no protection applies.
B
Normal operating system scheduled reboots initiated by the system administrator
Why it fails: Administrator-initiated reboots are a legitimate operating system function and do not constitute tampering with the agent; protection targets attempts to stop, delete or alter it. It is tempting because reboots affect the agent's running state, yet authorised system restarts are not blocked.
C
Standard automatic content updates pushed by the authorized Cortex XDR cloud tenant
Why it fails: Tamper protection blocks local attempts to disable, uninstall or modify the agent; authorised cloud-delivered content updates are explicitly permitted and must continue. It is tempting because updates touch the agent, but they originate from the trusted tenant, so protection does not obstruct them.
D
Unauthorized deletion of Cortex XDR agent files, directories, or critical registry keys
Tamper protection enforces kernel-level and file-system restrictions that block modification of the agent's own binaries, directories and registry keys. This directly satisfies the scenario's need to prevent unauthorised deletion, preserving agent integrity so endpoint protection cannot be silently removed.
E
Unauthorized attempts by local users or malware to stop or disable the Cortex XDR agent services
Tamper protection intercepts service-control requests, preventing local users or malware from stopping or disabling the Cortex XDR agent services. This satisfies the scenario's requirement to keep the agent continuously running, since a stopped service would halt endpoint detection and response entirely.

Question 8mediummultiple choice

An XDR engineer needs to create a scheduled report in Cortex XDR that delivers a daily PDF summary of all critical alerts to the security leadership team. The report must include a breakdown of alerts by severity and a trend chart over the last 7 days. Which component of Cortex XDR should the engineer use to configure this?

Trap 1: Report Templates

Report Templates in Cortex XDR are used to define the layout and content of a report, but they do not schedule or deliver reports. They are a building block, not the scheduling mechanism. The engineer needs a feature that handles both the template and the recurring delivery to stakeholders.

Trap 2: Dashboard Widgets

Dashboard Widgets are visual components for real-time monitoring within the Cortex XDR console. They do not support scheduled email delivery of PDF reports. While they can show trends, they lack the scheduling and distribution capabilities required for daily executive summaries.

Trap 3: XQL Scheduled Queries

XQL Scheduled Queries are used to run XQL queries on a schedule and trigger alerts or actions based on results. They do not generate formatted PDF reports with charts and severity breakdowns for email delivery. This feature is for detection and automation, not executive reporting.

A
Report Templates
Why it fails: Report Templates in Cortex XDR are used to define the layout and content of a report, but they do not schedule or deliver reports. They are a building block, not the scheduling mechanism. The engineer needs a feature that handles both the template and the recurring delivery to stakeholders.
B
Dashboard Widgets
Why it fails: Dashboard Widgets are visual components for real-time monitoring within the Cortex XDR console. They do not support scheduled email delivery of PDF reports. While they can show trends, they lack the scheduling and distribution capabilities required for daily executive summaries.
C
XQL Scheduled Queries
Why it fails: XQL Scheduled Queries are used to run XQL queries on a schedule and trigger alerts or actions based on results. They do not generate formatted PDF reports with charts and severity breakdowns for email delivery. This feature is for detection and automation, not executive reporting.
D
Scheduled Reports
Scheduled Reports in Cortex XDR allow an engineer to define a report template, set a recurrence (e.g., daily), and specify email recipients. This directly meets the requirement to deliver a daily PDF summary to leadership, including severity breakdown and trend charts, without manual intervention.