Common interview slip
Many candidates say 'Sentinel is just a Log Analytics workspace' or confuse Scheduled rules with NRT rules, or think playbooks are built with Azure Functions. These slips cost marks in a Sentinel interview.
Microsoft Sentinel is a cloud-native SIEM and SOAR built on top of a Log Analytics workspace — the workspace is the data store, but Sentinel adds the detection engine (analytics rules), entity enrichment (UEBA), investigation graph, and response automation (SOAR playbooks). They are not the same thing. NRT (Near Real-Time) rules process logs with roughly one-minute latency — they are not the same as Scheduled rules which run on a configurable cadence (every 5 minutes to every 14 days). And playbooks in Sentinel are Azure Logic Apps, not Azure Functions — the Logic App designer provides the low-code trigger-action workflow that analysts can build and trigger from an incident. Knowing these distinctions is exactly what interviewers probe.
① Fundamentals & Architecture — workspace, SIEM layers and pricing
Q: What is Microsoft Sentinel and how does it relate to a Log Analytics workspace?
Model answer: Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation and Response) service built on Azure. Under the hood it stores all ingested security data in a Log Analytics workspace — part of Azure Monitor — and Sentinel adds four capability layers on top: data collection (connectors to ingest logs), detection (analytics rules that run KQL), investigation (the incident and entity graph), and response (Logic App playbooks). The workspace is the data lake; Sentinel is the intelligence and automation engine above it. You can have more than one Sentinel instance per tenant (one per workspace) but Microsoft recommends a single workspace per organization unless regulatory or latency requirements force data residency separation.
Q: How is Microsoft Sentinel priced, and what is the Pay-As-You-Go vs Commitment Tier difference?
Model answer: Sentinel is billed on data ingestion volume (GB per day) from the Log Analytics workspace. There are two modes: Pay-As-You-Go (PAYG) — you pay per GB with no minimum, best for unpredictable or low volumes — and Commitment Tiers (formerly Capacity Reservations), where you commit to a fixed daily GB level (100 GB, 200 GB, 300 GB, 500 GB, 1 TB, 2 TB per day or more) at a discounted effective-per-GB rate. The break-even crossover is around 100 GB/day. Some data sources are free to ingest into Sentinel — notably Azure Active Directory sign-in and audit logs, Azure Activity logs, and Microsoft Defender for Cloud alerts. Knowing the free-ingestion sources is a strong pricing answer.
Q: What is the difference between Microsoft Sentinel and Microsoft Defender XDR (formerly Microsoft 365 Defender)?
Model answer: Microsoft Defender XDR is a unified XDR (Extended Detection and Response) platform that correlates signals across endpoints (Defender for Endpoint), identities (Defender for Identity), email (Defender for Office 365) and cloud apps (Defender for Cloud Apps) — it focuses on the Microsoft product estate and has its own incident queue. Microsoft Sentinel is a SIEM that ingests logs from any source — Microsoft and third-party — providing broader security analytics, long-term retention, custom analytics rules, threat hunting, and SOAR playbooks. In 2026, the two are deeply integrated: Defender XDR incidents can be synchronised bi-directionally into Sentinel, and analysts can work from a unified SOC portal in the Defender portal. The interview point: Sentinel = broad SIEM/SOAR; Defender XDR = Microsoft-product XDR; together they form the Microsoft unified SOC.
When an interviewer asks about Sentinel costs, name the free-ingestion sources: Azure Active Directory sign-in and audit logs, Azure Activity logs, Microsoft Defender for Cloud alerts, and Microsoft 365 Defender incidents. Organisations with heavy Azure AD usage can ingest millions of authentication events at no extra Sentinel cost — naming this shows you understand the pricing model, not just that it is 'per GB'.
Microsoft Sentinel stores all ingested security data in which Azure service?
② Connectors & KQL — ingesting data and querying it
Q: What connector types does Microsoft Sentinel offer, and how do you connect a non-Microsoft firewall?
Model answer: Sentinel provides four connector categories. Microsoft first-party connectors (one-click): Azure AD, Microsoft Defender for Endpoint, Defender for Identity, Office 365, Azure Activity — often free ingestion. Partner / third-party connectors in the Content Hub: ready-made connectors for Palo Alto, Cisco, Fortinet and hundreds more. CEF (Common Event Format) over Syslog: the universal method for security appliances that cannot use an API — the appliance forwards CEF-formatted syslog to a Log Analytics agent (AMA — Azure Monitor Agent) on a Linux forwarder VM, which ships them to the workspace. REST API / custom connector: for sources without a ready connector, you POST data directly to the Log Analytics HTTP Data Collector API or use the newer Data Collection Rules (DCRs) pipeline. For a non-Microsoft firewall without a partner connector, the answer is CEF over Syslog via an AMA-enabled Linux forwarder.
Q: Write a KQL query to find all failed sign-in events in the last 24 hours grouped by user account, and explain the key operators.
Model answer:
KQL (Kusto Query Language) is the query language used in all Sentinel analytics rules, workbooks and hunting queries. Key operators you must know: where — filters rows (like SQL WHERE); summarize — aggregates rows (like GROUP BY); extend — adds a calculated column; project — selects specific columns; join — joins two tables; render — visualises (timechart, barchart). A failed-sign-in query looks like:
- SigninLogs — the AAD sign-in table
- | where TimeGenerated > ago(24h) — last 24 hours
- | where ResultType != 0 — non-zero = failure
- | summarize FailedAttempts = count() by UserPrincipalName, IPAddress — count per user/IP
- | where FailedAttempts > 10 — only high-count accounts
- | order by FailedAttempts desc — worst first
That pattern — filter, summarize, threshold-filter, order — is the skeleton of most Sentinel detection rules.
Microsoft Sentinel is a cloud-native SIEM/SOAR built on a Log Analytics workspace. The workspace stores all data; Sentinel adds detection (analytics rules), investigation (entity graph, UEBA) and response (Logic App playbooks) on top.
To connect a non-Microsoft firewall: deploy an AMA-enabled Linux forwarder VM, configure the device to forward CEF-formatted syslog to it, and it ships events to the Log Analytics workspace. This is the universal method for third-party security appliances.
Scheduled rules run KQL on a configurable cadence (5 min to 14 days). NRT (Near Real-Time) rules run continuously with ~1-minute latency for time-sensitive detections. Fusion is the ML correlation engine that combines both into multi-stage incidents.
Sentinel playbooks are Azure Logic Apps triggered by a Sentinel alert or incident event. Automation rules are the policy layer that decides when to run them automatically based on incident conditions (severity, rule name, etc.).
KQL (Kusto Query Language) shares some concepts with SQL but is not SQL. The biggest mistake is writing SQL-style GROUP BY instead of KQL's summarize, or using SELECT instead of project. In a live interview coding question, always use KQL syntax: pipe-chained operators (| where, | summarize, | extend, | project, | order by), not SQL clauses. Another slip is forgetting that KQL is case-sensitive for column names — TimeGenerated not timegenerated.
You need to connect a Palo Alto firewall to Microsoft Sentinel. No first-party connector exists. What is the recommended approach?
③ Analytics, UEBA & Hunting — detecting and hunting threats
Q: What are the analytics rule types in Microsoft Sentinel, and when would you use each?
Model answer: Sentinel has five analytics rule kinds. Scheduled rules run a KQL query on a configurable cadence (every 5 minutes to every 14 days) over a lookback window — use for most custom detections. NRT (Near Real-Time) rules run continuously with roughly one-minute latency — use when you cannot wait a 5-minute window (e.g. account-lockout events). Fusion is Microsoft's ML-based multi-stage attack correlation engine — it correlates low-fidelity alerts from multiple sources and Sentinel tables into high-confidence incidents (like an account compromise followed by lateral movement); you enable it and it runs automatically. Microsoft Security rules automatically create Sentinel incidents from alerts in connected Defender products (e.g. every Defender for Endpoint high-severity alert becomes a Sentinel incident). Anomaly rules use built-in ML models to surface unusual behaviour patterns. The interview key: Scheduled = your KQL on a timer; NRT = near real-time KQL; Fusion = ML correlation; Microsoft Security = Defender bridge; Anomaly = ML baseline.
Q: What is UEBA in Microsoft Sentinel and how does it help detect insider threats?
Model answer: UEBA (User and Entity Behaviour Analytics) baselines the normal behaviour of users, hosts, IP addresses and applications using ML over a learning period (typically 7–14 days), then surfaces deviations as entity anomaly scores. Key components: the UEBA entity pages (click any entity in an incident and see a timeline of all activity, related alerts, anomalies and a peer-group comparison — is this user's login at 2 AM unusual for their role?), the IdentityInfo table (enriches entity data with Azure AD job titles, groups and roles), and the BehaviorAnalytics table (stores anomaly signals you can query in KQL or use as alert evidence). For an insider threat scenario, UEBA is powerful because a compromised or malicious insider may never trigger a signature-based rule — but their behaviour deviating from their own and peer baseline (accessing unusual file shares at odd hours, bulk downloads) surfaces as a rising anomaly score. The interview point: UEBA = ML baseline of normal entity behaviour; anomaly score = deviation signal; entity pages = investigation pivot.
Q: How does hunting work in Microsoft Sentinel, and what is the role of bookmarks?
Model answer: Hunting in Sentinel is proactive threat investigation — analysts run KQL queries (called hunting queries) across all ingested data to look for indicators of compromise or attack patterns before a rule fires. Sentinel ships hundreds of built-in hunting queries from the Content Hub, and analysts can write their own. The workflow: run a hunting query, find suspicious rows, then add them as bookmarks — a bookmark pins a specific row (a specific event, IP, user) to a named investigation, annotating it with tags and MITRE ATT&CK tactics. Bookmarks accumulate in the Incidents view and can be promoted to an incident or linked to an existing one. In 2026 Sentinel also integrates threat intelligence (TI) import via TAXII/STIX so hunting queries can join against known malicious IPs or hashes in the ThreatIntelligenceIndicator table.
UEBA in Sentinel requires explicit enablement under Settings ▸ Entity behaviour ▸ Enable UEBA, and a minimum data-source selection (Azure AD and/or audit logs). If an interviewer asks why UEBA anomaly scores are not appearing, the first check is whether UEBA is enabled and which entity types are selected. The learning period is 7 to 14 days — scores are not instant after you flip the switch.
▶ Watch a password-spray alert become a Sentinel incident — and find why UEBA missed it
Step through how sign-in failure events flow from Azure AD into a Sentinel incident. Press Play for the healthy detection path, then Break it to see the classic 'UEBA not enabled' gap.
Which Microsoft Sentinel analytics rule type uses ML to correlate low-fidelity alerts from multiple sources into a single high-confidence incident?
④ SOAR, Incidents & Scenarios — playbooks and triage workflow
Q: How do SOAR playbooks work in Microsoft Sentinel, and how do you trigger one automatically?
Model answer: Sentinel playbooks are Azure Logic Apps workflows. A Logic App starts with a Sentinel trigger — either When a Microsoft Sentinel alert is created or When a Microsoft Sentinel incident is created / updated — then adds actions (email, Teams message, block an IP in a firewall via API, disable a user in AAD, create a ticket in ServiceNow, etc.). You attach a playbook to an automation rule so it runs automatically: automation rules fire on incident create/update matching specified conditions (e.g. severity = High, analytic rule name = Brute Force) and can change severity, assign owner and run a playbook — all in sequence. The distinction interviewers check: playbooks are Logic Apps triggered by Sentinel events; automation rules are the policy layer that decides when to run them automatically. A playbook can also be run manually from an incident's context menu.
Q: Walk me through the standard Microsoft Sentinel incident triage workflow from alert to close.
Model answer: The triage flow: (1) Alert fires from an analytics rule and is grouped into an incident (alert grouping lets related alerts from the same rule or same entities merge into one incident over a time window). (2) Assign the incident to an analyst and set status = Active. (3) Investigate using the Investigation graph — a visual map of entities (users, IPs, hosts, files) and their relationships to the alert events; expand nodes to see related alerts, sign-ins, and process trees. (4) Check entity pages for UEBA anomaly scores and Azure AD context. (5) Run a playbook to auto-enrich or contain (block IP, disable user). (6) Add comments and document findings in the incident. (7) Close the incident with a classification: True Positive (malicious activity confirmed), Benign Positive (real event, expected), or False Positive (rule needs tuning). The close classification feeds back into Sentinel's ML to improve future accuracy.
Q: A senior engineer asks you to detect a password spray attack in Sentinel. Describe your end-to-end approach.
Model answer: A password spray is one password tried across many accounts — it produces many failed logins across different UserPrincipalNames from the same IP in a short window. Approach: (1) Write a Scheduled KQL rule on SigninLogs: filter ResultType != 0 (failure), summarize FailedCount = count(), DistinctUsers = dcount(UserPrincipalName) by IPAddress in a 10-minute window, threshold on DistinctUsers > 20. (2) Set the entity mapping on the rule to map IPAddress and UserPrincipalName so Sentinel enriches the incident with entity context and UEBA data. (3) Add a MITRE ATT&CK tactic tag: T1110.003 (Password Spraying) so the Sentinel MITRE coverage map shows it. (4) Create an automation rule on this analytic rule: auto-assign severity = High and trigger a playbook that calls the Azure AD API to confirm MFA is enforced on the affected accounts and posts an alert to the SOC Teams channel. (5) After close, tune the threshold based on false-positive rate. The interviewer is looking for: KQL logic, entity mapping, MITRE tagging, and playbook automation — not just a query.
Arjun at FinServe India in Mumbai faces this
FinServe India's SOC analyst Arjun notices a high-severity Sentinel incident titled 'Possible Password Spray Attack' — but the incident shows 200 failed sign-in attempts from a single IP targeting 85 different user accounts in 10 minutes. No playbook fired automatically. The CEO's account appears in the entity list.
The analytics rule for password spray exists but no automation rule was created to link it to a playbook. As a result, no automatic enrichment or containment action ran when the incident was created, leaving the SOC to triage manually during a potentially active attack.
Arjun opens the incident in Sentinel, clicks Investigate to open the entity graph, and sees the source IP mapped to an Eastern European geolocation. He checks the CEO entity page — UEBA shows an anomaly score spike and the CEO's account has 3 successful sign-ins from an unrecognised device following the spray. The BehaviorAnalytics table confirms the anomaly.
Microsoft Sentinel ▸ Incidents ▸ [Incident] ▸ Investigate (entity graph) ▸ Entity pages ▸ BehaviorAnalytics tableArjun runs the 'Block-IP-and-Confirm-MFA' Logic App playbook manually from the incident context. The playbook calls the Azure AD Conditional Access API to enforce MFA on the CEO's account and posts a priority alert to the #soc-alerts Teams channel. He then creates an automation rule so future password-spray incidents auto-trigger this playbook on creation.
The CEO is prompted for MFA on the next sign-in, confirming the policy applied. Arjun closes the incident as True Positive, adds a comment with the MITRE ATT&CK reference (T1110.003), and creates a tuning task to adjust the analytics rule threshold to reduce false positives from legitimate bulk-login tools.
An analyst closes a Microsoft Sentinel incident as 'False Positive'. What is the primary operational benefit of this classification?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the difference between a Sentinel Scheduled rule, an NRT rule, and Fusion — and when would you use each? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Log Analytics Workspace
- The Azure Monitor data store that underpins Microsoft Sentinel — all ingested security logs are stored here and queried with KQL. Sentinel adds detection, investigation and SOAR on top.
- KQL (Kusto Query Language)
- The pipe-chained query language used in Sentinel for analytics rules, hunting queries and workbooks. Key operators: where, summarize, extend, project, join, render.
- Scheduled Analytics Rule
- A Sentinel analytics rule that runs a KQL query on a configurable cadence (5 minutes to 14 days) over a lookback window and generates alerts when threshold conditions are met.
- NRT Rule
- Near Real-Time analytics rule in Sentinel — runs KQL continuously with approximately 1-minute latency, used for time-critical detections where a 5-minute schedule is too slow.
- Fusion
- Microsoft's ML-based multi-stage attack correlation engine in Sentinel. Correlates low-fidelity signals from multiple sources into high-confidence incidents representing multi-stage attacks.
- UEBA
- User and Entity Behaviour Analytics — baselines normal behaviour for users, hosts and IPs using ML, then surfaces deviations as anomaly scores in the BehaviorAnalytics table and entity pages.
- CEF/Syslog via AMA
- The standard connector method for non-Microsoft security appliances. The device forwards CEF-formatted syslog to an AMA-enabled Linux forwarder VM, which ships events to the Log Analytics workspace.
- Automation Rule
- The policy layer in Sentinel that fires automatically on incident create/update conditions (severity, rule name) to assign owners, change severity or trigger Logic App playbooks.
- Logic App Playbook
- Azure Logic Apps used as Sentinel SOAR playbooks. Triggered by Sentinel alert or incident events, they automate enrichment and response actions (block IP, disable user, alert team, create ticket).
- Commitment Tier
- A Sentinel pricing mode where you reserve a daily GB ingestion level (100 GB, 200 GB, 500 GB, 1 TB etc.) at a discounted effective per-GB rate compared to Pay-As-You-Go.
📚 Sources
- Microsoft — What is Microsoft Sentinel? learn.microsoft.com/azure/sentinel/overview
- Microsoft — Microsoft Sentinel pricing. learn.microsoft.com/azure/sentinel/billing
- Microsoft — Data connectors in Microsoft Sentinel — CEF, Syslog, REST API. learn.microsoft.com/azure/sentinel/connect-data-sources
- Microsoft — Analytics rules in Microsoft Sentinel: Scheduled, NRT, Fusion and Anomaly. learn.microsoft.com/azure/sentinel/detect-threats-built-in
- Microsoft — User and Entity Behaviour Analytics (UEBA) in Microsoft Sentinel. learn.microsoft.com/azure/sentinel/identify-threats-with-entity-behavior-analytics
- Microsoft — Automate incident handling in Microsoft Sentinel with automation rules and playbooks. learn.microsoft.com/azure/sentinel/automate-incident-handling-with-automation-rules
What's next?
Done with the interview prep? Go deeper on Microsoft Sentinel design — workspace architecture and cost optimisation, advanced KQL for threat hunting, Fusion ML correlation, UEBA entity behaviour, and building production SOAR playbooks with Logic Apps.