5.2.1. Workspaces, Roles, and Content Hub Solutions
💡 First Principle: Sentinel isn't a separate product with its own storage — it's a set of security capabilities layered on top of a Log Analytics workspace, which means workspace-level decisions (which one, who has access to it) directly shape how Sentinel behaves.
Creating and connecting a workspace to Sentinel enables the security capabilities (analytics rules, incidents, hunting) on top of that Log Analytics workspace's data. Assigning roles in Sentinel uses dedicated built-in roles (Sentinel Reader, Responder, Contributor) that are distinct from generic Log Analytics roles — a user can have full Log Analytics access without any Sentinel-specific permissions, and vice versa. Content hub solutions are packaged bundles of analytics rules, workbooks, connectors, and playbooks for specific data sources or scenarios (a particular product's connector plus its pre-built detections, for example) — installable as a unit rather than building each component from scratch.
⚠️ Exam Trap: Granting a user the Log Analytics Reader role on the underlying workspace does not automatically grant Sentinel permissions — Sentinel's own RBAC roles (Sentinel Reader, Responder, Contributor) must be assigned separately for that user to work with incidents, analytics rules, or playbooks within Sentinel itself.
Reflection Question: Why would a user with full Log Analytics Contributor access to the underlying workspace still be unable to manage Sentinel incidents without an additional role assignment?
