Microsoft Sentinel SIEM and SOAR Fundamentals – SC-200 Study Guide

Study guide

Technical reference and lesson notes

Purpose of This Lesson

This lesson introduces Microsoft Sentinel as Microsoft’s cloud-native security information and event management and security orchestration, automation, and response platform.

For the SC-200 Microsoft Security Operations Analyst exam, Sentinel is one of the most important products to understand because it sits at the center of many SOC workflows. A Microsoft Security Operations Analyst uses Sentinel to collect security data, detect threats, investigate incidents, hunt for suspicious activity, and automate response actions.

At a high level, Sentinel helps analysts answer questions such as:

What happened?
Which users, devices, IP addresses, files, or cloud resources were involved?
Is this alert part of a larger incident?
What is the scope and impact?
What should be contained, remediated, escalated, or documented?
How can detection and response be improved next time?

Microsoft Sentinel is especially exam-relevant because many SC-200 scenario questions ask you to choose between Microsoft Defender XDR, Microsoft Sentinel, analytics rules, automation rules, playbooks, hunting queries, data connectors, and workbooks.

Key Concepts

What Is Microsoft Sentinel?

Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR solution.

It provides two major security operations capabilities:

SIEM – Security Information and Event Management
SOAR – Security Orchestration, Automation, and Response

Sentinel is designed to centralize security data from many different sources, analyze that data for suspicious activity, create incidents, support investigations, and automate response actions.

In plain English, Sentinel acts like an enterprise security watchtower. It collects signals from across Microsoft cloud services, Azure resources, on-premises systems, and third-party security tools so analysts can monitor and respond from one place.

SIEM: Security Information and Event Management

A SIEM collects logs, events, alerts, and security telemetry from multiple systems and stores them in a centralized platform for searching, correlation, investigation, reporting, and detection.

Microsoft did not invent the SIEM category. Sentinel is Microsoft’s cloud-native implementation of this long-standing security operations concept.

A SIEM is useful because modern environments generate massive amounts of telemetry from many different systems, including:

Endpoints
Firewalls
Identity providers
Email platforms
Cloud workloads
SaaS applications
Network devices
Servers
Applications
Containers
Security appliances

Without a SIEM, analysts would have to log into many separate tools to understand what happened. Sentinel reduces that operational burden by bringing the data into one security monitoring platform.

What Sentinel Does as a SIEM

Sentinel can help a SOC team:

Collect security logs from many sources
Normalize or structure data into searchable tables
Correlate related events
Detect suspicious behavior
Generate alerts and incidents
Support investigation workflows
Enable threat hunting using KQL
Provide dashboards and reporting through workbooks

For SC-200, remember that Sentinel is the tool you use when you need centralized detection, correlation, hunting, and investigation across multiple data sources.

SOAR: Security Orchestration, Automation, and Response

SOAR focuses on automating security operations tasks.

Where SIEM helps collect and analyze security data, SOAR helps respond to that data through automation.

Sentinel’s SOAR capabilities allow analysts to automate repeatable response actions instead of manually performing every step for every alert.

Examples of SOAR-style actions include:

Creating a ticket in ServiceNow, Jira, or Zendesk
Sending a message to Microsoft Teams or Slack
Triggering an HTTP request
Notifying an analyst or incident response team
Enriching an incident with additional data
Running a containment action
Interacting with Microsoft Defender for Endpoint
Interacting with Microsoft Defender for Cloud Apps
Starting a Logic App workflow

In Sentinel, SOAR is commonly implemented through playbooks, which are built using Azure Logic Apps.

Sentinel’s Core Security Operations Cycle

Microsoft Sentinel supports a SOC workflow that can be summarized as:

Collect
Detect
Investigate
Respond

This cycle is important for both real-world SOC work and SC-200 exam scenarios.

Collect: Bringing Security Data into Sentinel

The first step is collecting data.

Sentinel uses data connectors to ingest logs, alerts, and telemetry from Microsoft services, Azure resources, on-premises systems, and third-party products.

Common Microsoft Data Sources

Sentinel can connect to Microsoft security and cloud services such as:

Microsoft Defender XDR
Microsoft Defender for Endpoint
Microsoft Defender for Office 365
Microsoft Defender for Cloud
Microsoft Defender for Identity
Microsoft Defender for Cloud Apps
Microsoft Entra ID
Office 365
Azure Activity
Azure Storage
Azure Key Vault
Azure Kubernetes Service
Microsoft Defender for IoT

Third-Party and On-Premises Data Sources

Sentinel can also collect from non-Microsoft sources, including:

Firewalls
Network appliances
Linux systems using Syslog
Windows servers using Windows Event logs
Third-party endpoint tools
Security appliances
Custom applications
REST API-based integrations

Common integration methods include:

Syslog
Common Event Format
Windows Event Forwarding
REST APIs
Microsoft security connectors
Azure service connectors
Custom connectors

Exam Note

Sentinel detection depends on available data. If a data source is not connected, Sentinel cannot analyze that source’s logs.

For example, if a question asks why Sentinel is not detecting suspicious sign-ins, one possible issue is that the relevant Microsoft Entra ID logs are not connected or not being ingested.

Detect: Analytics, Correlation, and Machine Learning

After data is collected, Sentinel can detect threats by analyzing that data.

Detection can happen through:

Analytics rules
Microsoft security analytics
Threat intelligence
Machine learning
Entity correlation
Scheduled KQL queries
Near-real-time detection
Microsoft-provided rule templates

The goal is to identify activity that may represent a security threat.

Alerts vs Incidents

This distinction is critical for SC-200.

An alert is a specific detection. It usually represents one suspicious event or detection logic result.

An incident is a collection of related alerts, entities, and evidence grouped together for investigation.

In Sentinel, analytics rules can create alerts and incidents. Multiple related alerts may be correlated into a single incident to give the analyst better context.

Why Correlation Matters

A single alert may not tell the full story.

For example:

A suspicious sign-in alert may involve a user account.
An endpoint alert may involve a device.
A cloud alert may involve a storage account.
An email alert may involve a phishing message.

When those alerts are connected, Sentinel can help analysts understand the broader attack path.

This is where Sentinel becomes more valuable than isolated tools. It allows security teams to see activity across identity, endpoint, email, cloud, and third-party sources.

Investigate: Understanding Scope and Root Cause

Sentinel provides investigation capabilities that help analysts understand what happened and what was affected.

During investigation, an analyst may review:

Users
Devices
IP addresses
Hostnames
Files
URLs
Mailboxes
Cloud resources
Azure subscriptions
Applications
Processes
Related alerts
Incident timelines
Evidence and entities

Sentinel can show relationships between these entities using investigation graphs and incident details.

Typical Investigation Questions

A SOC analyst may use Sentinel to answer:

Which user account triggered the alert?
Was the sign-in successful?
What IP address was used?
Is the IP address known to be malicious?
Which device was involved?
Did the device execute suspicious processes?
Was the same account used elsewhere?
Are there related alerts in Microsoft Defender XDR?
Did the activity affect cloud resources?
Has this pattern appeared before?
Is this a false positive or a real incident?

Scope and Root Cause

Sentinel is not only used to confirm whether an alert is true or false. It is also used to determine:

Initial access method
Impacted assets
Lateral movement
Persistence
Exfiltration indicators
Related accounts or hosts
Root cause
Required remediation steps

For SC-200, investigation is not just about viewing an alert. It is about connecting evidence across multiple data sources.

Respond: Automation, Playbooks, and Orchestration

After detecting and investigating threats, Sentinel can support response actions.

Response may be manual, semi-automated, or fully automated depending on the environment and risk level.

Playbooks

A playbook is an automated workflow built with Azure Logic Apps.

Playbooks can connect to Microsoft and third-party services to perform response actions.

Examples include:

Notify a Teams channel
Create an incident ticket
Send an email notification
Query another system for enrichment
Disable or contain an entity through another security tool
Trigger an HTTP webhook
Update incident fields
Add comments to an incident
Start an approval workflow

Automation Rules

An automation rule in Sentinel controls what happens when incidents are created or updated.

Automation rules can:

Assign incidents to analysts
Change severity
Add tags
Run playbooks
Close known false positives
Trigger standardized workflows

Automation Rules vs Playbooks

This is a common exam distinction.

Automation rules manage incident-level automation inside Sentinel.
Playbooks perform workflow actions using Azure Logic Apps.

A good way to remember it:

Use an automation rule to decide when automation should happen.
Use a playbook to define what the automation actually does.

Microsoft Security Operations Context

How Sentinel Fits into a Real SOC Workflow

In a real SOC, Sentinel is often used as the central platform for security monitoring and incident response, especially in organizations heavily invested in Microsoft 365 and Azure.

A typical SOC workflow may look like this:

A data connector ingests Microsoft Entra ID sign-in logs.
An analytics rule detects suspicious sign-in behavior.
Sentinel creates an alert and groups it into an incident.
The analyst opens the incident and reviews associated entities.
The analyst checks the user, IP address, device, and related alerts.
The analyst pivots into Microsoft Defender XDR or Defender for Endpoint for deeper endpoint evidence.
The analyst determines whether the activity is malicious.
A playbook creates a ticket and notifies the response team.
The analyst documents findings and containment actions.
Detection logic is tuned if the alert was noisy or incomplete.

Triage an Alert

During triage, the analyst decides whether the alert is worth deeper investigation.

Important triage factors include:

Severity
Confidence
Affected entity
User importance
Device criticality
Known false positive patterns
Related alerts
MITRE ATT&CK tactic or technique
Threat intelligence matches
Whether the activity succeeded or failed
Whether the behavior is expected in the environment

Sentinel helps triage by grouping related alerts into incidents and exposing the entities involved.

Investigate an Incident

During investigation, the analyst reviews the full context of the incident.

Key actions include:

Review the incident timeline.
Identify all entities involved.
Check related alerts.
Review raw logs using KQL.
Pivot to Defender portals when needed.
Validate whether the activity is malicious.
Determine scope and impact.
Identify containment steps.
Document evidence.

For example, if an incident involves a compromised endpoint, Sentinel may show the incident, but Microsoft Defender for Endpoint may provide deeper device timeline, process tree, file, and remediation details.

Review Entities

Entities are objects involved in an incident.

Common entities include:

Account
Host
IP address
File
URL
Mailbox
Cloud application
Azure resource

Entity review is important because the same entity may appear in multiple alerts or incidents.

For example, if the same IP address appears across several failed sign-ins, successful sign-ins, and endpoint alerts, that IP becomes important evidence.

Determine Scope and Impact

Sentinel supports scope analysis by allowing analysts to query across large volumes of data.

An analyst may ask:

How many users were targeted?
How many devices communicated with this IP?
How many mailboxes received the phishing email?
Did any user click the link?
Did a suspicious file run on any endpoint?
Did the same attacker access Azure resources?
Did the activity spread beyond the original alert?

This is where Sentinel’s centralized log collection and KQL querying become extremely valuable.

Contain or Remediate a Threat

Sentinel can support containment and remediation, but it often works with other tools to execute the action.

Examples:

Use Microsoft Defender for Endpoint to isolate a device.
Use Microsoft Entra ID to disable a user or revoke sessions.
Use Defender for Office 365 to investigate and remediate phishing.
Use Defender for Cloud to investigate cloud workload alerts.
Use a Sentinel playbook to trigger response actions.
Use a ticketing integration to assign remediation work.

Sentinel is often the coordination and investigation layer, while other Defender products may perform workload-specific remediation.

Escalate to Another Team

Sentinel incidents may need escalation to:

Endpoint team
Identity team
Cloud operations team
Email security team
Network team
Infrastructure team
Incident response team
Legal or compliance team

A good SOC workflow includes clear escalation criteria, evidence collection, and documentation.

For example, if Sentinel identifies a suspicious sign-in followed by endpoint malware activity, the SOC may escalate to both the identity team and endpoint team.

Document Findings

Incident documentation should include:

What triggered the incident
Initial detection source
Timeline of activity
Entities involved
Evidence reviewed
Scope and impact
Analyst decision
Containment actions
Remediation steps
Escalations
Lessons learned
Detection tuning recommendations

Good documentation improves future investigations and reduces repeated manual work.

Improve Future Detection

After an incident, analysts may improve Sentinel by:

Tuning analytics rules
Adding watchlists
Creating new hunting queries
Adjusting automation rules
Building playbooks
Adding missing data connectors
Improving entity mapping
Updating incident severity logic
Creating workbooks for visibility
Adding threat intelligence indicators

This is a key part of mature security operations.

Exam-Relevant Takeaways

What to Remember for SC-200

Microsoft Sentinel is heavily tested in SC-200 because it covers detection, investigation, hunting, automation, and response.

Know these points:

Microsoft Sentinel is a cloud-native SIEM and SOAR solution.
SIEM focuses on collecting, correlating, analyzing, and searching security data.
SOAR focuses on automating response workflows.
Sentinel uses data connectors to ingest logs and alerts.
Sentinel can ingest data from Microsoft services, Azure resources, on-premises systems, and third-party tools.
Sentinel detection often depends on analytics rules.
Analytics rules can generate alerts and incidents.
An alert is a detection.
An incident is a case that groups related alerts, entities, and evidence.
Playbooks are built on Azure Logic Apps.
Automation rules can trigger playbooks and manage incident automation.
KQL is used to query Sentinel data.
Sentinel is strong for cross-platform, cross-source investigation.
Microsoft Defender XDR is strong for integrated Microsoft 365 Defender incident investigation.
Sentinel can ingest Defender XDR incidents and alerts for broader correlation and SOC operations.
Sentinel can help reduce false positives through correlation, tuning, analytics, and automation.
Sentinel is only as useful as the data sources connected to it.

Tool / Feature Decision Guide

Scenario	Best Microsoft Security Tool or Feature	Why
Collect logs from Azure, Microsoft 365, on-premises servers, and third-party appliances	Microsoft Sentinel data connectors	Data connectors bring security telemetry into Sentinel for analysis and detection.
Centralize security monitoring across multiple platforms	Microsoft Sentinel	Sentinel functions as the SIEM for cross-source monitoring and investigation.
Automate a response workflow that creates a ticket and sends a Teams message	Sentinel playbook	Playbooks use Azure Logic Apps to orchestrate actions across services.
Automatically assign new high-severity incidents to a SOC queue	Sentinel automation rule	Automation rules manage incident-level actions inside Sentinel.
Detect suspicious activity from ingested logs	Sentinel analytics rule	Analytics rules evaluate data and create alerts or incidents.
Investigate related alerts, users, hosts, IP addresses, and evidence	Sentinel incident investigation	Incidents group related security signals for analyst review.
Search logs for suspicious behavior that has not yet triggered an alert	Sentinel hunting query	Hunting queries use KQL to proactively search for threats.
Visualize trends, metrics, and security posture	Sentinel workbooks	Workbooks provide dashboards and reporting views.
Investigate endpoint process trees, device timeline, and device isolation	Microsoft Defender for Endpoint	Defender for Endpoint provides deep endpoint detection and response.
Investigate suspicious sign-ins and identity risk	Microsoft Entra ID / Microsoft Defender XDR / Sentinel	Entra provides identity logs; Sentinel can correlate them with broader activity.
Investigate phishing email and mailbox impact	Microsoft Defender for Office 365	Defender for Office 365 provides email and collaboration security investigation.
Investigate cloud workload security alerts	Microsoft Defender for Cloud	Defender for Cloud focuses on Azure, hybrid, and cloud workload protection.
Correlate Microsoft and third-party security data in one place	Microsoft Sentinel	Sentinel is designed for broader SIEM correlation beyond a single Defender product.
Manage related Microsoft 365 security alerts as one incident	Microsoft Defender XDR	Defender XDR correlates incidents across Microsoft Defender workloads.

KQL Notes

The lesson does not go deep into KQL syntax, but KQL is central to Microsoft Sentinel.

Sentinel stores ingested data in searchable tables. Analysts use Kusto Query Language, or KQL, to search those tables, investigate incidents, and build detections.

Example KQL Query: Review Recent Failed Sign-ins

This is a simple example to reinforce the concept.

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress
| order by FailedAttempts desc

What This Query Does

Query Part	Purpose
`SigninLogs`	Searches Microsoft Entra ID sign-in log data.
`where TimeGenerated > ago(24h)`	Limits the query to the last 24 hours.
`where ResultType != 0`	Filters for failed sign-in attempts.
`summarize FailedAttempts = count() by UserPrincipalName, IPAddress`	Groups failed attempts by user and source IP.
`order by FailedAttempts desc`	Shows the highest number of failures first.

How This Helps an Investigation

This type of query can help an analyst identify:

Password spray activity
Brute force attempts
Repeated failures against a specific user
Suspicious source IP addresses
Accounts that may need further review

Exam Relevance

For SC-200, you should understand that KQL is used in Sentinel for:

Hunting queries
Analytics rules
Incident investigation
Log review
Filtering noisy data
Summarizing activity
Finding patterns across security events

You do not need to memorize every possible table, but you should understand the purpose of common KQL operators such as:

where
project
summarize
extend
join
order by
ago()

Common Exam Traps

Confusing SIEM and SOAR

SIEM and SOAR are related but not the same.

SIEM collects and analyzes security data.
SOAR automates response actions.

Sentinel provides both.

Confusing Alerts and Incidents

An alert is a detection.

An incident is an investigation case that may contain one or more alerts, entities, and pieces of evidence.

In exam scenarios, if the question is about triage and investigation, the answer often involves the incident, not just the individual alert.

Assuming Sentinel Works Without Data Connectors

Sentinel needs data ingestion.

If the required logs are not connected, Sentinel cannot detect or investigate that activity.

Always check whether the correct data connector is enabled for the scenario.

Confusing Analytics Rules, Automation Rules, and Playbooks

These are different features:

Feature	Purpose
Analytics rule	Detects suspicious activity and creates alerts/incidents.
Automation rule	Applies automated logic to incidents.
Playbook	Runs response workflows using Azure Logic Apps.

A common exam trap is choosing a playbook when the question asks how to detect something. Detection usually requires an analytics rule, not a playbook.

Choosing Sentinel When a Defender Product Is More Specific

Sentinel is excellent for centralized SIEM operations, but some tasks are better handled in the workload-specific Defender portal.

Examples:

Endpoint isolation: Microsoft Defender for Endpoint
Phishing investigation: Defender for Office 365
Cloud workload recommendations and alerts: Defender for Cloud
Identity-based lateral movement signals: Defender for Identity
Cross-source SIEM correlation: Microsoft Sentinel

Forgetting Cost and Data Ingestion Considerations

Sentinel is powerful, but ingestion volume matters.

In real environments, sending every possible log into Sentinel without planning can create unnecessary cost and noise.

For the exam, remember that Sentinel depends on data connectors and retention settings. For real-world work, remember that ingestion strategy matters.

Treating Automation as Always Safe

Automation is useful, but response actions can have tenant-wide or business-impacting consequences.

For example:

Disabling users can interrupt business operations.
Isolating devices can disrupt users.
Blocking IP ranges too broadly can affect legitimate traffic.
Closing incidents automatically can hide real attacks.

Automation should be designed with severity, confidence, approval, and rollback in mind.

Real-World SOC Analyst Notes

Alert Fatigue

Sentinel can centralize a large amount of security telemetry. That is useful, but it can also create noise if detections are not tuned.

A mature SOC should review:

Which analytics rules are enabled
Which alerts generate the most noise
Which incidents are repeatedly closed as false positives
Which users or systems are expected to trigger benign alerts
Which detections need suppression logic or threshold tuning

The goal is not to alert on everything. The goal is to alert on meaningful security activity with enough context to act.

False Positives

False positives are expected in any SIEM environment.

Sentinel can help reduce false positives through:

Better analytics rules
Entity mapping
Watchlists
Suppression logic
Automation rules
Threat intelligence enrichment
Incident grouping
Historical baselining

However, analysts still need to validate whether the activity is expected, authorized, or malicious.

Investigation Quality

A good Sentinel investigation should not stop at the first alert.

The analyst should determine:

What triggered the detection
Whether the activity succeeded
What entities were involved
Whether related alerts exist
Whether the behavior occurred elsewhere
Whether containment is required
Whether another team needs to be involved

This is especially important in cloud and identity-based attacks where the original alert may only show one piece of the activity.

Escalation Paths

Sentinel can identify and coordinate incidents, but remediation often involves other teams.

For example:

Endpoint team handles device isolation or malware cleanup.
Identity team handles account disablement, MFA reset, or session revocation.
Messaging team handles phishing remediation.
Cloud team handles Azure resource containment.
Network team handles firewall or proxy blocks.
Compliance or legal teams may need evidence for serious incidents.

A Sentinel incident should contain enough evidence for the next team to act without starting over.

Evidence Preservation

Security analysts should preserve evidence before taking disruptive action when possible.

Useful evidence may include:

Raw logs
Alert details
Incident timeline
Entity relationships
Screenshots
KQL query results
Device timeline events
Email headers
IP reputation data
User activity logs

Good evidence supports escalation, root cause analysis, and post-incident reporting.

Automation Safety

Automation should be implemented carefully.

Good automation candidates include:

Ticket creation
Analyst notification
Incident tagging
Enrichment lookups
Low-risk evidence collection
Known false positive closure with strong conditions

Higher-risk automation should be controlled more carefully, such as:

Disabling accounts
Isolating devices
Deleting emails
Blocking IP addresses
Changing firewall or conditional access policies

Automation is powerful, but unsafe automation can create outages.

Change Control and Governance

In production environments, Sentinel configuration should be governed like other security infrastructure.

Changes to analytics rules, automation rules, and playbooks should be documented and reviewed.

Important governance areas include:

Who can create analytics rules
Who can modify playbooks
Who can run response actions
Which actions require approval
How rule changes are tested
How false positive tuning is tracked
How incident closure reasons are standardized

Data Retention and Cost

Sentinel can ingest large volumes of data.

Cost considerations include:

Which logs are collected
How much data is ingested daily
Retention period
Verbose diagnostic logs
High-volume firewall or proxy logs
Duplicate data from multiple sources
Long-term archival requirements

From a real-world perspective, a good Sentinel deployment balances visibility, cost, and operational value.

Quick Reference Summary

Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform.
SIEM means collecting, correlating, analyzing, and searching security data.
SOAR means automating response workflows.
Sentinel uses data connectors to ingest logs from Microsoft, Azure, on-premises, and third-party sources.
Detection in Sentinel commonly uses analytics rules.
Alerts are individual detections.
Incidents group related alerts, entities, and evidence.
Playbooks are built using Azure Logic Apps.
Automation rules manage incident-level automation.
KQL is used to search and analyze Sentinel data.
Sentinel supports the SOC lifecycle: collect, detect, investigate, respond.
Sentinel is useful for cross-source correlation and threat hunting.
Defender products are often used for workload-specific investigation and remediation.
Sentinel effectiveness depends on connected data sources, good detection logic, and safe automation.

Flashcards

Q: What are the two major security operations capabilities provided by Microsoft Sentinel?
A: SIEM and SOAR.

Q: What does SIEM stand for?
A: Security Information and Event Management.

Q: What does SOAR stand for?
A: Security Orchestration, Automation, and Response.

Q: What is the main purpose of a SIEM?
A: To collect, centralize, correlate, search, and analyze security data from multiple sources.

Q: What is the main purpose of SOAR?
A: To automate security response workflows and reduce manual analyst effort.

Q: What Sentinel feature is used to ingest logs and alerts from Microsoft and third-party sources?
A: Data connectors.

Q: What Sentinel feature is commonly used to detect suspicious activity and create alerts or incidents?
A: Analytics rules.

Q: What is the difference between an alert and an incident?
A: An alert is a specific detection; an incident groups related alerts, entities, and evidence for investigation.

Q: What technology are Microsoft Sentinel playbooks built on?
A: Azure Logic Apps.

Q: When should you use a Sentinel playbook?
A: When you need to automate a response workflow, such as creating a ticket, sending a notification, or triggering an external action.

Q: When should you use an automation rule?
A: When you want to automate incident-level actions such as assignment, tagging, severity changes, or running a playbook.

Q: What language is used to query Microsoft Sentinel data?
A: Kusto Query Language, or KQL.

Q: Why are data connectors important in Sentinel?
A: Sentinel can only analyze data that has been ingested from connected sources.

Q: Why is Sentinel useful in a SOC?
A: It centralizes security telemetry, correlates alerts, supports investigation, enables hunting, and automates response.

Q: Why should automation be implemented carefully?
A: Some automated actions, such as disabling users or isolating devices, can disrupt business operations if triggered incorrectly.

Practice Questions

Question 1:

Your organization wants to collect security logs from Microsoft Entra ID, Azure resources, Microsoft Defender products, and several third-party appliances into a centralized platform for investigation and threat detection. Which Microsoft solution should you use?

A. Microsoft Defender for Endpoint
B. Microsoft Sentinel
C. Microsoft Defender for Office 365
D. Microsoft Purview

Correct Answer:
B. Microsoft Sentinel

Explanation:
Microsoft Sentinel is Microsoft’s cloud-native SIEM and SOAR platform. It is designed to collect and correlate security telemetry from Microsoft services, Azure resources, on-premises systems, and third-party tools.

Question 2:

A SOC manager wants new high-severity Sentinel incidents to automatically be assigned to a specific analyst group and tagged for priority review. Which Sentinel feature should be used?

A. Data connector
B. Automation rule
C. Hunting query
D. Workbook

Correct Answer:
B. Automation rule

Explanation:
Automation rules are used to automate incident-level handling in Sentinel, such as assigning incidents, adding tags, changing severity, or triggering playbooks.

Question 3:

You need to create an automated workflow that sends a Microsoft Teams message and creates a ServiceNow ticket when a Sentinel incident is generated. What should you configure?

A. Playbook
B. Watchlist
C. Data connector
D. Workbook

Correct Answer:
A. Playbook

Explanation:
Sentinel playbooks are built on Azure Logic Apps and are used to orchestrate response workflows across Microsoft and third-party services.

Question 4:

An analyst is reviewing a Sentinel incident and sees multiple related detections involving the same user account, IP address, and device. What best describes the relationship between the detections and the incident?

A. The incident is a single raw log entry.
B. The incident groups related alerts, entities, and evidence for investigation.
C. The incident is only used for automated remediation.
D. The incident replaces the need for analytics rules.

Correct Answer:
B. The incident groups related alerts, entities, and evidence for investigation.

Explanation:
In Sentinel, alerts are individual detections. Incidents group related alerts and entities together so analysts can investigate the broader security event.

Question 5:

A Sentinel analytics rule is not generating alerts for suspicious sign-in behavior. The analyst discovers that Microsoft Entra ID sign-in logs are not being ingested into Sentinel. What should be configured first?

A. A workbook
B. A data connector
C. A playbook
D. An automation rule

Correct Answer:
B. A data connector

Explanation:
Sentinel depends on ingested data. If the required data source is not connected, Sentinel cannot analyze that activity or generate detections from it.