# Microsoft Sentinel Interview Questions — Cloud SIEM Answers & Prep 2026 Source: https://ai.techclick.in/blog_microsoft_sentinel_interview_qa Markdown: https://ai.techclick.in/blog_microsoft_sentinel_interview_qa.md Publisher: Techclick Infosec Pvt Ltd Prepare for a Microsoft Sentinel cloud SIEM interview with 12 real questions and model answers covering workspace architecture, data connectors and KQL, analytics rules and UEBA, plus SOAR playbooks and incident management. Microsoft Sentinel Interview Questions — Cloud SIEM Answers & Prep 2026 student learning map A visual study map for Microsoft Sentinel Interview Questions — Cloud SIEM Answers & Prep 2026 showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Sentinel Interview Questions — Cloud SIEM... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① Fundamentals & Architecture... 4. Practice ② Connectors & KQL — ingesting... How to use this page First build the mental model, then answer with the flow, evidence, safe fix, and verification. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. 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. Figure 1 — Sentinel architecture layers Sentinel adds detection, investigation and response on top of the Log Analytics workspace data store. - Sentinel architecture layers SOAR & Response Logic App playbooks, automation rules Investigation Incident graph, entity pages, UEBA Detection Engine Analytics rules, Fusion ML, Anomaly Log Analytics Workspace All ingested data — KQL query layer Sentinel adds detection, investigation and response on top of the Log Analytics workspace data store. Figure 2 — Sentinel vs Defender XDR Sentinel is the broad SIEM/SOAR; Defender XDR is the Microsoft-product XDR — both feed the unified SOC. Sentinel vs Defender XDR Microsoft Sentinel Broad SIEM + SOAR Any data source via connectors Custom KQL analytics rules Long-term retention Unified SOC portal Defender XDR Microsoft-estate XDR Endpoint, Identity, Email, Cloud Auto-correlation across M365 Bi-directional incident sync Unified SOC portal Sentinel is the broad SIEM/SOAR; Defender XDR is the Microsoft-product XDR — both feed the unified SOC. Name the free-ingestion sources in pricing questions 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'. Quick check · Q1 of 10 · Remember Microsoft Sentinel stores all ingested security data in which Azure service? a) An Azure SQL Database b) A Log Analytics workspace in Azure Monitor c) An Azure Blob Storage account d) Azure Cosmos DB Correct: b. Sentinel is built on a Log Analytics workspace in Azure Monitor — the workspace is the underlying data store. Sentinel adds the detection engine, entity enrichment, investigation graph and SOAR playbooks on top. SQL Database, Blob Storage, and Cosmos DB are not the Sentinel data store. 👉 So far: Sentinel = cloud-native SIEM/SOAR built on a Log Analytics workspace. Workspace = data store; Sentinel adds detection, investigation, and SOAR response on top. Billing is per GB ingested; free sources include Azure AD sign-in logs, Azure Activity logs, and Defender for Cloud alerts. Commit to a tier at 100+ GB/day for lower effective cost. ## ② 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. Figure 3 — Sentinel connector types Sentinel ingests data via first-party connectors, partner connectors, CEF/Syslog forwarders, and REST API. - Sentinel connector types Log Analytics Workspace Azure / M365 1st-party Partner connectors CEF/Syslog (AMA) REST API / DCR Threat Intel (TAXII) Sentinel ingests data via first-party connectors, partner connectors, CEF/Syslog forwarders, and REST API. 🏗 Sentinel Architecture tap to flip 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. 🔌 CEF/Syslog Connector tap to flip 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. ⚡ NRT vs Scheduled tap to flip 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. 🤖 Playbook = Logic App tap to flip 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 is just like SQL' mistake 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. Quick check · Q2 of 10 · Apply You need to connect a Palo Alto firewall to Microsoft Sentinel. No first-party connector exists. What is the recommended approach? a) Email the logs to a mailbox and parse them manually b) Use the Azure SQL import wizard c) Forward CEF-formatted syslog to an AMA-enabled Linux forwarder VM d) Write a PowerShell script to copy log files to Blob Storage Correct: c. The standard method for non-Microsoft security appliances is CEF (Common Event Format) over Syslog via an AMA-enabled (Azure Monitor Agent) Linux forwarder VM. The forwarder receives the syslog stream and ships it to the Log Analytics workspace. Many vendors also have partner connectors in the Content Hub, but CEF/Syslog is the universal fallback. 👉 So far: Connector types: first-party (Azure/M365, one-click), partner (Content Hub), CEF/Syslog via AMA Linux forwarder (universal for third-party appliances), REST API/DCR (custom). KQL operators: where (filter), summarize (aggregate), extend (new column), project (select columns), join (two tables), render (visualise). Pattern = filter | summarize | threshold-filter | order by. ## ③ 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. Figure 4 — Analytics rule to incident A Scheduled or NRT rule fires an alert; alerts are grouped into an incident for triage and investigation. Analytics rule to incident Log ingested connector to workspace KQL rule runs Scheduled or NRT Alert created entity mapped Incident opened alerts grouped Triage & close assign, investigate, close A Scheduled or NRT rule fires an alert; alerts are grouped into an incident for triage and investigation. Confirm UEBA is enabled before the interview scenario 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. ① AAD sign-in logs Azure AD streams failed sign-in events (ResultType != 0) into the Log Analytics workspace via the first-party Azure AD connector. ▼ ② Scheduled KQL rule A Scheduled analytics rule runs every 5 minutes, queries SigninLogs, and detects > 20 failed logins targeting distinct accounts from the same IP in 10 minutes. ▼ ③ Alert + entity map Sentinel creates an alert, mapping the source IP and the affected UserPrincipalNames as entities, and tags the MITRE tactic T1110.003 (Password Spraying). ▼ ④ Incident + UEBA pivot Alerts are grouped into an incident. The analyst opens entity pages and BehaviorAnalytics to check if any targeted account has a UEBA anomaly score spike indicating successful compromise. Press Play to step through a password-spray detection path in Microsoft Sentinel. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Understand Which Microsoft Sentinel analytics rule type uses ML to correlate low-fidelity alerts from multiple sources into a single high-confidence incident? a) Fusion rule b) Scheduled rule c) NRT (Near Real-Time) rule d) Microsoft Security rule Correct: a. Fusion is Microsoft's ML-based multi-stage attack correlation engine in Sentinel. It correlates low-fidelity signals from multiple data sources and analytics tables into high-confidence incidents representing multi-stage attacks. Scheduled and NRT rules are KQL-based; Microsoft Security rules bridge Defender product alerts. 👉 So far: Analytics rule types: Scheduled (KQL on cadence), NRT (~1 min latency), Fusion (ML multi-stage correlation), Microsoft Security (Defender alert bridge), Anomaly (ML baseline). UEBA: baselines entity behaviour, surfaces anomaly scores in BehaviorAnalytics table and entity pages, enriched by IdentityInfo. Hunting = proactive KQL queries + bookmarks promoted to incidents. ## ④ 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. Figure 5 — SOAR playbook trigger An automation rule fires on incident creation, running a Logic App playbook to enrich and contain. SOAR playbook trigger Incident created analytics rule alert Automation rule condition matches Logic App runs Sentinel trigger Actions execute block IP, alert team Incident updated playbook comment added An automation rule fires on incident creation, running a Logic App playbook to enrich and contain. 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. Likely cause 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. Diagnosis 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 table Fix Arjun 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. Verify 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. Quick check · Q4 of 10 · Analyze An analyst closes a Microsoft Sentinel incident as 'False Positive'. What is the primary operational benefit of this classification? a) It permanently deletes the incident data b) It disables the analytics rule that generated the alert c) It feeds back into Sentinel ML to improve future detection accuracy and signals the rule may need tuning d) It automatically blocks the source IP address Correct: c. Classifying an incident as False Positive feeds the classification back into Sentinel's ML to help improve future accuracy and signals to the SOC that the analytics rule generating that alert may need threshold or logic tuning. It does not delete data, disable the rule automatically, or block IPs — those are separate actions. 👉 So far: Playbooks = Azure Logic Apps triggered by Sentinel alert or incident events. Automation rules fire them automatically on conditions (severity, rule name). Incident triage: assign owner, set Active, investigate entity graph, check UEBA, run playbook, add comments, close as True/Benign/False Positive. Classification feeds back into ML for future accuracy. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is Microsoft Sentinel and how does it relate to Log Analytics? How is Microsoft Sentinel priced, and which data sources are free to ingest? What connector types does Sentinel offer, and how do you connect a non-Microsoft firewall? What are the KQL operators I must know for a Sentinel interview? What are the analytics rule types in Sentinel, and what is UEBA? How do Sentinel playbooks and automation rules work together for SOAR? 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. Q5 · Remember Which billing model is best for a Microsoft Sentinel deployment ingesting only 30 GB per day with unpredictable spikes? a) Commitment Tier at 100 GB/day b) A fixed annual enterprise agreement c) Free tier — under 50 GB is always free d) Pay-As-You-Go (per GB, no minimum) Correct: d. Pay-As-You-Go is best for low-volume or unpredictable ingestion (under ~100 GB/day). Commitment Tiers offer lower per-GB rates but you pay for the reserved capacity whether you use it or not — committing at 100 GB/day when average is 30 GB wastes money. There is no free tier based purely on volume below 50 GB. Q6 · Understand Why must the Azure Monitor Agent (AMA) Linux forwarder VM sit between the on-premises firewall and the Log Analytics workspace when using CEF/Syslog? a) Because the firewall cannot generate any log output b) Because Sentinel requires all logs to pass through Azure Defender first c) Because Log Analytics only accepts HTTPS and cannot receive syslog directly, so AMA normalises CEF-formatted syslog into the CommonSecurityLog schema and forwards it d) Because AMA decrypts TLS traffic before forwarding Correct: c. The Log Analytics workspace does not have a listening syslog port — it only accepts data from agents or APIs over HTTPS. The AMA Linux forwarder receives the raw CEF/syslog stream from the firewall, normalises it into the CommonSecurityLog schema, and ships it to the workspace. AMA also handles authentication and efficient batching. The firewall generates logs fine; Sentinel does not require Azure Defender as a relay. Q7 · Apply You write a KQL query that accidentally uses 'select' instead of 'project' and 'group by' instead of 'summarize'. What happens? a) The query runs successfully because KQL accepts both syntaxes b) The query fails with a parse error because KQL uses pipe-chained operators, not SQL clauses c) The query runs but returns only the first row d) Sentinel automatically converts SQL to KQL at runtime Correct: b. KQL (Kusto Query Language) uses pipe-chained operators and does not accept SQL clauses like SELECT or GROUP BY. Using SQL syntax causes a parse error. The correct KQL equivalents are 'project' for SELECT and 'summarize' for GROUP BY. Sentinel does not auto-convert SQL to KQL. Q8 · Analyze A Sentinel Scheduled analytics rule fires every 5 minutes, but the SOC needs to detect account lockouts within 60 seconds. What is the correct change? a) Decrease the scheduled rule's run frequency to 1 minute b) Switch to an NRT (Near Real-Time) rule for ~1-minute latency c) Enable Fusion ML correlation instead d) Add a UEBA anomaly rule to the workspace Correct: b. NRT (Near Real-Time) rules in Sentinel run continuously with approximately 1-minute latency — ideal for time-critical detections like account lockouts where a 5-minute scheduled cadence is too slow. Scheduled rules cannot be reduced below 5 minutes. Fusion and UEBA serve different purposes and do not provide sub-minute alert latency for specific KQL conditions. Q9 · Evaluate After closing several Sentinel incidents as False Positive, the SOC manager asks what additional action reduces future false positives from the same analytics rule. Best answer? a) Disable the analytics rule permanently b) Delete the Log Analytics workspace and recreate it c) Tune the KQL threshold or add exclusion conditions (e.g. exclude known-safe IPs or service accounts) in the analytics rule d) Increase the incident severity to High so analysts pay more attention Correct: c. Tuning the analytics rule — adjusting KQL thresholds, adding where conditions to exclude known-safe entities (service accounts, jump hosts, approved IP ranges) — directly reduces false positives while keeping the detection active. Disabling the rule removes the detection entirely; deleting the workspace destroys data; changing severity does not reduce alert volume. Q10 · Evaluate A Logic App playbook runs when triggered manually but does NOT run automatically on high-severity incidents. What is the most likely missing configuration? a) The Logic App needs to be redeployed after each Sentinel update b) No automation rule exists that matches high-severity incidents and triggers the playbook c) High-severity incidents cannot trigger Logic Apps in Sentinel d) The playbook is deployed in the wrong Azure subscription Correct: b. Automation rules are the policy layer in Sentinel that fire playbooks automatically — they match on conditions like incident creation with severity = High and then run the specified playbook. Without an automation rule pointing to this playbook, it only runs when an analyst manually triggers it from the incident context. High-severity incidents can absolutely trigger Logic Apps; region and redeployment are not the issue. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 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. Compare with expert answer Expert version: A Scheduled analytics rule runs a KQL query on a configurable cadence (every 5 minutes to every 14 days) over a lookback window — use for most custom detections where near-instant alerting is not required. An NRT (Near Real-Time) rule runs the same KQL continuously with approximately one-minute latency — use when the event window is too narrow for a 5-minute schedule, such as account lockouts or critical privilege escalation. Fusion is completely different: it is Microsoft's ML-based multi-stage attack correlation engine that correlates low-fidelity signals from multiple data sources (Defender products, Sentinel tables, anomaly signals) and surfaces them as high-confidence incidents representing multi-stage attacks like credential theft followed by lateral movement — you enable it and it runs automatically, requiring no custom KQL. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 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. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt