7.2 Workspace Architecture and Design Decisions
Workspace Architecture and Design Decisions
Domain 1 — Manage a SOC Environment: "Design and configure a Microsoft Sentinel workspace." Workspace architecture is one of the most frequently tested topics in this domain.
Introduction
The workspace architecture decision is the first and most consequential choice you make when deploying Sentinel. It determines how data is organized, who can access what, how costs are managed, and how complex your operational overhead becomes. Get this right and everything else is straightforward. Get it wrong and you spend months migrating data, rebuilding analytics rules, and retraining analysts.
This subsection presents the decision framework, walks through the factors that drive architecture choices, and provides clear recommendations for common scenarios.
The default recommendation: single workspace
Microsoft’s recommendation for most organisations is a single Sentinel workspace. One workspace, one incident queue, one set of analytics rules, one set of automation rules, one KQL query surface. The reasons are practical.
Cross-data correlation works natively within a workspace. When sign-in data, endpoint data, email data, and cloud security data are in the same workspace, KQL join and union queries correlate them without any extra configuration. The cross-product investigation timelines from Modules 3.9, 4.10, and 5.10 — which join SigninLogs with CloudAppEvents with OfficeActivity with AzureActivity — only work when all four tables are in the same workspace. In a multi-workspace architecture, cross-workspace queries require the workspace() function, which adds complexity, increases latency, and incurs additional query costs.
Analytics rules evaluate data within their workspace. A scheduled analytics rule that joins SigninLogs with DeviceProcessEvents only works if both tables are in the same workspace. If sign-in data is in Workspace A and endpoint data is in Workspace B, the rule must use cross-workspace queries — which are slower, more complex to write, and more expensive to run. For organisations with dozens of analytics rules that correlate multiple data sources, single workspace is the only practical choice.
Operational overhead scales with workspace count. Each workspace requires its own analytics rules, automation rules, data connectors, watchlists, and health monitoring. Two workspaces means two of everything — double the configuration, double the maintenance, double the troubleshooting. For a SOC team of 2-5 analysts, managing multiple workspaces is an operational burden that provides little security benefit.
Incident management is workspace-scoped. Each workspace has its own incident queue. In a multi-workspace architecture, the SOC team monitors multiple queues — increasing the chance that an incident in one queue is missed while the analyst is focused on another. The unified security operations platform (Sentinel + Defender XDR in the Defender portal) further assumes a single workspace model.
When multi-workspace is justified
Despite the single-workspace default, some organisations have legitimate reasons for multiple workspaces. Understand these reasons because the SC-200 exam tests the decision criteria.
| Scenario | Recommendation | Why |
|---|---|---|
| Single organisation, single region | Single workspace | No reason to split — correlation benefits outweigh separation |
| Single org, multi-region (data residency) | Multi-workspace | Data sovereignty laws require data to stay in specific regions |
| MSSP managing multiple customers | Multi-workspace (one per customer) | Customer data must be isolated — no cross-tenant access |
| Large enterprise, strict department segregation | Consider multi-workspace | If HR data must be invisible to the general SOC team |
| Dev/test vs production | Multi-workspace | Prevent test data from polluting production analytics |
| Regulatory requirement for data segregation | Multi-workspace | Some regulations require security data stored separately |
| Cost allocation per business unit | Single workspace + resource tags | Cost can be tracked without splitting workspaces |
Data residency and regional considerations
Azure Log Analytics workspaces are created in a specific Azure region. All data ingested into the workspace is stored in that region. For organisations with data residency requirements (GDPR data must stay in the EU, UK data must stay in the UK, Australian data must stay in Australia), the workspace region must match the residency requirement.
If your organisation operates in multiple jurisdictions with different residency requirements, you may need workspaces in different regions — one in UK South for UK data, one in West Europe for EU data. This is the most common legitimate reason for multi-workspace architecture.
The trade-off: Regional separation means sign-in data from UK users (in the UK workspace) cannot be correlated with sign-in data from German users (in the EU workspace) without cross-workspace queries. If an attacker compromises a UK account and then accesses EU resources, the investigation requires querying both workspaces. This is operationally manageable but more complex than a single workspace.
The practical compromise: Many organisations choose one workspace in their primary region and accept that some data traverses regions. GDPR does not prohibit processing data in another EU/EEA region — it restricts transfers to third countries (outside the EU/EEA). A UK workspace storing EU employee sign-in data is compliant post-Brexit under the UK-EU adequacy decision. Verify the specific regulatory requirements for your jurisdiction before making this decision.
The MSSP multi-workspace model
Managed Security Service Providers (MSSPs) managing multiple customer tenants must use separate workspaces per customer. Customer A’s security data must not be visible to Customer B’s analysts, and the MSSP’s internal team must see only the customers they are authorised to manage.
Azure Lighthouse enables the MSSP model: the MSSP’s Azure tenant is granted delegated access to each customer’s workspace. MSSP analysts query each customer’s workspace using their own MSSP credentials, with permissions scoped to the specific customer. The MSSP can use cross-workspace queries to aggregate high-level metrics (alert count, incident count) across customers for operational dashboards, but detailed investigation is per-workspace.
MSSP workspace architecture:
Each customer has their own Azure subscription, their own Log Analytics workspace, and their own Sentinel deployment. The customer owns the data. The MSSP has delegated access through Azure Lighthouse. Analytics rules, automation rules, and playbooks can be deployed to all customer workspaces from a central MSSP repository using Azure DevOps or GitHub Actions — ensuring consistent detection coverage across all customers.
RBAC within a single workspace
For organisations that choose a single workspace, RBAC provides data access control within the workspace — allowing different teams to see different data without splitting into separate workspaces.
Workspace-level roles: Microsoft Sentinel Reader (view incidents and data, no modifications), Microsoft Sentinel Responder (Reader + close incidents, run playbooks), Microsoft Sentinel Contributor (full Sentinel configuration — create rules, manage connectors, configure automation), Microsoft Sentinel Playbook Operator (run playbooks only). These roles control what actions users can take in Sentinel.
Resource-context RBAC: Limits which data a user can see based on the Azure resource that generated the data. If an analyst is granted access to only the “Production” resource group, they can only query data from resources in that resource group — even though all data is in the same workspace. This enables data segregation within a single workspace without the operational overhead of multiple workspaces.
Table-level RBAC: Restricts access to specific tables. If the SOC team should not see HR audit data (AuditLogs filtered to HR operations), table-level access control can restrict the HR-related tables to the HR security team only. This is the finest-grained access control available within a single workspace.
SC-200 questions frequently present scenarios where different teams need different access levels within Sentinel. The answer is almost always RBAC within a single workspace (not multiple workspaces) unless there is a regulatory or contractual requirement for complete data separation. Know the four Sentinel roles and when to use each.
Workspace naming and organisation
Workspace names are globally unique in Azure. Choose a naming convention that is descriptive, consistent, and scalable.
Recommended naming pattern: sentinel-{org}-{environment}-{region}
Examples: sentinel-northgateeng-prod-uksouth, sentinel-northgateeng-dev-uksouth, sentinel-northgateeng-prod-westeurope
The naming convention identifies the organisation (useful for MSSPs managing multiple customers), the environment (production vs development — preventing test data from polluting production), and the region (critical for data residency compliance). Include the workspace in a dedicated resource group: rg-sentinel-prod-uksouth.
Tags provide additional metadata for cost management and governance: Environment: Production, Team: SOC, CostCenter: Security, DataClassification: Confidential. Tags enable cost reporting per workspace, per team, and per environment without splitting workspaces.
Decision scenarios: applying the framework
These scenarios illustrate how the architecture framework applies to real-world situations. Each scenario appears in variations on the SC-200 exam.
Scenario 1: Mid-size company, 2,000 employees, UK only, M365 E5. Single workspace in UK South. All M365 and Azure data ingested through native connectors. Firewall Syslog and third-party endpoint data ingested through DCRs. RBAC: SOC team has Responder + Reader, detection engineer has Contributor. No multi-workspace complexity. This is the simplest and most common deployment.
Scenario 2: Multi-national, 20,000 employees, UK + Germany + US. Three workspaces — one per major region (UK South, West Europe, East US). Each workspace ingests data from the corresponding region’s users and infrastructure. Cross-workspace queries enabled for the senior investigation team (incident commanders who need global visibility). Regional SOC teams have Responder access to their own workspace. RBAC restricts cross-region access to senior analysts only. Azure Lighthouse enables the central security team to monitor all three workspaces from a single tenant.
Scenario 3: MSSP managing 25 SMB customers. Twenty-five workspaces — one per customer. Each customer’s workspace is in the customer’s Azure subscription with Sentinel enabled. The MSSP has Azure Lighthouse delegated access to all 25 workspaces. Analytics rules and automation rules are deployed from a central Git repository through CI/CD pipelines, ensuring consistent detection across all customers. MSSP analysts are scoped to 5-8 customers each. The MSSP’s internal aggregation dashboard uses cross-workspace queries to track incident counts and SLA performance across all customers.
Scenario 4: Acquisition integration. Your company acquires another company. Their existing Sentinel workspace has 6 months of historical data. Options: (a) merge data into your workspace by re-configuring their connectors to point to your workspace — historical data is not migrated but new data flows to the unified workspace; (b) keep both workspaces temporarily and use cross-workspace queries for investigation continuity; (c) full migration using Azure Data Explorer for historical data export/import. Most organisations choose option (b) temporarily, then option (a) for new data after a transition period.
Workspace consolidation: when to merge
Organisations that grew into multiple workspaces without a clear architectural reason (each team created their own workspace, legacy workspaces from before Sentinel was adopted) should consider consolidation. The benefits of consolidation: reduced operational overhead, improved cross-data correlation, simplified RBAC management, and better commitment tier pricing (one workspace at 200 GB/day gets a better per-GB rate than four workspaces at 50 GB/day each).
Consolidation approach: Identify the target workspace (typically the one with the most data and most active analytics rules). Re-configure data connectors to point to the target workspace. Migrate custom analytics rules, automation rules, and workbooks. Verify detection coverage matches the pre-consolidation baseline. Decommission the old workspaces. The migration takes 2-4 weeks with careful planning.
Do not consolidate when: Regulatory or contractual requirements mandate separate workspaces, different regions require data residency compliance, or different business units have fundamentally different security requirements that cannot be addressed with RBAC.
Try it yourself
Before creating your Sentinel workspace (subsection 7.3), make the architecture decision for your lab environment. Answer: (1) How many workspaces do I need? (For a lab: 1 — single workspace.) (2) Which Azure region? (Choose the region closest to you or required by your data residency policy.) (3) What naming convention? (Use the pattern above.) (4) What resource group? Write down your answers — these are the inputs for the workspace creation in subsection 7.3.
What you should observe
For a lab environment, the answer is always: single workspace, one region, simple naming convention. The exercise builds the decision-making habit — in production, the same questions have more complex answers (multi-region data, regulatory requirements, MSSP model), but the decision framework is the same.
Knowledge check
Check your understanding
1. Your organisation has offices in the UK and Germany. GDPR requires German employee data to stay in the EU. You want to correlate sign-in data across both offices for security investigations. What architecture do you recommend?
2. An MSSP managing 10 customers wants a single workspace to simplify operations. Is this appropriate?
3. Two SOC teams in the same organisation want to see different data in Sentinel. Team A handles endpoint alerts, Team B handles identity alerts. Do you need two workspaces?