Study guide
Technical reference and lesson notes
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:
- Go to the Azure portal.
- Search for Log Analytics workspaces.
- Create a workspace.
- Select or create a resource group.
- Provide a workspace name.
- Select a region.
- 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:
- Open Microsoft Sentinel.
- Select Create or Add.
- Choose the Log Analytics workspace.
- 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:
- Deploy Sentinel workspace
- Create or select a Log Analytics workspace.
- Enable Microsoft Sentinel.
- Connect data sources
- Microsoft Defender XDR
- Microsoft Entra ID
- Microsoft Defender for Cloud
- Firewalls
- Endpoint logs
- Syslog/CEF sources
- Enable analytics rules
- Detect suspicious activity.
- Correlate events.
- Generate alerts and incidents.
- Triage incidents
- Review severity, tactics, entities, and evidence.
- Determine whether the incident is true positive or false positive.
- Investigate entities
- Users
- Devices
- IP addresses
- Files
- Mailboxes
- Cloud resources
- Contain or remediate
- Disable account.
- Isolate endpoint.
- Block IP address.
- Remove malicious email.
- Trigger playbook.
- 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.