This chapter covers the foundational steps for setting up a Microsoft Sentinel workspace, including provisioning, configuration, and initial data ingestion. Proper workspace setup is critical because all subsequent security operations—detection, investigation, automation—depend on it. On the SC-200 exam, workspace setup appears in approximately 15-20% of questions, often integrated with topics like data connectors, RBAC, and retention policies. Mastering this chapter ensures you can design a Sentinel environment that is cost-effective, compliant, and operationally efficient.
Jump to a section
Setting up a Microsoft Sentinel workspace is like constructing a new security operations center (SOC) for a company. First, you must choose a physical location (the Azure region) that balances proximity to your data sources and compliance with data residency requirements. Then, you decide how many rooms (workspaces) you need: one large room for all security teams, or separate rooms for different departments (e.g., IT, legal, HR) to control access. Next, you install the main monitoring board (the workspace) and configure the phone lines (data connectors) that bring in alerts from various sources—firewalls, endpoints, cloud apps. You also set up the roles and badges (Azure RBAC) so only authorized analysts can view or modify the board. Finally, you define the retention policy: how long you keep old case files (log data) before shredding them. Just as a poorly designed SOC leads to missed alerts or unauthorized access, a misconfigured Sentinel workspace can cause data loss, high costs, or security gaps. The analogy is mechanistic: each component (region, workspace, connector, role, retention) directly mirrors a real-world SOC element, and the decisions you make during setup have concrete, lasting impacts on operations.
What is a Microsoft Sentinel Workspace?
Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration Automation and Response (SOAR) service. The workspace is the logical container that holds all the data ingested into Sentinel, including logs, alerts, incidents, and configuration settings. Each workspace is tied to a specific Log Analytics workspace, which is the underlying data store. Sentinel adds SIEM and SOAR capabilities on top of Log Analytics.
Why Workspace Setup Matters for the Exam
The SC-200 exam tests your ability to plan and configure a Sentinel workspace correctly. Key areas include: choosing the right number of workspaces, selecting the appropriate Azure region, enabling prerequisites (like Azure Defender for Cloud), configuring RBAC, setting retention and archiving, and connecting data sources. Mistakes in these areas can lead to data residency violations, excessive costs, or missed security events.
How Workspace Setup Works Internally
When you create a Sentinel workspace, you are essentially enabling the Sentinel resource provider on an existing Log Analytics workspace. The process involves:
Resource Provider Registration: The Microsoft.OperationsManagement and Microsoft.OperationalInsights resource providers must be registered in your subscription. Sentinel is built on these.
Workspace Creation: You create a Log Analytics workspace via the Azure portal, CLI, or PowerShell. During creation, you specify the name, subscription, resource group, region, and pricing tier (Pay-as-you-go or Capacity Reservations).
Sentinel Enablement: After the Log Analytics workspace exists, you enable Sentinel by selecting it from the Azure Sentinel service. This action adds the Sentinel solution to the workspace, which installs security-related data tables and analytics rules.
Data Ingestion: Once enabled, you connect data sources using built-in connectors (e.g., Azure Activity, Office 365, AWS CloudTrail) or via the Common Event Format (CEF) or Syslog. Each connector writes data to specific tables in the Log Analytics workspace (e.g., SecurityEvent, SigninLogs).
Retention and Archiving: By default, Log Analytics retains data for 30 days for interactive queries. You can extend retention up to two years for individual tables or use archiving for longer-term storage at lower cost. Sentinel itself does not charge for data retention; Log Analytics charges apply.
Key Components, Values, Defaults, and Timers
- Workspace Name: Globally unique within a region. Maximum 63 characters. Can contain letters, numbers, and hyphens. - Region: Choose the Azure region closest to your data sources and users, but also consider data residency requirements. Some regions (e.g., US Gov Virginia) are isolated. - Pricing Tier: Log Analytics has a Pay-as-you-go tier (default) and Capacity Reservations (100 GB/day minimum). Sentinel pricing is based on the Log Analytics tier plus additional Sentinel costs for analytics rules, automation, and ingestion beyond the free first 5 GB/day. - Retention: Default 30 days interactive retention. You can increase up to 730 days (2 years) per table. Archival retention: up to 7 years at reduced cost. - Data Connectors: Over 100 built-in connectors. Each connector has a status (Connected, Disconnected, or Not configured). Connectors may require specific permissions (e.g., Global Admin for Office 365). - RBAC Roles: Sentinel-specific roles include: - Azure Sentinel Reader: View incidents, workbooks, etc. - Azure Sentinel Responder: Manage incidents (e.g., change status, assign). - Azure Sentinel Contributor: Create and edit analytics rules, workbooks, etc. - Azure Sentinel Contributor plus Log Analytics Contributor for full management. - Threat Intelligence: Enable Threat Intelligence (TI) connectors to ingest threat indicators. Free tier allows 10 MB/day of TI data.
Configuration and Verification Commands
You can create a workspace using Azure CLI:
az monitor log-analytics workspace create --resource-group myRG --workspace-name mySentinelWS --location eastus --sku PerGB2018Then enable Sentinel:
az sentinel enable --resource-group myRG --workspace-name mySentinelWSTo verify the workspace is ready, you can list workspaces:
az monitor log-analytics workspace list --resource-group myRGOr check for the Sentinel solution:
az monitor log-analytics solution show --resource-group myRG --name SecurityInsights(mySentinelWS)Interaction with Related Technologies
Azure Defender for Cloud: Must be enabled to ingest security alerts from Azure resources. Sentinel can pull alerts from Defender for Cloud via the 'Security Alert' connector.
Azure Policy: Can be used to enforce Sentinel deployment across multiple subscriptions, e.g., requiring a Sentinel workspace in every region.
Azure Lighthouse: Allows managed service providers (MSPs) to manage Sentinel workspaces across multiple tenants from a single console.
Azure Monitor: Underlying monitoring service. Log Analytics workspaces are part of Azure Monitor.
Azure Key Vault: Can store credentials for data connectors (e.g., AWS access keys) securely.
Best Practices for Workspace Design
Single vs. Multiple Workspaces: Use a single workspace for most organizations to simplify management and cross-workspace queries. Multiple workspaces may be needed for:
- Data sovereignty (e.g., EU data must stay in EU)
- Different security teams (e.g., SOC vs. insider threat)
- Isolating test environments
- Workspace Location: Choose a region that minimizes latency for analysts and complies with data residency.
- Retention Policies: Set retention per table based on compliance needs. For example, keep SigninLogs for 90 days, but SecurityEvent for 1 year.
- Cost Management: Use Capacity Reservations if you ingest more than 100 GB/day. Monitor daily ingestion via Sentinel Usage workbooks.
- Access Control: Use Azure RBAC to grant least privilege. Avoid using subscription-wide roles; scope roles to the workspace.
Common Pitfalls
Enabling Sentinel on an existing workspace with sensitive data: Sentinel adds security tables but does not delete existing data. Ensure the workspace is dedicated for security if possible.
Forgetting to register resource providers: If providers are not registered, workspace creation fails.
Misconfiguring retention: Setting retention too low may cause data loss before compliance requirements are met; setting too high increases costs.
Choosing wrong region: Data residency laws may be violated if logs are stored in a region outside the required jurisdiction.
Exam Relevance
The SC-200 exam objective 'Design and configure a Microsoft Sentinel workspace' (Domain 2, Objective 2.1) tests your ability to plan and implement workspaces. Expect questions on:
When to use multiple workspaces
How to enable Sentinel on a Log Analytics workspace
Default retention periods
RBAC roles for Sentinel
Steps to connect data sources
Detailed Mechanism: Data Ingestion Flow
A data source (e.g., Azure Active Directory) sends logs to the Log Analytics workspace via a connector.
The connector uses a Log Analytics Data Collection Rule (DCR) or direct API to write to a specific table (e.g., SigninLogs).
Sentinel's analytics rules query these tables (e.g., SigninLogs | where ...).
When a rule matches, an incident is created in Sentinel.
The incident is stored in the SecurityIncident table.
Understanding this flow helps you troubleshoot why data is not appearing in Sentinel.
1. Plan workspace architecture
Decide between single or multiple workspaces based on compliance, team structure, and cost. For example, a multinational company may need one workspace per region to meet GDPR. Consider that cross-workspace queries are possible but can add latency. Also decide on the workspace region—choose the Azure region closest to your data sources and users. Document the workspace name, subscription, and resource group. Ensure you have the required permissions (Contributor at the subscription level or a custom role that allows creating Log Analytics workspaces and enabling Sentinel).
2. Register resource providers
Before creating a Log Analytics workspace, ensure the `Microsoft.OperationsManagement` and `Microsoft.OperationalInsights` resource providers are registered in your subscription. You can check via Azure CLI: `az provider list --query "[?contains(namespace,'Microsoft.OperationsManagement')].registrationState"`. If not registered, run: `az provider register --namespace Microsoft.OperationsManagement` and similarly for `Microsoft.OperationalInsights`. This step is often forgotten and causes errors during workspace creation.
3. Create Log Analytics workspace
In the Azure portal, navigate to Log Analytics workspaces and click Create. Fill in the subscription, resource group, workspace name (must be globally unique within a region), and region. Choose the pricing tier: Pay-as-you-go (PerGB2018) is default; Capacity Reservations require a minimum of 100 GB/day. You can also create using CLI: `az monitor log-analytics workspace create --resource-group myRG --workspace-name myWS --location eastus --sku PerGB2018`. The workspace is provisioned within a few minutes.
4. Enable Microsoft Sentinel
In the Azure portal, search for 'Microsoft Sentinel' and click Create. Select the Log Analytics workspace you just created. Sentinel will add the 'SecurityInsights' solution to the workspace. This solution installs the necessary data tables (e.g., SecurityAlert, SecurityIncident) and analytics rules. You can verify via CLI: `az sentinel show --resource-group myRG --workspace-name myWS`. If successful, the workspace will appear in the Sentinel list.
5. Configure RBAC permissions
Assign Sentinel roles to users and groups. Use Azure RBAC at the workspace scope. For example, to assign a SOC analyst as a Reader: `az role assignment create --assignee user@domain.com --role "Azure Sentinel Reader" --scope /subscriptions/.../workspaces/myWS`. Common roles: Reader (view), Responder (manage incidents), Contributor (full management). Also consider Log Analytics roles for querying logs. Remember that Sentinel permissions are additive to Log Analytics permissions.
6. Set retention and archiving
By default, Log Analytics retains data for 30 days. To change retention for a specific table, go to the workspace's Tables settings. For example, set `SigninLogs` to 90 days. You can also enable archiving: data older than the interactive retention period is moved to low-cost storage (archival) for up to 7 years. Use CLI: `az monitor log-analytics workspace table update --resource-group myRG --workspace-name myWS --table-name SigninLogs --retention-time 90`. Cost implications: interactive retention is more expensive than archival.
7. Connect data sources
In Sentinel, go to Data connectors. Choose a connector (e.g., Azure Active Directory) and click Open connector page. Follow the instructions: for Azure AD, you need to enable diagnostic settings to stream logs to the workspace. For AWS, you need to configure CloudTrail and provide access keys. Each connector has specific prerequisites. After configuration, verify data is flowing by checking the connector status (should be 'Connected') and querying the relevant table (e.g., `SigninLogs | take 10`).
Enterprise Scenario 1: Global Retail Company with Data Residency Requirements
A multinational retailer must comply with GDPR (EU data stays in EU) and similar laws in Asia. They set up three Sentinel workspaces: one in West Europe (for EU data), one in Southeast Asia (for Asian data), and one in East US (for Americas). Each workspace is managed by a separate SOC team with local RBAC. They use Azure Lighthouse to allow a global SOC manager to view all workspaces from a single pane. The challenge is cross-workspace queries for global threat hunting; they use Azure Data Explorer (ADX) for cross-workspace queries when needed. The cost is higher due to multiple workspaces, but compliance is satisfied.
Enterprise Scenario 2: Large Financial Institution with High Ingestion Volume
A bank ingests over 500 GB/day of logs from firewalls, endpoints, and cloud services. They choose a single workspace in the same region as their primary data center (East US 2) to minimize latency. They use Capacity Reservations at 500 GB/day to reduce cost (compared to Pay-as-you-go). They set retention to 90 days for most tables, but keep SecurityEvent for 1 year due to regulatory requirements. They archive financial transaction logs for 7 years. The workspace is integrated with Azure Defender for Cloud for alerts. The SOC team uses Sentinel's built-in workbooks to monitor daily ingestion and cost. Misconfiguration risk: if they set retention too low for compliance, they could face fines; if they use Pay-as-you-go, costs would be significantly higher.
Enterprise Scenario 3: MSP Managing Multiple Tenants
A managed security service provider (MSP) manages security for 50 small businesses. Each customer has their own Azure subscription. The MSP uses Azure Lighthouse to delegate access to each customer's Sentinel workspace. They create one workspace per customer to isolate data. They use Azure Policy to enforce consistent configuration (e.g., mandatory data connectors, retention settings) across all customer workspaces. The MSP's SOC analysts have read-only access to all workspaces via a built-in custom role. The main challenge is managing cost: each workspace has its own ingestion and retention costs, and the MSP must bill customers accurately. They use Sentinel's usage reports to track per-customer consumption.
SC-200 Exam Focus on Workspace Setup
The SC-200 exam objective 'Design and configure a Microsoft Sentinel workspace' (Domain 2, Objective 2.1) is tested in multiple-choice and case study questions. Key areas:
Number of workspaces: The exam tests when to use multiple workspaces vs. a single workspace. Correct answers often involve data sovereignty, team isolation, or regulatory requirements. Wrong answer: 'Multiple workspaces are always better for performance.' Reality: Single workspace is simpler and supports cross-workspace queries if needed.
Workspace region: Questions may ask which region to choose for a company with data residency requirements. The correct answer is the region that complies with local laws. Trap: Choosing the nearest region to the SOC analysts is not always correct if data must stay in a specific country.
Default retention: The exam expects you to know that the default retention for Log Analytics is 30 days. A common wrong answer is 90 days (which is the default for some other services). You can extend retention per table up to 730 days (2 years) for interactive queries.
RBAC roles: You must know the three Sentinel-specific roles (Reader, Responder, Contributor) and what each can do. A typical question: 'Which role allows an analyst to change the status of an incident but not create analytics rules?' Answer: Azure Sentinel Responder.
Enabling Sentinel: The exam tests that you enable Sentinel on an existing Log Analytics workspace. A wrong answer might suggest creating a new workspace specifically for Sentinel (which is optional but not required; you can use an existing one).
Data connectors: You should know that connectors must be configured individually and that some require special permissions (e.g., Global Admin for Office 365). The exam may ask which connector to use for a specific data source.
Cost management: Questions on Capacity Reservations: minimum commitment is 100 GB/day. Pay-as-you-go is default. You may be asked to recommend a pricing tier based on ingestion volume.
Common Wrong Answers and Why
'You must create a new Log Analytics workspace for Sentinel.' Wrong: You can use an existing workspace, but it's recommended to use a dedicated workspace for security to avoid mixing with operational logs.
'Retention can be set globally for all tables.' Wrong: Retention is set per table. The default is 30 days for all tables, but you can customize per table.
'Azure Sentinel Reader can create analytics rules.' Wrong: Reader can only view. Contributor is needed to create rules.
'Multiple workspaces are required for different data sources.' Wrong: You can connect multiple data sources to a single workspace.
Exam Tips
Memorize the default retention of 30 days.
Remember the three Sentinel roles and their permissions.
Know that Sentinel is enabled on a Log Analytics workspace, not created independently.
Understand that workspace region must comply with data residency laws.
Practice with the Azure CLI commands for workspace creation and Sentinel enablement.
Sentinel is enabled on an existing Log Analytics workspace; you cannot create a Sentinel workspace without first creating or selecting a Log Analytics workspace.
Default interactive retention is 30 days per table; can be increased up to 730 days per table.
Archival retention can be set up to 7 years at lower cost.
Sentinel has three built-in roles: Reader (view), Responder (manage incidents), Contributor (full management).
Data connectors must be configured individually and may require specific permissions (e.g., Global Admin for Office 365).
Capacity Reservations require a minimum commitment of 100 GB/day and offer cost savings over Pay-as-you-go.
Cross-workspace queries are possible but can incur latency and cost; use them sparingly.
Azure Lighthouse enables managing multiple Sentinel workspaces across tenants from a single console.
These come up on the exam all the time. Here's how to tell them apart.
Single Workspace
Simpler management: one workspace to monitor and configure.
Supports cross-workspace queries using union operator across workspaces (though with latency).
Lower cost: no redundant storage for duplicate data; one set of analytics rules.
Easier RBAC: one scope for permissions.
Best for most organizations without strict data residency or team isolation needs.
Multiple Workspaces
Necessary for data sovereignty: keep data in specific regions.
Isolates different security teams (e.g., SOC vs. insider threat) with separate RBAC.
Can be used for test/production separation.
Higher cost: separate ingestion, retention, and analytics rule costs.
Required for managed service providers using Azure Lighthouse to manage separate customer environments.
Mistake
Sentinel workspace is a separate resource from Log Analytics workspace.
Correct
Sentinel is an overlay on a Log Analytics workspace. You enable Sentinel on an existing Log Analytics workspace; it does not create a new type of workspace. The underlying data storage is still the Log Analytics workspace.
Mistake
You can only have one Sentinel workspace per subscription.
Correct
You can have multiple Sentinel workspaces per subscription, each tied to a different Log Analytics workspace. However, best practice is to use a single workspace unless compliance or team isolation requires multiple.
Mistake
Data retention in Sentinel is set globally for the entire workspace.
Correct
Retention is set per table (e.g., SigninLogs, SecurityEvent). You can configure different retention periods for different tables. The default is 30 days for all tables.
Mistake
The Azure Sentinel Contributor role can delete the workspace.
Correct
The Contributor role cannot delete the workspace; deletion requires Owner or Contributor permissions at the resource group level. Sentinel roles are scoped to the workspace and do not include delete permissions.
Mistake
You must enable Azure Defender for Cloud before using Sentinel.
Correct
Azure Defender for Cloud is not a prerequisite for Sentinel. However, to ingest security alerts from Azure resources, you need to enable Defender for Cloud and connect it via the 'Security Alert' connector.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, you can enable Sentinel on an existing Log Analytics workspace. However, it is recommended to use a dedicated workspace for security data to avoid mixing with operational logs and to simplify RBAC. If you use an existing workspace, ensure that the data already in the workspace does not cause compliance issues (e.g., mixing security and non-security data).
The default retention period for Log Analytics workspaces (and thus Sentinel data) is 30 days. This applies to all tables unless you configure a different retention period per table. You can increase retention up to 730 days (2 years) for interactive queries, and set archival retention up to 7 years.
Use a single workspace unless you have specific requirements such as data sovereignty (data must stay in a specific region), team isolation (different SOC teams need separate workspaces), or regulatory compliance (different data retention policies per business unit). Multiple workspaces increase complexity and cost, so start with a single workspace and split only if necessary.
You need Contributor permissions on the subscription or resource group where you will create the Log Analytics workspace. Additionally, the resource providers Microsoft.OperationsManagement and Microsoft.OperationalInsights must be registered. After the workspace is created, you need Contributor permissions on the workspace to enable Sentinel.
No, you cannot change the region of an existing Log Analytics workspace. You would need to create a new workspace in the desired region, enable Sentinel on it, and migrate your data and configurations (e.g., analytics rules, workbooks) manually. This is a significant effort, so choose the region carefully at creation time.
Azure Sentinel Reader can view incidents, workbooks, analytics rules, and other Sentinel data but cannot make any changes. Azure Sentinel Responder has all Reader permissions plus the ability to manage incidents (e.g., change status, assign, add comments). Responder cannot create or modify analytics rules, workbooks, or data connectors.
Use Sentinel's built-in 'Usage and cost' workbook, which shows daily ingestion per table and estimated costs. You can also set budgets and alerts in Azure Cost Management. Additionally, the Log Analytics workspace has its own usage reports. For Capacity Reservations, track your daily ingestion to ensure you are meeting the commitment.
You've just covered Microsoft Sentinel Workspace Setup — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?