Security Operations Platform Foundations
This domain tests your grasp of the Cortex XSIAM operating model: how telemetry reaches the platform, which components collect it, and how access and content are governed. Expect questions that ask you to choose the right component or permission level rather than recite product names.
Core architecture rules
- The normal data path is source → collector or Broker VM / cloud API → Cortex Data Lake → analytics → alerts and incidents → playbooks and response.
- Broker VM is customer-deployed for local collection, syslog reception, and proxying. Cloud integrations pull SaaS telemetry through APIs; endpoint telemetry typically comes from the Cortex XDR agent.
- RBAC should follow least privilege. Use built-in or custom roles scoped to the tenant or domain, and separate triage, administration, and audit duties.
- Marketplace content packs provide integrations, parsers, and playbooks. Review version, permissions, and dependencies before installing.
Worked example
A new SOC analyst needs to triage incidents but must not change RBAC or install content. Create a custom role with incident view/edit, XQL query access to production datasets, and no tenant administration or Marketplace rights. Assign the role through a user group scoped to the production tenant. Validate by signing in as a test user and confirming that incidents are visible while administration menus are denied. The reasoning is least privilege plus a verification step: access should be proven, not assumed.
Traps that cost marks
- Assuming every source requires a Broker VM; many SaaS sources are API-collected.
- Confusing Cortex Data Lake with a general-purpose data warehouse.
- Granting administrator rights for daily triage because it is faster.
- Ignoring data residency or regional tenant placement.
- Installing content packs without checking permissions and compatibility.