Operations And Lifecycle Management practice questions

Review the Audit Trail dashboard for high-frequency API polling events.

Why it fails: Incorrect. The Audit Trail records administrative actions within XSIAM, not data volume ingestion statistics.

Execute an XQL query using the `dataset = host_inventory` command and group by storage size.

Why it fails: Incorrect. Ingestion metrics and license usage are tracked in dedicated license management views, not generic host inventory datasets.

Check the Cortex XDR Agent health status page under Endpoint Management.

Why it fails: Incorrect. Endpoint Management tracks agent status and versions, not overall tenant log ingestion volume.

SSH into the Cortex XSIAM management cluster master node and check the /var/log/parser.log file.

Why it fails: Incorrect. Administrators do not have direct SSH access to the underlying XSIAM cloud management infrastructure.

Open the Cortex XDR Agent console on the local machine and export the Agent Log Collector bundle.

Why it fails: Incorrect. The Agent Log Collector is for endpoint agent troubleshooting, not cloud-side custom parser validation.

Review the Incident Graph to trace dropped packets from the ingestion pipeline.

Why it fails: Incorrect. Incident graphs are for security investigations, not low-level log parsing debug.

Update the Log Forwarding profile timeout threshold.

Why it fails: Log Forwarding profiles govern how logs are routed to external destinations; they hold no session or authentication parameters. It is tempting because it is an administrator-editable profile, and would be correct for tuning log export behaviour, but the idle web session timeout lives in the authentication or session configuration instead.

Modify the Agent Settings profile assigned to the administrator's laptop.

Why it fails: Agent Settings profiles configure endpoint agent behaviour on managed hosts, not browser sessions against the XSIAM console. It is tempting because it is scoped to the administrator's own laptop, and would be right for agent collection or protection tuning, but the web interface timeout is a server-side session setting.

Edit the XQL query execution limit parameters in Analytics settings.

Why it fails: XQL execution limits cap query runtime and result volume; they do not control authentication session lifetime. It is tempting because Analytics settings are administrator-editable and query timeouts sound session-related, but the idle web interface timeout is configured in the console's session or authentication settings, not query parameters.

Set up a local cron job on each Broker VM to archive logs to local hard drives.

Why it fails: Extended retention is configured in the Cortex XSIAM data retention settings, which govern how long datasets remain queryable in the platform; a Broker VM cron job only copies logs to local disk, leaving them outside XSIAM and unsearchable. It is tempting for offline archival, where local storage genuinely preserves raw logs.

Modify the global license key string to unlock extended storage capacities.

Why it fails: Retention periods are set through Cortex XSIAM's data retention policy configuration, not through the licence key, which only governs entitlements and never storage duration. It is tempting because licences do control ingest volume and feature access, so administrators associate licence changes with capacity limits rather than policy settings.

Create an automated XSOAR playbook to export raw logs to local USB drives daily.

Why it fails: XSOAR playbooks orchestrate response actions; exporting raw logs to USB drives bypasses XSIAM's retention controls and creates unmanaged copies. It is tempting because XSOAR automation is the correct tool for enrichment and remediation workflows, but retention periods are configured in the XSIAM data retention settings, not via playbook exports.

Paste the certificate into the custom CSS styling box under Global Settings.

Why it fails: The CSS styling box only alters the console's visual appearance; it cannot hold certificates or supply them to an outbound TLS handshake. CSS fields are correct for customising interface colours and branding, not for storing mTLS client credentials used by integrations.

Store the certificate in the Broker VM local `/etc/passwd` file.

Why it fails: /etc/passwd stores local user account records, not X.509 certificates or private keys, so the webhook cannot load a client identity from it. That file is relevant when managing Linux user accounts, not when configuring mutual TLS credentials for an integration.

Install the certificate in the local browser certificate store of the analyst viewing the incident.

Why it fails: A browser certificate store holds certificates for the analyst's own TLS sessions, not for XSIAM's server-side webhook client, so the outbound mTLS handshake would present nothing. Browser stores are correct for user-authenticated web access requiring a personal client certificate.

Configure the Agent Software Upgrade schedule under Endpoint Management.

Why it fails: Incorrect. Agent upgrades govern endpoint software, not API keys.

Adjust the Broker VM Docker container memory limit.

Why it fails: Incorrect. Container memory limits relate to server performance, not API keys.

Modify the XQL query timeout threshold.

Why it fails: Incorrect. Query timeout thresholds govern search runtimes, not API token validity.

Disable all custom correlation rules to prevent them from interfering with the upgrade process.

Why it fails: Disabling rules does not protect them from being altered or lost during an upgrade, nor does it provide a way to restore them. It also leaves the environment vulnerable to missed detections. The correct approach is to back up the entire configuration, not to disable critical detections.

Schedule the upgrade during a maintenance window without any backup, since Cortex XSIAM upgrades are always non-destructive.

Why it fails: While Cortex XSIAM upgrades are designed to be non-destructive, unexpected issues can still occur, and having a backup is a best practice for rollback. Relying solely on the non-destructive nature is risky because customizations might be affected by schema changes or deprecated features. Always back up before upgrading.

Manually copy all custom correlation rules and playbooks to a text file for later re-import.

Why it fails: Manually copying rules and playbooks is error-prone and does not capture dependencies, dashboard layouts, or system settings. It also fails to provide a rollback mechanism for the entire tenant. The Backup and Restore feature is the supported method to preserve and restore all customizations in a consistent manner.

In the Cortex XSIAM management console, navigate to Settings > Configurations > System Settings and change the audit log retention in the Logging section.

Why it fails: System Settings typically contains general system parameters like time zone, session timeout, and email notifications. It does not include a Logging section for audit log retention. The correct place is the dedicated Data Retention page, which centralizes retention policies for all data types, including audit logs.

In the Cortex XSIAM management console, navigate to Settings > Configurations > Access Management and modify the audit log retention under the User Roles section.

Why it fails: Access Management is used to configure user roles, permissions, and authentication settings, not data retention. Audit log retention is not found under User Roles. The correct location is the Data Retention section under Configurations. Modifying access management settings would not affect how long audit logs are stored.

In the Cortex XSIAM management console, navigate to Settings > Configurations > Data Sources and edit the retention for the Audit Logs data source.

Why it fails: Data Sources configuration is used to onboard and manage log sources, such as syslog or API integrations. While it may include settings for parsing and ingestion, it does not control the global retention period for audit logs. The retention period is a separate global setting under Data Retention, not per data source.

Use the Cortex XSIAM API to poll for malware alerts and then manually run the script.

Why it fails: Polling via API introduces delay and requires custom code, and it is not an automated native component. Manual execution defeats the purpose of automation. This approach is inefficient and error-prone compared to using built-in automation capabilities.

Create a BIOC rule that directly executes the remediation script on the endpoint.

Why it fails: BIOC (Behavioral Indicator of Compromise) rules are used for detection, not for direct script execution. While they can trigger alerts or playbooks, they do not natively run remediation scripts on endpoints. A playbook triggered by a correlation rule is the appropriate mechanism.

Configure a scheduled report to run the remediation script on all endpoints daily.

Why it fails: Scheduled reports are for generating and distributing reports, not for executing remediation actions. They cannot run scripts on endpoints, and running daily would not be triggered by malware detection, violating the requirement for immediate, event-driven remediation.

Configure the agent to check for updates via the Update Server setting in the agent configuration profile.

Why it fails: The Update Server setting specifies the server from which the agent downloads updates, but it does not enable automatic upgrades by itself. The agent must still be configured to allow upgrades, which is done in the console. This option alone is insufficient.

Manually download the latest agent installer and deploy it to each endpoint via Group Policy.

Why it fails: Manual deployment is time-consuming and error-prone, and it does not provide automatic updates. It also requires external tools like Group Policy, which may not cover all operating systems. This approach does not meet the requirement for automatic updates.

Create a scheduled playbook that runs a script on all endpoints to download and install the latest agent.

Why it fails: While a playbook could automate installation, it is not the native mechanism for agent upgrades and may conflict with agent management. It also requires custom scripting and may not handle version checks properly. The built-in automatic upgrade is more reliable and supported.

Use the 'Audit Trail' to manually revert changes by reapplying the previous configuration from logs.

Why it fails: The Audit Trail records changes but does not offer a one-click rollback for correlation rules. Manually reconstructing a previous state from audit logs is time-consuming and risks introducing errors. It is not a reliable method for automated reversion and is not designed for that purpose.

Enable the 'Version Control' setting in the correlation rule configuration and set a retention period.

Why it fails: Version Control is not a native feature within XSIAM correlation rules. While XSIAM supports content versioning through its management interface, it is not enabled per-rule with a retention period. This option misrepresents the platform's capabilities and would not provide the desired automated rollback for a specific rule.

Configure a scheduled job in the XSIAM CLI to export the rule to an external repository every hour.

Why it fails: While scheduled exports can back up rule definitions, they do not provide an integrated rollback mechanism within XSIAM. Restoring would require manual import, which is inefficient and error-prone. This approach does not meet the requirement for automatic reversion and is not a standard practice for rule-level versioning.

Open a support ticket requesting a compatibility audit of all custom content and wait for the vendor to confirm readiness.

Why it fails: While support can assist, opening a ticket and waiting is not the first action an administrator should take. The administrator can and should independently review the Release Notes and Compatibility Matrix. Waiting on support introduces delay and may not cover all custom content. This choice reflects a passive approach that does not meet the requirement to verify compatibility proactively before the upgrade.

Export all custom playbooks to a local archive, then delete them before the upgrade to avoid conflicts.

Why it fails: Deleting custom playbooks before an upgrade is destructive and unnecessary. The correct approach is to verify compatibility, not remove content. Exporting is a good backup practice, but deleting playbooks would disable active automations and incident response workflows, causing operational gaps during and after the upgrade window without solving compatibility concerns.

Run the built-in Upgrade Readiness Report from the Marketplace and apply all recommended fixes automatically.

Why it fails: The Marketplace does not include an automated Upgrade Readiness Report that applies fixes. The Marketplace is for installing and updating content packs and integrations, not for assessing tenant upgrade readiness. Relying on this would leave the administrator unaware of deprecated APIs or breaking changes documented in the Release Notes, risking playbook and integration failures after the upgrade.

XSIAM Manager

Why it fails: XSIAM Manager is not a component name in the XSIAM architecture. XSIAM is a cloud-delivered platform managed through the Cortex XSIAM console. There is no separate 'XSIAM Manager' service that handles agent telemetry routing. This distractor may confuse administrators familiar with on-premises management servers from other products.

Cortex Data Lake

Why it fails: Cortex Data Lake is the underlying storage and analytics layer for XSIAM, not the component that routes endpoint telemetry. While data ultimately lands in Cortex Data Lake, the agent's data path does not directly interact with it. The issue described is about data not being routed, so checking the data lake would not resolve the missing telemetry from a newly onboarded agent.

XSIAM Collector

Why it fails: The XSIAM Collector is used for ingesting logs from external sources such as syslog or API-based feeds, not for receiving endpoint agent telemetry. Endpoint agents communicate through the Broker VM or directly to the XSIAM cloud. Configuring the Collector would not address why the agent's data is missing from the console.

Re-ingest the raw logs from the original data sources to rebuild the dataset.

Why it fails: Re-ingesting logs would require access to the original raw data and would not restore the dataset exactly as it was, including any enrichments or modifications. This approach is time-consuming and may not be feasible if the raw logs are no longer available or if the dataset contained processed data. It does not leverage the existing backup and is not the recommended recovery method.

Use the API endpoint /public_api/v1/backup/restore_dataset to restore the dataset programmatically.

Why it fails: Cortex XSIAM does not expose a public API endpoint specifically for restoring individual datasets. While XSIAM has extensive APIs, backup and restore operations are performed through the management console's Backup & Restore page. This distractor is plausible because APIs exist for many tasks, but this particular endpoint is not part of the XSIAM API surface.

Restore the entire tenant configuration and data from the backup, overwriting all current data.

Why it fails: While a full tenant restore is possible, it would revert all datasets and configurations to the state two days ago, causing loss of any legitimate changes made since then. This is overly destructive for a single dataset deletion. XSIAM provides more granular options, so this brute-force method is not the best choice and may cause additional operational disruption.

Instance Administrator

Why it fails: The Instance Administrator role is a high-level administrative role that includes managing users, roles, and system settings. It would grant the analyst excessive permissions, such as the ability to modify correlation rules and delete incidents, which is not desired.

Account Administrator

Why it fails: The Account Administrator role has full permissions, including user management, system configuration, and the ability to modify or delete any object. Assigning this role would violate the principle of least privilege because the analyst would have far more access than needed, including the ability to alter correlation rules and delete incidents.

Viewer

Why it fails: The Viewer role provides read-only access to most areas, including incidents and queries. However, it does not allow running queries that might require write operations or saving query results. The requirement includes running queries, which may imply the ability to execute and save queries, so Viewer is too restrictive.

Settings > Configurations > Licensing

Why it fails: This path does not exist in the current XSIAM interface. Licensing information is not found under Configurations; that section contains general platform settings such as data retention and indexing. Attempting to locate license details here would waste time and lead to confusion, as the actual license status is displayed in a dedicated area accessible from the main navigation.

Settings > Health & Monitoring > License Status

Why it fails: While Health & Monitoring provides system health metrics, it does not include license capacity or expiration details. License information is separate from health monitoring, which focuses on component status, performance, and data ingestion rates. An engineer looking here would not find the subscription expiration date or remaining license capacity, and would need to navigate elsewhere.

Dashboard > System Overview

Why it fails: The Dashboard provides high-level security metrics and incident trends, not license details. System Overview widgets may show data ingestion volume, but they do not display license expiration or capacity limits. An engineer relying on the dashboard would not obtain authoritative licensing information and might overlook an impending expiration, risking service disruption.

Edit the Broker VM log forwarding configuration to drop endpoint telemetry events after 30 days by adding an age-based filter on the collector.

Why it fails: A Broker VM forwards or collects logs; it does not store them for 30 days and then release them. Age-based filters on the collector would prevent ingestion entirely rather than purge already-stored data, and they would also block fresh events once they age. This approach fails to meet the requirement because retention applies to stored datasets, not to the forwarding layer.

In the Cortex Data Lake tenant settings, adjust the ingestion license allocation for the endpoint telemetry dataset to 30 days and restart the data pipeline.

Why it fails: Cortex Data Lake license settings govern ingestion volume and tenant allocation, not per-dataset purge windows. There is no field that sets a 30-day retention period for a specific dataset in the license view, and restarting the data pipeline does not change retention. This option confuses capacity management with retention policy, so it would not achieve the required automatic purge.

Create a scheduled query in the Query Center that runs daily to delete endpoint telemetry records older than 30 days from the dataset.

Why it fails: Scheduled queries in the Query Center are read-only analytics and reporting tools; they cannot delete records from datasets. XSIAM does not support destructive delete operations through scheduled queries, and attempting to use one would only produce a report, not enforce retention. Retention must be configured natively through the data retention settings, not through a query-based workaround.

Assign the integration to a dedicated user account with domain administrator rights.

Why it fails: Using a domain administrator account violates the principle of least privilege and increases security risks. The integration should use a dedicated service account with minimal permissions, not an over-privileged account. This step is insecure and not recommended for any integration.

Configure a Broker VM to proxy all API requests through the on-premises network.

Why it fails: While Broker VMs are used for on-premises data collection, they are not required for cloud-based integrations that can communicate directly over the internet. Proxying through a Broker VM adds unnecessary complexity and may not be supported for all cloud APIs. This step is not essential for cloud application integrations.

Enable automatic updates for the integration to receive new features.

Why it fails: Automatic updates can introduce unexpected changes and are not a requirement for initial integration setup. While keeping integrations updated is good practice, it is not essential for the integration to work correctly and securely at the time of configuration. This step does not address authentication or data retrieval.

Account Admin

Why it fails: Account Admin has full administrative privileges, including user management, configuration changes, and incident modification. Assigning this role would give the analyst far more access than required, violating the principle of least privilege. The manager needs a role that restricts modification capabilities while still allowing read and query access, so Account Admin is inappropriate.

Investigator

Why it fails: The Investigator role is designed for users who need to conduct deep investigations, often including the ability to modify incidents and run advanced queries. It may also allow actions like isolating endpoints. This role provides more than read-only access, so it would not satisfy the manager's requirement to restrict the analyst from modifying incident details.

Security Analyst

Why it fails: The Security Analyst role in Cortex XSIAM typically includes permissions to modify incidents, such as changing status, assigning, and adding comments. While it allows viewing and querying, it also grants write access to incidents, which exceeds the requirement. The manager specifically wants to prevent incident modifications, so this role does not meet the least-privilege requirement.

Ensure the syslog source is sending logs in the correct format as defined by the parser.

Why it fails: The scenario states that the correct parser is selected, implying the format is expected. While format mismatches can cause parsing failures, the engineer has already verified the parser. If the format were wrong, the parser would likely generate errors or drop logs, but the issue is that logs are not appearing at all, suggesting a transport problem.

Confirm that the data source's IP address is included in the Broker VM's allowed sources list.

Why it fails: If the IP were not allowed, the Broker VM would not receive the logs at all. The scenario states that logs are being received by the Broker VM, so the allowed sources list is correctly configured. This option is a distractor because it addresses a different stage of the ingestion pipeline that is already working.

Check the Broker VM's disk space to ensure it has not run out of storage for buffering logs.

Why it fails: Disk space issues could cause logs to be dropped if the buffer fills, but the scenario does not indicate any storage alerts. The Broker VM is receiving logs, so it has some capacity. While disk space is worth monitoring, it is less likely to be the root cause when logs are consistently not appearing in the data lake despite being received.