Planning and Creating a Microsoft Sentinel Workspace – SC-200 Study Guide

Purpose of This Lesson

This lesson explains the foundational setup required before Microsoft Sentinel can be used as a cloud-native SIEM and SOAR platform. The main focus is planning and creating the Log Analytics workspace that Microsoft Sentinel depends on.

For the SC-200 exam, this is important because Microsoft Sentinel does not operate in isolation. It needs a workspace to store ingested security data, run analytics, generate incidents, support hunting queries, and drive automation. A Security Operations Analyst must understand this foundation before working with data connectors, analytics rules, incidents, workbooks, hunting queries, automation rules, or playbooks.

In a real SOC, poor workspace planning can create problems with cost, permissions, data retention, investigation scope, compliance, and operational separation.

Key Concepts

Microsoft Sentinel Requires a Log Analytics Workspace

Microsoft Sentinel is enabled on top of an Azure Monitor Log Analytics workspace. The workspace is the central data store where Sentinel ingests, analyzes, and queries security data. Microsoft’s current documentation confirms that a Log Analytics workspace is required for Sentinel detections, analytics, and other features.

Think of the relationship like this:

Component	Purpose
Log Analytics workspace	Stores log data and makes it queryable with KQL
Microsoft Sentinel	Adds SIEM/SOAR capabilities on top of the workspace
Data connectors	Bring security data into the workspace
Analytics rules	Analyze workspace data and generate alerts/incidents
Workbooks	Visualize data stored in the workspace
Hunting queries	Search workspace data for suspicious behavior
Automation/playbooks	Respond to incidents and alerts

A common beginner mistake is thinking that creating Microsoft Sentinel creates all of the underlying data storage automatically. In practice, Sentinel is added to a Log Analytics workspace.

Prerequisites for Deploying Microsoft Sentinel

Before enabling Microsoft Sentinel, you need a valid Azure environment. Current Microsoft documentation lists the need for a Microsoft Entra ID tenant/license or individual account with a valid payment method, an Azure subscription, and appropriate permissions.

The key prerequisites are:

• Microsoft Entra ID tenant or valid Azure account
• Azure subscription for resource creation and billing
• Sufficient Azure permissions
• Log Analytics workspace
• Supported workspace pricing tier
• No unsupported resource locks on the workspace
• Region selection based on business, compliance, and data residency requirements

For the SC-200 exam, remember that Sentinel is an Azure service, but it is tightly connected to Microsoft Entra ID, Azure Monitor, Log Analytics, and Microsoft Defender security data sources.

Log Analytics Workspace Planning

Creating a workspace is not just a setup task. It is a design decision.

A Log Analytics workspace stores security data from sources such as:

• Microsoft Entra ID
• Microsoft Defender XDR
• Microsoft Defender for Endpoint
• Microsoft Defender for Identity
• Microsoft Defender for Office 365
• Microsoft Defender for Cloud
• Azure Activity logs
• Firewalls
• DNS logs
• Windows Security Events
• Syslog
• Common Event Format logs
• Third-party security tools

Microsoft recommends using a dedicated resource group for the Log Analytics workspace enabled for Sentinel, along with Sentinel-related resources such as playbooks and workbooks. This makes permissions easier to manage and reduces operational complexity.

When planning the workspace, consider:

Planning Area	Why It Matters
Region	Impacts data residency, latency, and compliance
Resource group	Helps separate Sentinel resources from unrelated Azure assets
RBAC scope	Controls who can view, investigate, modify, or automate responses
Data sources	Determines what Sentinel can detect and investigate
Retention	Impacts investigation history and cost
Cost model	Sentinel and Log Analytics can become expensive at scale
Naming convention	Helps with operational clarity in multi-workspace environments
Workspace architecture	Affects centralized vs segmented SOC operations

Creating the Log Analytics Workspace

The basic deployment flow is:

1. Go to the Azure portal.
2. Search for Log Analytics workspaces.
3. Create a workspace.
4. Select or create a resource group.
5. Provide a workspace name.
6. Select a region.
7. Review and create the workspace.

Microsoft’s Log Analytics documentation describes the workspace as a data store for log data from Azure, non-Azure, and application sources. It also notes that creating a workspace requires an active Azure subscription and appropriate workspace write permissions.

Example naming pattern:

Azure Resource	Example Name
Resource group	rg-sentinel-prod-eastus
Log Analytics workspace	law-sentinel-prod-eastus
Sentinel environment	Production SOC workspace

For a lab, a simple name like Sentinel-Log-Workspace is fine. For production, use a standard naming convention that identifies environment, region, workload, and ownership.

Enabling Microsoft Sentinel on the Workspace

After the Log Analytics workspace exists, Microsoft Sentinel can be added to it.

The basic process is:

1. Open Microsoft Sentinel.
2. Select Create or Add.
3. Choose the Log Analytics workspace.
4. Add Microsoft Sentinel to the workspace.

This does not mean logs are automatically flowing into Sentinel. It only means the workspace is now enabled for Sentinel capabilities. You still need to configure data connectors before Sentinel has useful security telemetry to analyze.

Important distinction:

Action	Result
Create Log Analytics workspace	Creates the data store
Add Microsoft Sentinel	Enables SIEM/SOAR features on that workspace
Configure data connectors	Starts bringing security data into Sentinel
Create analytics rules	Starts detecting suspicious activity
Configure automation rules/playbooks	Enables response workflows

Free Trial and Pricing Considerations

Microsoft Sentinel is usage-based. Costs are driven heavily by data ingestion, retention, and additional capabilities. Current Microsoft documentation states that when Sentinel is enabled on an Azure Monitor Log Analytics workspace, the first 10 GB per day ingested using the Analytics logs plan is free for 31 days, with charges waived up to that limit during the trial. Usage beyond trial limits and extra capabilities may still be charged.

For exam purposes, do not memorize a specific dollar amount from a training video. Pricing changes by region, time, commitment tier, and data plan. Instead, remember the cost model:

• Sentinel pricing is based heavily on data ingestion.
• Log Analytics is the underlying storage/query platform.
• High-volume data sources can increase cost quickly.
• Commitment tiers may reduce cost for predictable daily ingestion.
• Retention choices affect long-term cost.
• Not every data source has the same billing behavior.
• Always review pricing before enabling Sentinel broadly in production.

In a production SOC, the question is not simply “Can we connect this data source?” It is also “Should we ingest all of this data, how long do we need it, and what detection value does it provide?”

Microsoft Security Operations Context

Where This Fits in a SOC Workflow

A Sentinel workspace is the foundation for the SOC’s SIEM workflow. Before analysts can triage incidents or hunt threats, the environment must be able to collect and store security telemetry.

A typical SOC workflow looks like this:

1. Deploy Sentinel workspace
   • Create or select a Log Analytics workspace.
   • Enable Microsoft Sentinel.
2. Connect data sources
   • Microsoft Defender XDR
   • Microsoft Entra ID
   • Microsoft Defender for Cloud
   • Firewalls
   • Endpoint logs
   • Syslog/CEF sources
3. Enable analytics rules
   • Detect suspicious activity.
   • Correlate events.
   • Generate alerts and incidents.
4. Triage incidents
   • Review severity, tactics, entities, and evidence.
   • Determine whether the incident is true positive or false positive.
5. Investigate entities
   • Users
   • Devices
   • IP addresses
   • Files
   • Mailboxes
   • Cloud resources
6. Contain or remediate
   • Disable account.
   • Isolate endpoint.
   • Block IP address.
   • Remove malicious email.
   • Trigger playbook.
7. Document and improve
   • Record findings.
   • Tune analytics rules.
   • Add watchlists.
   • Improve automation.
   • Adjust data ingestion strategy.

Without the workspace and connectors, Sentinel has nothing meaningful to analyze.

Why Workspace Planning Matters to Analysts

Even though workspace creation may feel like an admin task, it directly affects analysts.

Poor workspace planning can lead to:

• Missing logs during investigations
• Analysts lacking access to needed data
• Excessive data ingestion cost
• Noisy detections
• Inconsistent retention
• Data split across too many workspaces
• Confusing incident scope
• Automation failures due to missing permissions
• Compliance or data residency problems

A Security Operations Analyst should understand enough of the architecture to know whether an investigation is limited by missing telemetry.

Permissions and RBAC Considerations

Microsoft Sentinel uses Azure RBAC for SIEM access. Microsoft documents built-in roles such as Microsoft Sentinel Reader, Responder, Contributor, Playbook Operator, and Automation Contributor. These roles control whether users can view data, manage incidents, create resources, or run playbooks.

Common role patterns:

Role	Typical Use
Microsoft Sentinel Reader	View incidents, data, and workbooks
Microsoft Sentinel Responder	Manage incidents during triage and investigation
Microsoft Sentinel Contributor	Create and modify Sentinel resources such as analytics rules
Microsoft Sentinel Playbook Operator	Manually run playbooks
Logic App Contributor	Create or modify playbooks because playbooks are Azure Logic Apps

For SC-200, remember that least privilege matters. A Tier 1 analyst does not usually need Owner or Contributor rights across the entire subscription.

Exam-Relevant Takeaways

For the SC-200 exam, remember these points:

• Microsoft Sentinel requires a Log Analytics workspace.
• Sentinel is enabled on a workspace; the workspace stores the data.
• Creating Sentinel does not automatically ingest useful logs.
• Data connectors are required to bring data into Sentinel.
• Analytics rules use ingested data to create alerts and incidents.
• Workbooks visualize data already present in the workspace.
• Hunting queries search data already present in the workspace.
• Pricing is tied heavily to data ingestion and retention.
• The free trial is useful for labs, but production planning requires cost review.
• A dedicated resource group is recommended for Sentinel-related resources.
• Permissions should be assigned using least privilege, often at the resource group level.
• Microsoft Sentinel Reader, Responder, Contributor, and Playbook Operator serve different operational purposes.
• The Azure portal setup flow is still useful to understand, but Microsoft states that after March 31, 2027, Sentinel will be available only in the Microsoft Defender portal.

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
You need to deploy Sentinel for the first time	Log Analytics workspace + Microsoft Sentinel	Sentinel must be enabled on a workspace before it can ingest and analyze data
You need a central place to store security logs	Log Analytics workspace	It stores queryable log data used by Sentinel
You need SIEM/SOAR capabilities	Microsoft Sentinel	Provides incidents, analytics rules, hunting, automation, workbooks, and connectors
You need to collect logs from Microsoft Entra ID	Microsoft Sentinel data connector	Data connectors bring identity logs into the workspace
You need to detect suspicious activity from ingested logs	Analytics rule	Analytics rules query data and generate alerts/incidents
You need to visualize security posture or log trends	Workbook	Workbooks provide dashboards over workspace data
You need to manually search for suspicious activity	Hunting query	Hunting queries use KQL to investigate data
You need to respond automatically to incidents	Automation rule or playbook	Automation rules orchestrate incident handling; playbooks perform Logic App response actions
You need to control analyst access	Microsoft Sentinel RBAC roles	Assign Reader, Responder, Contributor, or Playbook Operator based on job function
You need to estimate production cost	Sentinel pricing and Log Analytics ingestion planning	Cost depends heavily on data volume, retention, and capabilities

Microsoft Defender XDR vs Microsoft Sentinel

Area	Microsoft Defender XDR	Microsoft Sentinel
Main purpose	Extended detection and response across Microsoft security products	Cloud-native SIEM and SOAR
Primary data	Microsoft Defender product signals	Microsoft and non-Microsoft log sources
Best for	Incidents across endpoint, identity, email, and cloud apps	Centralized security monitoring, log analytics, SIEM correlation, and automation
Data dependency	Built around Defender product telemetry	Depends on connected data sources and Log Analytics workspace
Query language	Advanced Hunting uses KQL	Sentinel hunting and analytics use KQL
Typical SC-200 decision	Use when investigating Microsoft Defender incidents	Use when correlating multiple log sources or building SIEM detections

KQL Notes

This lesson does not demonstrate KQL directly. However, the workspace setup is what makes KQL useful in Sentinel. Once data is connected, analysts use KQL to search tables in the Log Analytics workspace.

Basic Concept

KQL queries run against tables in the workspace. If a data connector has not been configured, the table you want may not exist or may not contain data.

Example: after connecting Azure Activity logs, an analyst might query recent Azure activity.

AzureActivity
| where TimeGenerated > ago(24h)
| take 20

What this does:

Query Part	Meaning
AzureActivity	Searches the Azure Activity table
where TimeGenerated > ago(24h)	Limits results to the last 24 hours
take 20	Returns 20 rows for quick inspection

Example: after connecting Windows Security Events, an analyst might look for recent failed logons.

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| project TimeGenerated, Computer, Account, IpAddress, Activity

What this does:

Query Part	Meaning
SecurityEvent	Searches Windows security event data
EventID == 4625	Filters for failed logon events
project	Displays only selected columns

Exam point: KQL is only useful when the relevant data is being ingested into the workspace. If the scenario says Sentinel has no data from a source, the correct first step is usually to configure the data connector or diagnostic setting, not write a better query.

Common Exam Traps

Trap 1: Thinking Sentinel Works Without a Workspace

Sentinel requires a Log Analytics workspace. If a question asks what must exist before enabling Sentinel, the answer is the workspace.

Trap 2: Confusing Workspace Creation with Data Ingestion

Creating a workspace and enabling Sentinel does not automatically bring in endpoint, identity, email, or cloud logs. Data connectors are still required.

Trap 3: Memorizing a Specific Price

Do not memorize an exact per-GB price from a course video. Microsoft pricing varies by region, plan, and date. Understand the model: ingestion, retention, and extra capabilities drive cost.

Trap 4: Choosing Microsoft Defender XDR When the Scenario Requires SIEM

If the scenario involves collecting and correlating data from many Microsoft and non-Microsoft sources, Microsoft Sentinel is usually the better answer.

Trap 5: Choosing Sentinel When the Scenario Is Only Defender Investigation

If the incident is fully within Defender for Endpoint, Defender for Office 365, Defender for Identity, or Defender XDR, the best first investigation path may be Microsoft Defender XDR.

Trap 6: Ignoring RBAC

A user who only triages incidents should not need broad Azure subscription permissions. Use Sentinel-specific roles where possible.

Trap 7: Forgetting Cost Governance

A production Sentinel deployment must include cost planning. Ingesting every verbose log source without filtering, retention planning, or business justification can create major billing issues.

Trap 8: Assuming the Azure Portal Will Always Be the Primary Sentinel Portal

The Azure portal experience is still useful to understand, but Microsoft has announced that Sentinel will be available only in the Microsoft Defender portal after March 31, 2027.

Real-World SOC Analyst Notes

Cost Control Matters

Sentinel can be extremely valuable, but it can also become expensive if organizations ingest high-volume logs without planning. Examples of noisy sources include firewall traffic logs, DNS logs, proxy logs, endpoint telemetry, and verbose cloud audit data.

A good SOC does not simply ingest everything. It prioritizes data sources based on detection value, compliance requirements, retention needs, and investigation usefulness.

Data Source Coverage Determines Investigation Quality

If Sentinel does not have the right logs, the analyst may not be able to answer basic incident questions:

• Which user was involved?
• Which device was affected?
• What IP address initiated the activity?
• Was the activity successful?
• Did the threat move laterally?
• Was email involved?
• Was a cloud resource modified?
• Is this isolated or widespread?

Sentinel is only as useful as the data connected to it.

RBAC Should Match SOC Roles

Tier 1 analysts may need to view and manage incidents, but they usually should not be able to modify analytics rules, delete resources, or change workspace settings. Security engineers may need Contributor rights to create analytics rules, deploy content, and manage automation.

Separate roles help reduce the risk of accidental tenant-wide changes.

Workspace Design Affects Escalation

In a large organization, multiple teams may use the same Sentinel workspace:

• SOC analysts
• Identity team
• Endpoint team
• Cloud operations
• Network team
• Compliance team
• Incident response team

A dedicated resource group and clear RBAC model make escalation cleaner. Analysts should know who owns connectors, analytics rules, playbooks, and cost management.

Evidence Preservation and Retention

Retention settings matter during incident response. If data retention is too short, analysts may lose evidence needed for historical investigation. If retention is too long without planning, costs may increase unnecessarily.

A real-world SOC should align retention with:

• Regulatory requirements
• Incident response needs
• Threat hunting needs
• Legal hold requirements
• Budget constraints

Automation Safety

Although this lesson focuses on setup, Sentinel planning should account for future automation. Playbooks can disable users, isolate devices, block IP addresses, or notify teams. Those actions require careful permissions, testing, and change control.

Do not give automation more privilege than it needs.

Quick Reference Summary

• Microsoft Sentinel requires a Log Analytics workspace.
• The workspace stores the data Sentinel uses for detections, analytics, hunting, and dashboards.
• Enabling Sentinel does not automatically connect data sources.
• Data connectors are required before Sentinel can generate meaningful detections.
• Pricing is heavily affected by ingestion volume and retention.
• Microsoft currently documents a 31-day trial with up to 10 GB/day for Analytics logs.
• Use a dedicated resource group for Sentinel resources when possible.
• Use least-privilege RBAC for analysts, engineers, and automation.
• Sentinel Reader, Responder, Contributor, and Playbook Operator serve different roles.
• Workspace planning affects cost, access, retention, compliance, and investigation quality.
• KQL queries depend on data being present in the workspace.
• Azure portal setup knowledge is useful, but Microsoft is moving Sentinel fully into the Defender portal after March 31, 2027.

Flashcards

Q: What Azure resource is required before enabling Microsoft Sentinel?
A: A Log Analytics workspace.

Q: What does the Log Analytics workspace do for Microsoft Sentinel?
A: It stores the log data that Sentinel uses for analytics, detections, hunting, workbooks, and investigations.

Q: Does enabling Microsoft Sentinel automatically ingest security logs?
A: No. Data connectors or diagnostic settings must be configured to ingest useful data.

Q: What is the purpose of Microsoft Sentinel data connectors?
A: They bring data from Microsoft and third-party sources into the Log Analytics workspace.

Q: What is the main cost driver for Microsoft Sentinel?
A: Data ingestion volume, with retention and extra capabilities also affecting cost.

Q: What role is appropriate for an analyst who needs to manage incidents but not create Sentinel content?
A: Microsoft Sentinel Responder.

Q: What role is commonly needed to create analytics rules and manage Sentinel content?
A: Microsoft Sentinel Contributor.

Q: What feature would you use to visualize Sentinel data?
A: Workbooks.

Q: What feature would you use to search Sentinel data manually with KQL?
A: Hunting queries or Logs.

Q: What feature creates detections from ingested data?
A: Analytics rules.

Q: Why is a dedicated resource group recommended for Sentinel resources?
A: It simplifies RBAC, access management, and organization of related resources.

Q: What should you check before enabling high-volume data sources?
A: Cost, ingestion value, retention needs, and detection use cases.

Q: What happens if the required data source is not connected?
A: Sentinel cannot query or detect activity from that source.

Q: Which platform is Microsoft moving Sentinel toward for the unified security operations experience?
A: The Microsoft Defender portal.

Q: What should you avoid memorizing from pricing examples in training videos?
A: Exact per-GB prices, because they vary by region, date, and pricing plan.

Practice Questions

Question 1:

You are preparing to deploy Microsoft Sentinel for a new SOC lab. You have an Azure subscription and appropriate permissions. What must you create or select before enabling Microsoft Sentinel?

A. Microsoft Defender for Endpoint device group
B. Log Analytics workspace
C. Microsoft Purview compliance portal
D. Azure Key Vault

Correct Answer:
B. Log Analytics workspace

Explanation:
Microsoft Sentinel is enabled on a Log Analytics workspace. The workspace stores the log data that Sentinel uses for analytics, detections, hunting, and workbooks.

Question 2:

You enabled Microsoft Sentinel on a new workspace, but no incidents are being generated. You have not configured any data connectors yet. What is the most likely reason?

A. Sentinel incidents only work with Microsoft Defender for Cloud
B. Sentinel has no ingested security data to analyze
C. The workspace name is invalid
D. KQL must be enabled manually

Correct Answer:
B. Sentinel has no ingested security data to analyze

Explanation:
Enabling Sentinel does not automatically ingest logs. Data connectors must be configured before analytics rules can detect activity and generate meaningful incidents.

Question 3:

A company wants to deploy Microsoft Sentinel in production and connect several high-volume firewall, DNS, and endpoint data sources. What should be reviewed before enabling all connectors?

A. Microsoft Teams external access settings
B. Sentinel and Log Analytics ingestion and retention costs
C. Windows Defender Firewall local policy only
D. Microsoft Purview sensitivity labels

Correct Answer:
B. Sentinel and Log Analytics ingestion and retention costs

Explanation:
Sentinel cost is heavily influenced by data ingestion and retention. High-volume sources can significantly increase monthly Azure costs.

Question 4:

A Tier 1 SOC analyst needs to view Sentinel incidents and update incident status during triage. The analyst should not create analytics rules or modify Sentinel resources. Which role best fits this requirement?

A. Owner
B. Microsoft Sentinel Contributor
C. Microsoft Sentinel Responder
D. Logic App Contributor

Correct Answer:
C. Microsoft Sentinel Responder

Explanation:
Microsoft Sentinel Responder includes incident management capabilities without granting broader content creation and resource modification rights.

Question 5:

You run a KQL query against the SecurityEvent table in Sentinel, but the table has no data. What is the best next step?

A. Recreate the Sentinel workspace
B. Configure the appropriate data connector or log collection source
C. Disable Microsoft Defender XDR
D. Convert the query to SQL

Correct Answer:
B. Configure the appropriate data connector or log collection source

Explanation:
KQL queries can only return data that exists in the workspace. If the relevant logs are not being collected, the first step is to configure ingestion.