Select Two (Multi-Select) Questions

Manually compile the source code of the role policy into a JSON manifest and push it via the REST API.

Why it fails: Cortex XSIAM roles are built through the console's role and scope configuration, not by hand-authoring policy source and pushing manifests over REST. API-driven policy deployment suits infrastructure-as-code pipelines managing many tenants, but the question asks for the two console steps that define a custom role and its data scopes.

Install an additional XSOAR engine on each analyst workstation to enforce local authorization checks.

Why it fails: XSOAR engines execute playbooks and integrations; they hold no role definitions or data-scope mappings, so installing one per workstation enforces nothing. Engines would be the right component when you need to run automation actions on endpoints or in a segregated network segment, not to segregate Cortex XSIAM data access.

Reboot all Broker VMs in the region to propagate the new role definitions to local log collectors.

Why it fails: Broker VMs mediate communication between Cortex XSIAM and local log collectors; they do not store or distribute RBAC role definitions, so rebooting them changes no permissions. Brokers would be relevant when onboarding collectors or troubleshooting connectivity, not when assigning roles and data scopes to regional teams.

Manual CSV file upload via the user profile page

Why it fails: The user profile page handles personal settings and authentication, offering no ingestion pipeline; CSV uploads belong to the data management interface instead. Manual upload is tempting for one-off imports, and would be right for a small static lookup table, not continuous third-party log feeds.

Direct database replication via SQL Server Management Studio

Why it fails: XSIAM ingests through brokers, agents and API-based collectors; direct SQL replication bypasses those and is unsupported. It is tempting because database replication is standard for warehousing, and would be right when mirroring operational tables into an analytics store rather than feeding a security platform.

Physical serial cable connection to the XSIAM tenant gateway

Why it fails: XSIAM brokers receive logs over network protocols such as syslog, HTTP and API calls; no serial interface exists on tenant gateways. Serial cabling is tempting from console-based device administration, and would be correct for out-of-band management of network hardware, not log ingestion.

Always query all historical datasets without time limits to ensure completeness.

Why it fails: Querying all historical datasets without time bounds scans the entire retention window, multiplying data processed and latency. It is tempting when completeness is feared, yet XQL performs best when a narrow time range is specified; unbounded searches suit rare forensic hunts, not routine optimisation.

Avoid using any filters and sort by random strings.

Why it fails: Removing filters forces XQL to scan every record, and random sorting adds pointless processing, both inflating query cost across large datasets. It is tempting when an analyst wants unfiltered exploration, but targeted field filters and meaningful ordering are what actually reduce scanned data.

Execute all searches using raw regex parsing on unparsed datasets.

Why it fails: Raw regex on unparsed datasets bypasses normalised fields and indexes, forcing full-text scanning and heavy CPU use. It is tempting for irregular formats lacking parsers, but parsed fields with structured filters are what accelerate XQL; regex belongs to one-off extraction from unmodelled logs.

Copy the browser cookies of the analyst's session.

Why it fails: Browser cookies only hold a live session token; they carry no dashboard definition and expire, so nothing is portable. Session cookies matter when troubleshooting authentication or replaying a user's console state, not for backing up or migrating content between XSIAM environments.

Print physical paper copies of the dashboard screens.

Why it fails: Paper printouts capture a static image, losing the underlying query, layout and widget configuration needed to recreate a dashboard elsewhere. Printing suits sharing a snapshot in a report or meeting, but cannot restore or migrate content between XSIAM tenants.

Manually retype every XQL query into a notepad file on a local workstation without export tools.

Why it fails: Retyping XQL queries by hand into a notepad file is error-prone and captures no dashboard layout, so it is not a portability option. It tempts when no export tooling is available, yet XSIAM provides supported export and import for content migration.

Automatic creation of API keys for third-party tools.

Why it fails: The XDM standardises field names and values for correlation and querying; it does not generate credentials for external integrations. API key creation is tempting because onboarding third-party tools needs authentication, and would be correct for an integration or marketplace configuration step, not the data model itself.

Automatic translation of all log content into English.

Why it fails: The XDM normalises fields into a common schema so disparate sources correlate consistently; it does not translate log text into English. Translation is tempting because normalisation sounds linguistic, and would be correct for a localisation feature, not a data model whose purpose is field-level standardisation across vendors.

Manually telnetting into port 23 of every server to trigger the built-in operating system agent installer service.

Why it fails: Telnet on port 23 is an unencrypted interactive terminal protocol with no agent-installer service behind it; XSIAM deploys agents through packages, scripts, or management consoles. It tempts as a remote-access shortcut, but telnet suits legacy device administration, never automated agent rollout.

Flashing the server BIOS with a specialized firmware image that contains the embedded XSIAM kernel driver.

Why it fails: BIOS firmware cannot host an XSIAM kernel driver; agents install at the operating-system layer through supported packages, not motherboard flashing. Firmware images are the correct mechanism for hardware-level management or boot integrity, not endpoint agent deployment.

Physically connecting a USB thumb drive containing the master cryptographic key to each server's motherboard.

Why it fails: USB drives and master cryptographic keys have no role in agent installation; XSIAM distributes agents via software packages and central management, with keys handled internally. Physical media suits air-gapped environments lacking network paths, which corporate servers here are not.

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.

Recompiling the Cortex XDR agent kernel extension on all endpoints

Why it fails: Kernel extensions belong to endpoint agent telemetry, not log-source onboarding; parsing a third-party firewall feed requires a data-source integration and parser configuration in Cortex XSIAM. Recompiling agents is tempting when endpoint data collection misbehaves, which is when kernel-level agent components genuinely need rebuilding.

Flushing the browser cache of all SOC analysts

Why it fails: Browser cache holds analyst UI content and has no bearing on how Cortex XSIAM parses ingested firewall logs or generates alerts. Clearing it is tempting because stale cached console pages can display outdated dashboards, so it is a legitimate fix for UI rendering problems, not data ingestion.

Manually modifying the cloud data lake kernel source code via SSH

Why it fails: Cortex XSIAM parses third-party firewall logs through Broker VM log-forwarding configurations and built-in or custom parsers, not by editing the cloud data lake kernel. It is tempting because kernel-level tuning exists for performance work, but SSH access to the data lake is neither exposed nor required for onboarding a log source.

Deploy a physical hardware appliance in every AWS Availability Zone.

Why it fails: XSIAM collects S3 logs through API-based cloud ingestion, requiring no on-premises hardware. Deploying an appliance per Availability Zone adds cost and management without enabling bucket ingestion. Physical appliances are relevant when collecting logs from isolated on-premises networks that cannot reach XSIAM directly over the internet.

Configure the local Windows registry on the administrator workstation to route AWS traffic.

Why it fails: Windows registry settings on an administrator workstation do not influence XSIAM's cloud ingestion path; the broker or data source configuration handles AWS authentication and polling. Registry edits are relevant for endpoint agent behaviour or proxy settings on managed hosts, not for connecting XSIAM to an S3 bucket.

Manually install the Cortex XDR Agent on the AWS S3 root server.

Why it fails: AWS S3 is object storage with no host operating system, so a Cortex XDR Agent cannot be installed on it. XSIAM ingests bucket logs by configuring a cloud storage data source with appropriate IAM roles or access keys and API-based polling. Agent installation applies to endpoint log collection from Windows, macOS or Linux hosts.

Manually connect a serial console cable to every server in the data center.

Why it fails: Cortex XDR agent deployment is performed through the management console, installing packages on each endpoint OS; a serial console cable gives out-of-band terminal access to a single server's firmware or bootloader, not agent rollout. It is tempting when imaging or recovering a headless server that will not boot, where serial access is genuinely required.

Disable all firewall rules on the XSIAM cloud tenant.

Why it fails: Disabling firewall rules on the cloud tenant removes the protections agents rely on and is never a deployment task. It tempts as a troubleshooting shortcut when connectivity fails, but the correct approach is allowing required agent and management traffic through existing rules.

Physical network firewall bypass rules

Why it fails: Firewall bypass rules govern packet routing, not log parsing or field mapping, so they contribute nothing to normalising a custom application's events. They are tempting when ingestion traffic is blocked, but broker configuration, parsers and data models are the actual pipeline components.

Manually executed SQL queries for every incoming log packet

Why it fails: Manually running SQL per log packet cannot scale to streaming ingestion and provides no parsing or schema-mapping function. It is tempting to administrators comfortable with query languages, but the pipeline relies on automated brokers, parser rules and normalisation mappings instead.

Direct physical access to the server motherboard to install a hardware crypto-accelerator card.

Why it fails: XSIAM engine prerequisites cover CPU, memory, disk and network capacity, not physical hardware modification; a crypto-accelerator card is not required and cannot be validated as a software readiness check. It is tempting because hardware security modules appear in some security deployments, but XSIAM engines rely on software-based cryptography.

Disabling all host system firewalls and SELinux entirely across the corporate datacenter.

Why it fails: Disabling firewalls and SELinux datacentre-wide is neither a prerequisite nor acceptable; engines require specific ports opened and SELinux left in a supported state. It is tempting because some installations relax local security controls, but XSIAM documents targeted port and policy requirements rather than wholesale disabling.

Active Directory Domain Controller role installed on the same host operating system.

Why it fails: XSIAM engines are standalone appliances that must not share a host with a domain controller; the DC role consumes resources and conflicts with the engine's supported operating system baseline. It is tempting because Cortex products integrate with Active Directory for identity data, but that integration is remote, not co-hosted on the engine.

Store all raw logs exclusively on local Broker VM hard drives without cloud replication.

Why it fails: Local-only storage removes the offsite copy that disaster recovery requires, so a Broker VM disk failure loses raw logs permanently; cloud replication or forwarding to a secondary location preserves them. It tempts as a latency and cost measure, which would suit isolated air-gapped networks where external replication is prohibited.

Disable all automated correlation rules to conserve disaster recovery bandwidth.

Why it fails: Disabling correlation rules removes detection coverage rather than protecting availability, and correlation consumes negligible ingestion bandwidth. It is tempting because reducing load sounds protective during failover, but high availability requires redundant Brokers, tested failover, and resilient ingestion paths, not suppressed detections.

Use the same Broker VM to collect logs from all data centers over the WAN.

Why it fails: Collecting logs from all data centers over the WAN to a single Broker VM introduces latency, bandwidth consumption, and a single point of failure. It is not a scalable or highly available design. This option fails because it centralizes log collection inefficiently and does not provide redundancy.

Deploy a single Broker VM with a load balancer to handle all log sources.

Why it fails: A single Broker VM, even with a load balancer, represents a single point of failure and may not scale to handle the log volume from multiple data centers. Load balancers distribute incoming connections but do not provide redundancy for the Broker VM itself. This option fails because it does not meet high availability and scalability requirements.

Configure each Broker VM with identical resource specifications to simplify management.

Why it fails: While identical specifications can simplify management, they are not critical for high availability and scalability. The resource specifications should be based on the expected log volume at each site, which may vary. Using identical specs might lead to over-provisioning or under-provisioning. This option fails because it does not directly address the requirements for HA and scalability.

Ensuring the Broker VM has local administrative write access to all ingested network switches

Why it fails: Broker VMs collect and forward logs; they do not require administrative write access to switches, only read access or syslog forwarding. It is tempting because administrative credentials appear to guarantee complete ingestion, and would be needed only when the broker itself must change switch configuration.

Configuring local XSOAR database persistence exceeding 50 Terabytes on the Broker VM

Why it fails: Broker VMs buffer and forward telemetry; they are not XSOAR database hosts, and 50 TB of local persistence far exceeds their storage role. It is tempting because large local buffers appear to protect against outages, and such persistence belongs on the XSOAR database server instead.

Deploying a separate Windows Active Directory domain controller on each Broker VM

Why it fails: Broker VMs are lightweight collectors and forwarders; hosting a domain controller on each adds unnecessary roles, patching and attack surface. It is tempting because isolated segments seem to need local authentication, and a domain controller would be correct where that segment genuinely requires directory services.

Requiring all end users to manually rewrite their local operating system kernels

Why it fails: Requiring end users to rewrite local OS kernels is an impossible, irrelevant task that no XSIAM rollout needs. It tempts as a hardening-sounding action, but deployment planning covers endpoint agent installation, log ingestion and phased change windows, not kernel modification.

Replacing all physical network switches with fiber-optic hubs

Why it fails: Replacing switches with fibre-optic hubs is a network hardware refresh unrelated to XSIAM deployment planning. It tempts as an infrastructure modernisation task, but rollout planning concerns agent deployment, data source onboarding and change-window scheduling, not physical media replacement.

Local printer ink levels on managed workstations

Why it fails: Printer ink levels are hardware telemetry unrelated to agent health, and XSIAM's Endpoint Management view surfaces agent-centric metrics such as connectivity, version and status. Consumable monitoring belongs to print management tooling, not endpoint agent administration.

Individual employee Wi-Fi password history

Why it fails: Wi-Fi password history is credential data, not an agent health metric, and the Endpoint Management view reports agent state such as last connection, version and operational status. Credential auditing belongs to identity protection tooling, not endpoint agent monitoring.

Personal email login credentials stored in browser caches

Why it fails: Browser-cached personal email credentials are user data, not an agent health status, and XSIAM's Endpoint Management view reports agent state such as last seen, version and operational status. Credential discovery belongs to identity or exposure management, not endpoint agent monitoring.

Broker VM hardware CPU allocation limits

Why it fails: Broker VM CPU allocation is set when deploying or sizing the broker appliance, not within a parsing rule, which only handles field extraction and mapping. It tempts because Broker VMs do collect and forward logs, so their resources feel related to ingestion, but hardware limits are configured in broker deployment settings.

Automatic remediation playbook execution ID

Why it fails: Parsing rules define how raw log fields are extracted and mapped; a remediation playbook ID belongs to response automation, not ingestion parsing. It tempts because XSIAM couples detection with automated response, so playbook identifiers appear throughout the platform, but they are configured in playbook or alert-mapping settings, not in a parsing rule.

Enable the Correlation Engine in the XSIAM settings.

Why it fails: The Correlation Engine is a core component of XSIAM and is enabled by default; there is no separate toggle to enable it. While correlation rules must be configured, the engine itself is always active. This distractor is plausible because administrators might assume a feature needs activation, but in XSIAM, correlation is inherent to the platform's analytics.

Enable User Behavior Analytics (UBA) for all users.

Why it fails: While UBA can enhance detection by profiling user behavior, it is not a prerequisite for basic event correlation. Correlation can function without UBA, focusing on event patterns. Enabling UBA is an additional analytics feature that may be useful but is not required to enable correlation across data sources. Thus, it is not one of the two required actions.

Install a separate correlation server on-premises.

Why it fails: XSIAM is a cloud-native platform where correlation is performed in the cloud; no on-premises correlation server is needed. Installing such a server is not part of the architecture and would not integrate with XSIAM's built-in capabilities. This option is a distractor based on legacy SIEM deployments where separate correlation engines might exist.

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.