Module 3: Advanced | Day 4 only | Detection Engineering, Threat Hunting and SOAR

Curriculum version: 1 November 2026
Course: Five-day progressive Microsoft Sentinel technical training
This manual: Day 4 only — syllabus competencies A01–A14
Prerequisite: Demonstrated successful completion of Days 1–3
Primary SIEM experience: Microsoft Defender portal
Format: Day-wise, guided technical lab manual; no hourly schedule
Authorized use: Isolated, instructor-approved environment with invented identities and data
Source basis: The uploaded Module 3 — Advanced agenda, supplemented by Microsoft Learn verification (references at end)

---

READ FIRST — accuracy, scope, grading and safe execution

This is a workbook, not a proof that anything ran. The UI paths and product behaviors were checked against official Microsoft Learn guidance available on 1 November 2026; local KQL fixtures were checked for coherent data relationships and intended assertions. There is no authenticated test against your Azure tenant. Portal releases, Defender feature entitlements, region availability, enabled tables, workflow connectors, access roles and approval-provider licensing can change results. Every lab separates (a) reproducible offline/synthetic evidence, (b) live tenant evidence and (c) feature-dependent alternatives. A learner may not report a cloud integration as PASS without directly observing its required state and logs.

Never use actual compromised accounts, endpoint isolation, real firewall blocks, account disablement, unapproved tickets or privileged remediation as training actions. Use synthetic incident titles beginning D4-LAB-, fictitious users in aster.example, and TEST-NET example IPs (198.51.100.0/24, 203.0.113.0/24). These addresses are placeholders only; do not send traffic to them. Prefer manual playbook execution against a labeled incident before enabling an automatic rule. Do not expose Logic Apps connection credentials in screenshots.

Important 2026 distinctions:

1. The Defender portal is the primary UI; Microsoft says Sentinel’s Azure portal experience ends after 31 March 2027 [R01]. You will still administer Azure resources in the Azure portal.
2. ASIM is a query-time normalization model. A parser returning normalized fields does not imply all source vendors are covered or the events are trustworthy [R02–R03].
3. Sentinel NRT rules run once per minute and have rule-specific restrictions. Microsoft also recommends unified custom detections for eligible integrated Defender experiences; do not equate the two systems or promise equivalent licenses [R04–R05].
4. Hunting bookmarks can be viewed but not newly created in the Defender portal; advanced hunting does not support the old bookmark action. Preserve a hunt with saved query text and an evidence ledger instead [R06].
5. Playbook trigger options now include newer case-based experiences and legacy incident options. The actual trigger and automation-rule compatibility depend on the tenant. Match the trigger shown in your portal, rather than mixing an incident-triggered rule with a case-triggered workflow [R07–R09].
6. Logic Apps costs extra; granting Sentinel permission to run a playbook is separate from granting an engineer permission to edit it [R08].

Learning outcome and 5W1H contract

Lens	Day 4 operational answer
What?	ASIM, source/parser contracts, quality-engineered detections, NRT vs scheduled, hypothesis hunts, ATT&CK, Logic Apps/SOAR
Why?	Make heterogeneous signals comparable, reduce false attribution, test detection reliability and safely orchestrate repetitive investigation
Who?	Detection author, data steward, SOC analyst/hunter, workflow operator, incident commander, business/system approver
When?	Normalize when source schemas diverge; hunt when a falsifiable question exists; automate only after authorization and negative-path testing
Where?	Sentinel-enabled workspace, Defender advanced hunting/Sentinel configuration, Azure Logic Apps resource group and approved ticket sandbox
How?	Validate parsers → detect a time-ordered sequence → test good and bad cases → hunt and record uncertainty → deploy guarded workflow → review run history

Aster Retail — the continuing case

Aster Retail (entirely fictional) has a privileged identity admin@aster.example. A simulated sign-in, unusual firewall observation and a subsequent role grant suggest possible misuse. On Day 3 students already completed second-source ingestion, KQL joining, watchlist enrichment, a tuned rule, incident metadata and a workbook. On Day 4, the new work is normalized detections, test design, structured hunting, and approval-gated SOAR. Do not repeat Day 3’s onboarding or watchlist exercises.

YesNo / timeoutVendor-specific activityASIM parser contractMulti-stage detection KQLPositive / negative regression testsHypothesis-led hunt + ATT&CKLab incident / caseSentinel automation ruleLogic Apps playbookLab scope + approval?Non-disruptive update + auditStop; record rejection

Lab tracks and definition of PASS

Track	Available environment	What can be demonstrated	Allowed result
A — full lab	Sentinel workspace, permitted test incident/case, supported parser sources, Logic Apps and approval connector	Full ASIM → detection → hunt → playbook → run-history chain	Operational PASS if each evidence gate passes
B — shared instructor lab	Instructor operates restricted Azure resources, learners perform KQL, design and observe controlled runs	Same sequence with signed attribution of instructor-controlled steps	Competency PASS with operator attribution
C — synthetic-only	KQL editor or offline worksheets; no connector/licensing	Fixture queries, reasoning, workflow design and fault analysis	Conceptual PASS only; not live deployment

Day 4 completion gate: An ASIM source contract; query optimization justification; a multi-stage query and positive/negative test matrix; a falsifiable hunt and ATT&CK mapping; an approval-gated workflow; proof of approve/reject or equivalent safe negative-path tests; permission review; and one troubleshooting report. See final rubric. An offline mock-up is valuable but not a substitute for a real Logic Apps run.

Required instructor preflight (before Day 4)

• [ ] Confirm the specific Entra tenant, Azure subscription ID, Sentinel-enabled Log Analytics workspace, region, approved resource group and least-privileged instructor account.
• [ ] Preserve working Day 3 queries, a test analytics rule, a test incident, watchlist owner, source records and a saved query timestamp (UTC). Do not use real alerts containing personal data.
• [ ] Confirm usable source tables for ASIM (for example DNS, authentication or network session). A built-in parser may exist even if zero supported events exist.
• [ ] Confirm ability to use Sentinel > Configuration > Analytics and Sentinel > Configuration > Automation in the Defender portal; allow for navigation variations in integrated tenants.
• [ ] Confirm Azure Logic Apps Consumption or Standard support and the exact Sentinel workflow trigger offered. Standard workflows used as Sentinel playbooks must be stateful, not stateless [R07].
• [ ] Have a named human approver, approved method for recording decisions, and a sandbox-only target for notifications/tickets. If a connector requires an unavailable license, use the documented simulation branch and mark the external approval integration not exercised.
• [ ] Approve a cost budget, resource cleanup owner, allowable test count and run-history retention; review Logic Apps and connector pricing before provisioning.
• [ ] Confirm manual playbook run roles: Microsoft Sentinel Responder for incident access, Microsoft Sentinel Playbook Operator on playbook RG, and Microsoft Sentinel service-account Automation Contributor on that RG for automation-run permissions [R08]. Creating/editing Logic Apps additionally requires supported Logic Apps roles.
• [ ] Use personal access and managed identities with narrowly scoped permissions where the connector supports them. Never store credentials in a KQL query or playbook Compose output.
• [ ] Preselect an observation-only exercise in case portal features, source logs or SIEM/Defender permissions are unavailable.

Lab naming and evidence convention

Artifact	Recommended sandbox label
Saved query	D4-ASIM-HUNT-<initials>
Test rule	D4-LAB-identity-sequence-<initials>
Test incident	Title starts with D4-LAB-
Logic App playbook	pb-d4-lab-approval-<initials>
Automation rule	ar-d4-lab-scope-<initials>
Evidence folder	D4/<learner-id>/<lab-id>/
UTC evidence record	ISO-8601 timestamp, workspace ID, query text/version, expected vs observed, status, sanitized screenshot / run ID

Screenshot safety: Redact tenant IDs where not needed, incident content, UPNs, OAuth tokens, connector secrets, HTTP authorization headers and approval URLs. Record artifacts with stable identifiers and time instead of copying confidential logs into student reports.

---

DAY 4 — STEP-BY-STEP LABS

D4-L00 — Verify continuation, access and the test boundary

Mapped syllabus: prerequisite gate, A09/A11/A13.
Outcome: All prerequisite evidence and safe permissions are recorded before any deployment.

1. Open security.microsoft.com and confirm the expected tenant and selected SIEM workspace. Record workspace resource ID and region in your private evidence folder.
2. Open Microsoft Sentinel > Configuration > Analytics. Confirm that you can see the Day 3 test rule (or an instructor-approved substitute). Do not enable or edit it yet.
3. Open Investigation & response > Incidents & alerts > Incidents. Search for a nonproduction incident beginning D4-LAB-, or have the instructor create one using an approved test rule before any playbook lab.
4. Open Microsoft Sentinel > Configuration > Automation. Check access to automation rules and the Active playbooks list.
5. In Azure portal, inspect the dedicated Logic Apps resource group Access control (IAM). Confirm the role assignments from the preflight matrix; record who is permitted to edit, run, grant access and approve.
6. Record a written change boundary: all actions limited to lab scope; no device/user/network remediation. Identify an owner for disabling the automation rule after tests.
7. Record PASS / BLOCKED / SUBSTITUTE for: workspace, test incident/case, ASIM data, Logic Apps create/write, run permissions and approval provider.

PASS: Access worksheet completed, correct tenant/workspace verified, lab ticket/incident exists (or creation owner identified), approver named and cleanup owner assigned. BLOCK: Any production-scoped trigger or missing authorization.
Evidence: D4-L00-preflight.md, redacted role matrix, selected test rule and incident IDs.
Documentation: [R01], [R07–R09].

D4-L01 — ASIM architecture, parser discovery and normalized field contract

Mapped: A01. New skill: Abstract a real source behind an ASIM schema.

What/why: ASIM maps heterogeneous source fields to a normalized model at query time. A source-specific parser implements a contract; the unifying parser combines supported sources. Do not assume a custom log is automatically covered.

1. Go to Investigation & response > Hunting > Advanced hunting in Defender, and select the Sentinel workspace/query context supported by the tenant. If the unified query surface rejects a Sentinel parser, use the workspace’s supported Log Analytics query surface and record the editor used.
2. Check these candidate built-in unifying parser names against current Microsoft documentation: _Im_Authentication, _Im_Dns, _Im_NetworkSession. A parser is callable only if the selected query context exposes it.
3. Pick one source known to have records. Run the first candidate query below. Start with a short time window to control cost. No results is not the same thing as a missing parser.

// D4-L01A: bounded ASIM DNS example, requires supported DNS sources.
_Im_Dns(starttime=ago(1d))
| project TimeGenerated, SrcIpAddr, DnsQuery, ResponseCodeName
| take 20

4. If the query reports an unrecognized column, omit the unsupported projection, run _Im_Dns(starttime=ago(1d)) | take 1, inspect the actual returned schema, and correct the mapping. Do not silently fabricate DnsQuery or any source-specific field.
5. Inspect at least five events and write a field contract table: vendor/table, original key, ASIM normalized key, data type, sample value, source-specific limitations and field null percentage.
6. Demonstrate a unifying parser versus a source-specific parser conceptually. List one source-specific parser from the current Microsoft list, verify that its source is installed, and only then attempt execution.
7. Record how the parser determines an entity such as SrcIpAddr: it might represent a resolver, proxy, NAT egress or actual endpoint. Write one caution against using it as proof of device ownership.

Expected observation: The parser exists where supported; rows are returned only when qualifying source data exists. A legitimate empty result is acceptable for parser availability but not a source-data validation PASS.
PASS: Correct parser identified and source coverage plus semantic caveat documented. For full live PASS, show one real normalized event and its original source record.
Troubleshooting: Unknown function → wrong editor/workspace or feature context; zero rows → source absent, time filter or parser unsupported source; null fields → incomplete mapping, not an ASIM service failure.
Evidence: D4-L01-parser-contract.csv, parser query, sanitized source-to-normalized row.
Read: [R02], [R03].

D4-L02 — Optimize normalized queries with parser-time filters

Mapped: A02. Outcome: Use early filtering responsibly and measure, rather than guessing, performance.

1. Query a broad unifying parser over a bounded interval, recording execution duration, returned rows, scanned data if exposed and query surface.
2. Run the optimized query with the parser’s documented filter parameters. For DNS, the official pattern uses starttime and responsecodename:

// D4-L02A: optimized parser-side filtering
_Im_Dns(starttime=ago(1d), responsecodename='NXDOMAIN')
| summarize EventCount=count() by SrcIpAddr, bin(TimeGenerated, 15m)
| order by EventCount desc

3. Compare to a semantically equivalent after-parser filter:

// D4-L02B: control query with post-parser filtering
_Im_Dns
| where TimeGenerated >= ago(1d)
| where ResponseCodeName =~ 'NXDOMAIN'
| summarize EventCount=count() by SrcIpAddr, bin(TimeGenerated, 15m)
| order by EventCount desc

4. Run both more than once only within the approved query budget, on identical windows and workspace scope. Compare returned result sets (which should be logically comparable) and observed runtime. A one-off timing difference is not reliable benchmarking.
5. Inspect known edge cases: SrcIpAddr blank; DNS caching; event duplication; different vendor definitions of NXDOMAIN; time zone/clock skew.
6. Write a query optimization record: filter parameters used, query text, source count, observed difference, any field mismatch and whether the optimization is actually justified.

PASS: Learner explains filter-before-parse, reports measured evidence or records why performance comparison is unavailable, and does not claim faster execution without measurement.
Troubleshooting: Different counts → not equivalent filters, missing schema normalization or data changed between runs. Compare an explicit fixed UTC window for precise repeatability.
Evidence: D4-L02-query-comparison.md. Read: [R02–R03].

D4-L03 — Engineer a multi-stage attack sequence using reproducible data

Mapped: A03. Outcome: Encode ordering, a common entity key and a bounded window. This lab is synthetic first, to prevent false real-incident claims.

Hypothesis: A privileged account signs in and, within ten minutes, receives a high-privilege role grant, with an infrastructure signal in between. A matching query is a lead, not proof of compromise.

1. Open a scratch query tab in the KQL-compatible editor. Paste the entire block (the fixture is self-contained and contacts no IPs).
2. Observe that only admin@aster.example forms the designed contiguous sequence; ops@aster.example represents routine activity that should not match the ten-minute sequence.

// D4-L03: time-ordered three-stage fixture.
let Login = datatable(Account:string, SourceIp:string, LoginAgoMin:long)
[
  'admin@aster.example','198.51.100.25',12,
  'ops@aster.example','203.0.113.22',90
]
| extend LoginTime=now() - LoginAgoMin * 1m;
let Network = datatable(Account:string, SourceIp:string, NetworkAgoMin:long, Action:string)
[
  'admin@aster.example','198.51.100.25',9,'Deny',
  'ops@aster.example','203.0.113.22',20,'Deny'
]
| extend NetworkTime=now() - NetworkAgoMin * 1m;
let Grants = datatable(Account:string, GrantAgoMin:long, GrantedRole:string)
[
  'admin@aster.example',5,'Owner',
  'ops@aster.example',1,'Reader'
]
| extend GrantTime=now() - GrantAgoMin * 1m;
Login
| join kind=inner (Network) on Account, SourceIp
| join kind=inner (Grants) on Account
| where LoginTime <= NetworkTime and NetworkTime <= GrantTime
| where GrantTime - LoginTime <= 10m
| where GrantedRole =~ 'Owner'
| project Account, SourceIp, LoginTime, NetworkTime, GrantTime, GrantedRole, Action

3. Expected synthetic result: Exactly one row: admin@aster.example, the TEST-NET source IP, an Owner grant following login and network activity. The relative times are computed from the same query evaluation clock; if an editor does not support dynamic timespan arithmetic, run the fixture in the workspace Log Analytics KQL engine and record the compatibility issue.
4. Change the sequence to test negative cases: (a) increase GrantAgoMin to 20, (b) change GrantedRole to Reader, (c) mismatch SourceIp, and (d) reverse the event ordering. Run each as a separate fixture test and record whether it is correctly excluded.
5. Examine join multiplicity: multiple network records per login may create duplicate matches. Demonstrate an aggregation (for example summarize arg_min(NetworkTime, *) by Account, SourceIp) before joining when business logic requires one representative event.
6. Transfer the concept to the Day 3 real identity/network/source query only after verifying that the actual fields, identities and timestamps have equivalent semantics. Do not translate sample field names to a production table by guessing.
7. Save the query and write a schema/identity contract. Address shared IPs, NAT, session identifiers, clock skew, attacker-controlled input, legitimate emergency access and cross-tenant identity resolution.

PASS (synthetic): One expected detection plus four negative test results with a written false-attribution limitation. Operational PASS: an equivalent real-source query shows verified source IDs and correlates with documented semantics.
Evidence: versioned KQL, output table, D4-L03-test-matrix.csv.
Troubleshooting: Many-to-many explosions → deduplicate/aggregate before join; missing events → timestamp window, case-normalized account key, source ingestion delay.
Read: [R02], [R10].

D4-L04 — Decide between scheduled, NRT and unified custom detections

Mapped: A04. Outcome: Make an explicit design choice with current functionality and guardrails.

1. In Microsoft Sentinel > Configuration > Analytics, inspect existing rule types. Filter active rules by NRT using the documented Rule type filter.
2. Open the Create menu only in a lab workspace. Note whether NRT query rule and Scheduled query rule are offered. Do not enable a new detection yet.
3. Open the Defender Advanced hunting experience; inspect whether Create detection rule / unified custom detection is available. If absent, record license/permission/experience unavailable instead of assuming an error.
4. Fill this comparison matrix with the actual tenant evidence:

Decision question	Scheduled Sentinel	Sentinel NRT	Unified custom detection
Main reason to choose	Flexible scheduled correlations and thresholds	Frequent, narrow event-based Sentinel alerting	Eligible unified Defender/SIEM detection experience
Evaluation frequency	Configurable within service constraints	Runs about once per minute with a one-minute lookback	Depends on supported Defender detection configuration
Source assumptions	Sentinel query/table accessibility	NRT-supported Sentinel queries and constraints	Eligible advanced-hunting source and product/license permissions
Alert threshold	Configurable	NRT alert-generation behavior differs from scheduled	Rule-specific behavior; do not infer Sentinel settings
Control risk	Alert volume and late ingestion	Noisy minute-by-minute rules, strict result handling	Different schema/response options and entitlements

5. Inspect the official NRT limitations: frequency/lookback are fixed; result grouping and output sizes require deliberate project; do not simply paste an expensive multistage hunt into NRT.
6. Based on the D4-L03 sequence, recommend a scheduled rule for the learning exercise unless the source cadence, data availability and current tenant explicitly support a faster mode. Store a short decision record with rationale and rollback.
7. Optional supervised lab: create a disabled or tightly time-limited test rule from a previously validated live-source query and inspect its output schema. Do not publish the datatable() fixture as proof of live security detection. If generating a real incident, use the bounded Day 3 test source, route only to the lab queue, and disable after verifying it.

PASS: Accurate comparison and design rationale; any live rule has a bounded source, owner and safe disablement plan.
Evidence: D4-L04-execution-mode-ADR.md, optional test rule ID. Read: [R04], [R05].

D4-L05 — Build a detection regression-test matrix

Mapped: A05. Outcome: Evaluate detections against known examples, not anecdotes or alert-count vanity metrics.

1. Write down your detection’s intended behavior in plain English. Example: Flag a privileged identity whose successful sign-in precedes a network anomaly and Owner assignment within ten minutes; do not trigger on nonprivileged grants or mismatched identities.
2. Define test inputs independently of the detection query. The following table is a test specification, not a measurement of production accuracy:

Test ID	Sign-in	Infrastructure event	Role grant	Expected	Why
T01	Privileged, matching identity	In window, same IP	Owner within 10 min	Detect	Full chain
T02	Privileged, matching identity	In window	Reader within 10 min	Do not detect	No high-impact grant
T03	Privileged	Same IP, wrong user	Owner	Do not detect	Identity mismatch
T04	Privileged	In window	Owner after 45 min	Do not detect	Window exceeded
T05	Benign automation account	In window	Owner, approved window	Review/suppress if policy allows	Authorized change
T06	Privileged	No network record	Owner	Do not detect with three-stage logic	Missing prerequisite
T07	Privileged	Duplicate network messages	Owner	One meaningful case	Deduplication
T08	Shared NAT / proxy IP	In window	Owner	Investigate, not automatically attribute	Ambiguous identity

3. Use the D4-L03 fixture, changing one test variable at a time, and record observed results for T01–T04. Use additional instructor-seeded rows for T05–T08; explain any case your current query cannot decide.
4. Create a confusion matrix only for cases with known ground truth. TP = malicious case detected; FP = benign case detected; FN = malicious case missed; TN = benign case not detected. For an illustrative six-case fixture with TP=2, FP=1, FN=1, TN=2, calculate:

Precision proxy = TP / (TP + FP) = 2 / 3 ≈ 66.7%
Recall proxy    = TP / (TP + FN) = 2 / 3 ≈ 66.7%
False positive rate = FP / (FP + TN) = 1 / 3 ≈ 33.3%

5. Explicitly label these as toy-fixture metrics. Historical SOC alert dispositions are not full ground-truth negatives; they cannot measure actual missed attacks without independent validation.
6. Design a release gate: approved test fixture; query review; baseline alert volume; entity mapping review; false-positive exceptions; owner; rollback; detection health monitoring; expiration of temporary exclusions.
7. If using an actual lab analytics rule, confirm event-source timestamps, scheduling/evaluation window and alert/incident generation before claiming a live result. A query that returns a row in advanced hunting is not proof the rule executed or created an alert.

PASS: At least eight tests specified; four executed in synthetic KQL; numerical example correct; at least two known blind spots; rollback criterion.
Evidence: D4-L05-regression-matrix.csv, D4-L05-release-gate.md.
Failure trap: Adjusting detection thresholds just to make all demonstration tests pass without preserving a benign holdout set.

D4-L06 — Execute a falsifiable, hypothesis-led threat hunt

Mapped: A06. Outcome: Produce a structured analyst report with uncertainty and reproducibility.

Hunt question: Did a privileged cloud identity show a suspicious authentication-to-role-change sequence not explained by an approved change? This is a hypothesis, not a declaration of compromise.

1. In a new report, record the hypothesis before searching. List expected supporting evidence: successful authentication timestamp, account’s stable ID, network/session IP and context, role-assignment actor/target, UTC time, scope, approval record and source event IDs.
2. List disconfirming evidence: an authorized change request, expected break-glass access, approved deployment identity, known test data, sanctioned device/network, duplicate telemetry or a different human behind a shared IP.
3. Open Microsoft Sentinel > Threat management > Hunting to view relevant hunting content, and Investigation & response > Hunting > Advanced hunting for the unified query experience. Use the appropriate query surface based on source table support.
4. Run the following synthetic hunt timeline before connecting any source-specific data; no external logs are required:

// D4-L06A: timeline fixture. Results are fabricated, not an observed attack.
let Evidence = datatable(AgoMin:long, EventKind:string, Account:string, Note:string, EventId:string)
[
  19, 'Login', 'admin@aster.example', 'Successful sign-in from unusual network', 'TEST-LOGIN-01',
  16, 'Network', 'admin@aster.example', 'Egress deny from same example address', 'TEST-FW-02',
  12, 'RoleGrant', 'admin@aster.example', 'Owner assigned in training subscription', 'TEST-IAM-03',
   3, 'Review', 'admin@aster.example', 'Approval ticket not yet found', 'TEST-CASE-04',
  45, 'RoleGrant', 'ops@aster.example', 'Approved nightly service job', 'TEST-IAM-05'
];
Evidence
| extend EventTime=now() - AgoMin * 1m
| order by EventTime asc
| project EventTime, Account, EventKind, EventId, Note

5. Record the query time, time range, source/fixture classification, event identifiers and any missing data. Avoid saving screenshots that omit the UTC interval or source table.
6. For a real-data variation, use the already validated Day 3 sources and schema. Confirm the sign-in account ID is the actor versus the target in role-change logs, and link to the relevant authorization ticket. If that mapping cannot be shown, state identity attribution unresolved.
7. In Defender portal, save the query or its text in the evidence repository; use the Hunt report template below. Do not instruct students to add new bookmarks in Defender (the legacy action is Azure-portal-only) [R06].
8. Make a decision: escalate only for evidence-supported activity under SOC policy; otherwise continue investigation, record known benign, or insufficient evidence. Include a recommended detection enhancement.

Hunt report template (copy into learner evidence)

# D4 Hunt Report — <learner-id>
Hypothesis:
ATT&CK hypothesis:
UTC window / workspace / editor:
Sources available and missing:
Query text / query version:
Potential matching event IDs:
Evidence supporting:
Evidence contradicting:
Identity attribution confidence (low/medium/high + reason):
Known benign explanations checked:
Decision and incident/case owner:
Recommended detection improvements:
Data handling / retention classification:

PASS: A falsifiable hypothesis; one reproduced timeline; two independent evidence classes or an explicit documented gap; at least three benign alternatives examined; a justified disposition.
Evidence: D4-L06-hunt-report.md, anonymized query outputs. Read: [R06], [R11].

D4-L07 — Map evidence to MITRE ATT&CK without exaggerating coverage

Mapped: A07. Outcome: Explain ATT&CK as a behavioral knowledge model, not an alert-accuracy guarantee.

1. From the hunt hypothesis, identify two plausible technique hypotheses: T1078.004 — Valid Accounts: Cloud Accounts and T1098.003 — Account Manipulation: Additional Cloud Roles. Verify their current meanings from MITRE’s pages [R12].
2. Open Microsoft Sentinel > Threat management > MITRE ATT&CK (if exposed in the tenant). Review mapped analytics rules and coverage presentation. A mapped rule is not automatically a validated effective detector.
3. Create this coverage matrix:

Technique	Required observable behavior	Sensor/table actually available	Detection/hunt logic	Known gap	Tested?
T1078.004	Use of suspicious but valid cloud identity	Sign-in source verified?	Time-bounded unusual sign-in	Legitimate remote access	Yes/No
T1098.003	Unexpected additional cloud role	Role assignment audit source?	Actor/target and scope match	Missing change-ticket context	Yes/No

4. For both techniques, list data requirements, detection logic, expected entity and alert, benign scenarios and an unobserved evasion/path that the course’s sources could miss.
5. Run an instructor scenario where the role grant has a different actor than the signed-in account. Explain why a naive join by display name or IP would mislead an analyst.
6. Submit a four-part statement: technique hypothesis, evidence, limits, operational recommendation. Do not state “we cover T1078.004” based solely on a mapping tag.

PASS: Two accurate ATT&CK mappings, explicit observed sensors, one detection blind spot per technique and evidence-based confidence statement.
Evidence: D4-L07-attack-mapping.md. Read: [R12], [R01].

D4-L08 — Perform an advanced entity/UEBA pivot with alternative explanations

Mapped: A08. Outcome: Interpret context without confusing anomaly scores with proof.

1. Select the invented identity from the lab incident or from the preserved Day 3 UEBA exercise. In Defender, navigate to its entity page (for example Assets > Identities where available) or open entity details from the incident.
2. Record the account/object ID, time window, known device/network associations and any relevant UEBA/anomaly context. If no UEBA signal exists, mark not available; do not enable broad production analytics just to make a screenshot.
3. If the workspace contains BehaviorAnalytics, inspect source rows only after verifying the table is present. Use a schema-neutral preview:

// D4-L08: workspace-dependent table. Run only if present.
BehaviorAnalytics
| where TimeGenerated >= ago(7d)
| take 10

4. Record whether the anomaly was based on a supported source and whether a distinct raw event corroborates it. Identify what context was not available (VPN IP, geographic jumps, device history, normalized authentication result).
5. Compare at least three alternative explanations: role activation under PIM, emergency access, a test account in a sandbox, automation acting for a human, device proxy/NAT or timestamp skew.
6. Draft a defensible entity narrative: what happened, which signal said so, what is only inferred, what would disconfirm it, and who must approve response.

PASS: One entity pivot with two source references or a recorded missing-data blocker; no unsupported “suspicious = compromised” conclusion.
Evidence: D4-L08-entity-analysis.md. Read: [R01], [R06].

D4-L09 — Design the SOAR playbook before using Logic Apps

Mapped: A09, A10, A13. Outcome: A safe workflow contract with a scope check, human decision and no destructive defaults.

1. Draw the proposed chain. The condition lab incident/case title begins with D4-LAB- must execute before notification, ticketing or other external calls. If the trigger doesn’t reliably include the title, use a supported read-only lookup to resolve the full record before proceeding.
2. Decide which trigger the current tenant actually supports:
   • Incident trigger (Legacy) and incident-compatible automation rule, if shown;
   • Case trigger with a case-compatible workflow/automation option, when available in integrated Defender experience;
   • Manual execution against a permitted lab incident, if automatic case routing is not supported for the learner’s setup. Never combine mismatched incident/case triggers and report success.
3. Agree on the external approval authority and approval-provider connector. Record whether an integrated Start and wait for an approval action is accessible under that organization’s subscription. If not, use the manual approval evidence track and mark the provider integration untested.
4. Decide what the approved action will do: write an internal training comment, a safe tag or create a ticket in a sandbox project. No real containment or privilege change.
5. Define failure handling and retry semantics. Example: after a remote ticket creation succeeds but an acknowledgment is lost, querying by an idempotency key must happen before any retry; otherwise duplicate tickets appear.
6. Fill out the following workflow contract:

Contract item	Lab decision
Trigger	Named incident/case-compatible Sentinel event
Allowed scope	Only D4-LAB- plus expected workspace and test ownership
Context to log	Sanitized incident/case identifier, UTC timestamp, workflow run ID
Data minimization	No raw credentials, PII or full event payload in Compose/log output
Deduplication key	`
Read-only enrichment	Known dummy asset owner, test watchlist or preapproved lookup
Approval	Named human, accept/reject outcomes, timeout behavior
Allowed final action	Lab comment/tag or sandbox ticket; no disruptive action
Rejection/timeout	No action; record verdict; do not auto-retry approvals blindly
Owner and rollback	Engineer and instructor; disable rule + workflow

7. Have instructor approve the workflow diagram before creating a Logic Apps resource. Store the approval date and permitted resource group.

PASS: Diagram, scope condition, owner, permission boundary, rejection path and cleanup plan all approved.
Evidence: D4-L09-soar-contract.md, workflow diagram, review signoff. Read: [R07–R09], [R13].

D4-L10 — Create a guarded Logic Apps playbook and prove the human approval branch

Mapped: A10, A13. Outcome: Build and exercise a non-destructive Sentinel-triggered Logic Apps workflow.

Part A — Provision a lab-only playbook

1. In Defender, choose Microsoft Sentinel > Configuration > Automation > Create > Logic App playbook (the displayed options depend on integration and current UI). Choose the trigger type documented in the D4-L09 contract. If the portal shows Playbook with case trigger versus Playbook with incident trigger (Legacy), choose the one compatible with your actual test incident/case and automation trigger [R07].
2. Choose Consumption for a small sandbox if approved; if the organization requires Standard, create a stateful workflow (Sentinel playbooks do not support stateless Standard workflows). Select the correct subscription, isolated resource group, region and naming convention. Review costs before selecting Create.
3. Open the created Logic App resource in Azure. Go to Designer. Verify the intended Microsoft Sentinel trigger is present, connected and properly authenticated. Record its display name and authentication method in evidence—do not assume a trigger appeared simply because the Logic App resource exists.
4. Add a Control > Condition immediately after the trigger. Build the first operand from the exact incident/case title dynamic content provided by the trigger; evaluate whether it starts with D4-LAB- (where the designer supports a starts-with operator or equivalent expression). Additionally verify workspace/tenant context where available.
5. Put a Control > Terminate (or a harmless Compose and a terminated branch) on the False path. On the True path continue with the steps below. Note: a Succeeded run that exits the wrong-scope branch is not approval to take action.
6. Add Data Operations > Compose for a minimal lab envelope: a fictitious incident ID, title, UTC timestamp and a fixed workflow version v1. Do not output an entire incident object containing identifiers or private log fields.
7. Save. Use the designer’s code view / workflow validation where offered. Confirm any required connector authorization succeeds and inspect the current workflow’s trigger/action graph.

Part B — Implement an approval gate, with no unsafe action

Preferred live track (approval connector available):

8. In the True branch, add the organization’s approved approval-provider action that waits for a decision (for example a supported Approvals action in the approved connector). Configure its authorized connection and named training approver, and present only the sanitized incident/case name and requested test action.
9. Set a bounded timeout according to the provider and Logic Apps policy, and branch on an explicit Approved / Rejected / Timed out / Failed result. If the provider uses different outcome strings, compare to the actual run output rather than copying a guessed constant.
10. In Approved, add only an allowed Compose such as TRAINING: approved; no account or network action performed. Optionally add a sandbox ticket creation / approved lab case annotation if the connector and permissions are configured.
11. In Rejected and Timed out/Failed, add a distinct Compose outcome and Terminate without any external remediation. Make sure no notification or ticketing action that requires approval is placed before the approval branch.
12. Save and inspect the full diagram. Explain why this design gives the approver a veto; the false and timeout branches must have no remediation.

Restricted fallback (approval connector unavailable):

• Do not fake an external approval integration. Instead create a Condition that permits the final training-only Compose only when a fixed instructor-controlled approved test variable is true; default it to false. Have the approver record a decision outside the workflow. Then run separate explicit dry-runs with instructor authorization. Mark the artifact approval logic simulated; external approval transport NOT TESTED. This is a teaching substitute and is not equivalent to a production human approval gate.

Part C — Run positive and negative tests

13. Start with a manual run against the specific D4-LAB- incident/case where the chosen trigger permits it. In Defender Incidents, select the lab record and use Run playbook (or the tenant’s corresponding case experience) [R08]. If unavailable, review permissions and trigger compatibility; do not broaden the automation rule to make it run.
14. In the Logic App > Run history, open the run. Verify the true-scope condition, the sanitized Compose output, the approval result and the final safe action. Record run ID, trigger type, status and UTC timestamp. Do not screenshot the full dynamic payload or connector token.
15. Test Reject. The run must not reach the approved-action branch. Test Timeout with the instructor’s short supervised timeout policy, where feasible; otherwise demonstrate it using controlled workflow tests and mark as simulation.
16. Test the wrong-scope case with a synthetic incident/case that does not begin D4-LAB-. Confirm that it exits before any side effect. If production incidents might match a broad condition, disable the workflow and fix the filter before continuing.
17. Submit a run-evidence table:

Run	Trigger record	Expected path	Observed path	Side effects	PASS?
R1	Approved D4-LAB-...	Approve → lab-only Compose/ticket
R2	Rejected D4-LAB-...	Reject → no action
R3	Wrong-scope record	Exit immediately
R4	Timed out/failed approval	Stop → no action

PASS: Live Logic Apps runs prove the right-scope and wrong-scope paths plus rejection; named approval confirmation for the live connector track. Where the real provider cannot be used, the outcome must be labeled simulated.
Evidence: D4-L10-playbook-run-matrix.md, sanitized run IDs, workflow export/diagram, approver decision.
Troubleshooting: Playbook missing from menu → trigger mismatch or Sentinel service-account RG permissions; run failed → open failed action; 401/403 → connector or role; waiting indefinitely → review approval provider and timeout policy.
Read: [R07–R09], [R13].

D4-L11 — Secure workflow identity, role separation and secret handling

Mapped: A11. Outcome: Validate who performs each action, using least privilege rather than giving everyone Owner.

1. In Azure Logic App > Identity, determine whether the workflow has an enabled system-assigned managed identity. Not every connector or trigger supports all authentication modes. Record which actions use managed identity versus a managed connector connection. Do not enable or widen a permission merely to satisfy the screenshot.
2. In the Logic App resource group’s Access control (IAM), record Logic App Contributor (or appropriate Standard role) for the builder, and Microsoft Sentinel Playbook Operator for the learner running a permitted playbook.
3. Review the extra Microsoft Sentinel Automation Contributor permission for the Sentinel service account on the playbook resource group. In Defender, where the playbook shows Missing permissions or Grant permission, follow the Manage playbook permissions flow with an Owner/User Access Administrator and only this lab RG [R08].
4. Map all identities involved:

Identity	Needs	Should not have by default
Learner builder	Edit lab Logic App and view safe run history	Tenant-wide Owner, production remediation
Sentinel service account	Invoke only approved playbooks in approved RG	Write access to unrelated RGs
Connector identity	Call narrowly scoped sandbox destination	Global administrator privileges
Human approver	Review request and approve/reject only	Automatic execution privileges
SOC analyst	Investigate and initiate approved manual runs	Edit all workflows or grant RBAC

5. Inspect each action’s connection and API permissions. Verify that a connection created with user-delegated OAuth won’t silently keep an inappropriate broad personal identity. Prefer managed identity where supported and approved.
6. If the workflow has sample secrets in a Compose or a connector parameter, remove them, use managed connections/Key Vault according to organization policy, enable secure inputs/outputs for sensitive actions as appropriate, and rotate any exposed test secret. Never commit connection secrets or authorization URLs to the course repository.
7. Document separation of duties: the person who writes a response action should not unilaterally authorize disruptive response in production. The lab’s approved action remains non-disruptive.

PASS: RACI/IAM table complete; no credential visible in run logs; Sentinel service permission restricted to lab RG; risk acknowledged for delegated connector connections.
Evidence: D4-L11-rbac-security-review.md, sanitized role assignments. Read: [R08], [R13].

D4-L12 — Engineer reliable orchestration: deduplication, retries and safe failures

Mapped: A12. Outcome: Demonstrate the difference between retrying a request and safely retrying a business action.

1. Define a stable idempotency key from the incident/case’s immutable ID plus workflow version, e.g. incident-arm-id|approval-v1. Do not use only a title: names can change and collide.
2. Identify a durable store appropriate for the test environment (sandbox ticket search, a dedicated storage table, or approved state system). Without durable state, a Logic Apps Compose action is not idempotency control.
3. Before a ticket-creation action, require a read-only lookup by the key. If a match exists, use its existing ID; otherwise create a new item with the correlation key. Record the result. Use a store with atomic uniqueness or controlled concurrency if duplicate creation is unacceptable.
4. In the designer, review Settings > Retry policy for a connector action where configurable. Explain when retrying 429 or transient 5xx is reasonable and why retrying a non-idempotent create after a timeout can duplicate effects.
5. Configure run-after paths or Scope blocks for success, failed, skipped and timed out statuses where supported. Make sure the failure branch does not report success to the SOC if a required step failed.
6. Run the same test incident twice (instructor-approved). Confirm either the original ticket is reused or the action is skipped. If no external state store is available, mark dedup design reviewed; not operationally proven.
7. Deliberately cause one harmless failure (for example a read-only lookup to a sandbox test record that does not exist). Verify the failure branch is invoked and no approved action executes after the failure.
8. Record workflow concurrency, action timeout, retry count, rate limit, compensating action and manual escalation owner in a failure-mode worksheet.
9. Define rollback precisely: disable the automation rule, disable the playbook, revoke an accidentally broad role, and correct created sandbox tickets using the service desk’s normal process. Do not attempt rollback of hypothetical identity containment in this course.

Failure	Risk	Required behavior
Duplicate incident update	Duplicate ticket/approval	Deduplicate by immutable key
HTTP 429 / API quota	Temporary loss of enrichment	Bounded backoff, log and escalation
Ticket created but response lost	Duplicate on retry	Look up existing ticket before create
Approval timeout	Unapproved action	Stop, notify human owner
Connector 401/403	Unauthorized access	Stop and request scoped repair
Workflow partially succeeded	Misleading SOC status	Explicit partial-failure outcome

PASS: One duplicate and one fault scenario documented; live PASS requires real durable-state evidence and explicit failure branch; design-only work earns conceptual credit.
Evidence: D4-L12-idempotency-and-faults.md, workflow run IDs. Read: [R07–R09], [R13].

D4-L13 — Connect the playbook to a narrowly scoped Sentinel automation rule

Mapped: A09, A13. Outcome: Trigger only on the approved lab context and verify permission boundaries.

1. With the workflow disabled or unconnected, agree on a single incident/case-producing test method and a unique D4-LAB- title or rule name. Record the exact Sentinel workspace and intended trigger.
2. In Defender go to Microsoft Sentinel > Configuration > Automation, then Create > Automation rule, as offered in your experience [R08].
3. Enter name ar-d4-lab-scope-<initials> and select a supported trigger matching the playbook: incident created, incident updated, alert created, or available case event. Do not assume every incident metadata field is allowed for every trigger.
4. Add the narrowest available conditions using the authorized lab analytics rule name, lab incident scope, source and severity as appropriate. If the trigger cannot restrict to your lab content adequately, stop and use manual execution. A blanket All incidents training rule is unacceptable.
5. Select action Run playbook and the exact workflow. If it is unavailable or greyed out, verify trigger compatibility and the Sentinel Automation Contributor permission for the service account on the workflow RG.
6. Review rule order and an expiration date. Prefer a short-lived lab rule; record the disabling/cleanup owner.
7. Create or update one approved lab test incident. Check rule execution, Logic Apps run history and case/incident audit history. Do not treat an enabled automation rule icon as evidence that a workflow ran.
8. Manually disable the rule after the test and confirm the disabled status in the portal. Leave the playbook itself in a safe state pending the troubleshooting exercise.

PASS: Trigger scoped to lab; one permitted actual run observed; service-account permission documented; rule disabled and cleanup recorded.
Evidence: automation rule ID/config snapshot, one run ID and post-test disabled state. Read: [R08–R09].

D4-L14 — Debug advanced response and prove the operating boundary

Mapped: A14. Outcome: Diagnose the first failed component from the right log surface.

1. Pick one instructor-seeded failed run or use a harmless missing-lookup test. Capture the exact UTC run and action IDs.
2. Inspect the Sentinel automation rule outcome first: did the rule trigger, did its conditions match, and was invoking the playbook permitted?
3. Then inspect Azure Logic Apps > Workflow > Run history. Identify the first Failed or Timed out action; open only sanitized inputs/outputs. An automation-rule status that says launched does not prove successful completion of the workflow’s internal actions.
4. Inspect connector authorization if error is 401/403; inspect quotas/backoff if 429; inspect schema/empty dynamic content if null; inspect trigger mismatches if the playbook is not selectable.
5. Record whether a workflow repeated due to incident updated firing after a workflow itself updated the incident. Add explicit scoping/idempotency protection; do not rely only on increasing delays.
6. Review who has permission to view execution logs. If sensitive content may have been exposed, stop, restrict logs and follow the organization’s secret-handling policy.
7. Fill the fault worksheet:

Symptom	First evidence	Cause to check	Safe repair	Confirm repair
No playbook option	Automation list	Missing RG grant or wrong trigger	Narrow grant / correct trigger	Playbook listed
No run after rule fires	Sentinel rule history	Condition/role/disabled	Fix bounded test	One run appears
Run ends 403	Failed connector action	Connection RBAC/consent	Fix minimal access	Test-only action succeeds
Multiple tickets	Ticket audit	Missing key / retry replay	Query by immutable ID	No duplicates
Approval never returns	Approval provider status	Timeout/identity	Stop and notify	Failure safely recorded
Rule causes new incidents recursively	Incident/audit timeline	Update-trigger feedback	Disable rule immediately	No new runs

PASS: Root cause supported by a cited error/run and the corrective control; observed resolution where permission allows, otherwise clearly marked blocked.
Evidence: D4-L14-root-cause.md, sanitized run details. Read: [R08], [R13].

---

DAY 4 CAPSTONE — integrated skills verification

Scenario and instructions

You are the lead detection engineer at fictional Aster Retail. A suspicious privileged sign-in, a network anomaly and a high-risk access change appear across differently formatted sources. Your job is to investigate without overclaiming evidence, propose a reliable rule and prepare a safe approval-gated lab response. You must work from the validated Day 3 environment (or an explicitly labeled synthetic substitute).

Submission pack:

1. 01_asim_contract.md — source table, parser, normalized fields, ambiguity and observed event IDs.
2. 02_query.kql — multi-stage correlation with timestamp/identity boundaries and query version.
3. 03_regression_tests.csv — test IDs, expected outcomes, observed outcomes and false-positive analysis.
4. 04_hunt_report.md — hypothesis, T1078.004/T1098.003 mapping, evidence, alternate explanations and disposition.
5. 05_playbook_workflow.md — trigger type, safe scope, approvals, auth model, idempotency and rejection branch.
6. 06_run_history.md — run IDs, approval/reject/timeout evidence and negative-scope result, or explicit simulated-track notation.
7. 07_rollback_and_cost.md — owner, estimated Logic Apps cost drivers, disable path and resource cleanup.

Instructor scoring rubric (100 points)

Skill	Points	Evidence threshold
ASIM source/field contract (A01–A02)	15	Correct parser semantics and source coverage, no fabricated data
Robust multi-stage KQL (A03)	15	Order, keys, window and duplicates handled
Detection mode choice + regression (A04–A05)	15	Realistic constraints, positive and negative tests
Hunt and ATT&CK (A06–A08)	20	Falsifiable hypothesis, mapped behavior, independent evidence, alternatives
SOAR design and controlled workflow (A09–A11)	15	Correct trigger, least privilege, human decision gate
Reliability and response governance (A12–A13)	10	Idempotency and timeout/reject protections
Debugging + evidence quality (A14)	10	Run-level root cause, cleanup evidence, candid limitations
Total	100

Suggested advancement rule: At least 80/100, plus all mandatory safety checks: no production intervention; no workflow able to act on out-of-scope incidents; rejection and timeout have no disruptive effects; roles are reviewed; evidence distinguishes actual runs from simulations. A conceptual-only learner cannot be represented as having completed a live SOAR deployment. This is an instructor rubric, not an official Microsoft certification.

Quick knowledge check (answers for instructors)

1. Why is a normalized IP insufficient for strong identity attribution? Because its semantics can be resolver, shared proxy, NAT or user-supplied; independently confirm who acted.
2. When is NRT different from scheduled rules? NRT executes on a fixed minute cadence and has result/window constraints; scheduled rules permit other configuration. Unified custom detections are a separate eligible experience.
3. Does an ATT&CK tag prove effectiveness? No; it maps intended behavior, not detection recall.
4. Why can’t Compose guarantee idempotency? It is not a durable, atomic record shared across runs.
5. Does an automation rule’s successful playbook launch prove the workflow finished successfully? No; inspect Logic Apps run history.
6. What happens when approval is rejected? No permitted remediation; record the decision and notify the case owner.
7. What if automation cannot be narrowed to the test scope? Do not turn it on; use supervised manual runs.
8. Can a learner claim completed human-in-the-loop authorization from an instructor-controlled Boolean? No; that is a simulation of branching, not external approval transport.

Syllabus coverage audit — Day 4 only

The following competencies are taught as new Day 4 skills. Days 1–3 are prerequisites and are not repeated as instructional labs.

Syllabus ID	New advanced competency	Primary hands-on evidence
A01	ASIM schemas, parser hierarchy, source normalization	D4-L01 parser contract
A02	Parser parameter filtering and performance	D4-L02 query comparison
A03	Multi-stage detection logic	D4-L03 fixture and live-source plan
A04	Scheduled, NRT, unified detection tradeoffs	D4-L04 decision record
A05	Detection regression and quality	D4-L05 test matrix
A06	Falsifiable threat hunts	D4-L06 hunt report
A07	ATT&CK technique mappings	D4-L07 mapping validation
A08	Entity/anomaly analysis	D4-L08 context and counterevidence
A09	SOAR trigger/action architecture	D4-L09, D4-L13 automation contract
A10	Controlled incident/case playbook	D4-L10 workflow and run evidence
A11	Workflow identities and privileges	D4-L11 IAM review
A12	Reliability, retries, deduplication	D4-L12 fault-injection evidence
A13	Approval and response guardrails	D4-L09–L10, D4-L13
A14	Workflow failure diagnostics	D4-L14 root-cause worksheet

Daily evidence checklist

• [ ] D4-L00 preflight, resource ownership and lab boundary
• [ ] D4-L01 parser/source contract and observed rows or documented missing-source condition
• [ ] D4-L02 optimized versus comparison queries and test context
• [ ] D4-L03 synthetic query and four negative variants
• [ ] D4-L04 scheduled/NRT/unified mode decision
• [ ] D4-L05 regression design and metrics disclaimer
• [ ] D4-L06 hunt report, UTC interval, alternative hypotheses
• [ ] D4-L07 ATT&CK coverage map with actual telemetry checks
• [ ] D4-L08 entity pivot and source confidence
• [ ] D4-L09 signed SOAR architecture and approval contract
• [ ] D4-L10 live or simulated approve/reject/wrong-scope execution status
• [ ] D4-L11 IAM and secrets audit
• [ ] D4-L12 idempotency and safe-failure verification
• [ ] D4-L13 scoped automation rule disabled after testing
• [ ] D4-L14 fault worksheet with observed root cause
• [ ] Capstone scored, safety signed off, learner status recorded

Safe cleanup checklist — do not delete shared training assets

1. Disable the lab automation rule first. Confirm no more automatic triggers occur.
2. Disable the lab Logic App workflow, after preserving only approved/sanitized run IDs and minimal evidence. Confirm no outstanding approval requests remain.
3. Delete optional sandbox tickets according to service desk procedures; preserve audit records that must be retained.
4. Remove temporary lab-specific Sentinel analytics rules and test content only if the instructor owns them and they are not prerequisites for Day 5; consider leaving them disabled for version-control labs.
5. Remove temporary lab role assignments with the approving RBAC owner, not blindly deleting inherited team access.
6. Delete Logic App resources only if not shared or required for Day 5, and only after reviewing associated resource groups, connection resources and cost impact.
7. Review Azure Cost Management and Logic Apps usage for the dedicated test scope; avoid claiming exact cost until billing data is available.
8. Preserve deliverables in controlled storage with redaction, retention policy and final learner signoff.

---

Common errors and escalation table

Problem	Likely origin	First diagnostic action	Acceptable alternate
_Im_Dns unknown	Query editor/workspace/function scope	Verify parser availability and query context	Schema mapping worksheet
ASIM query empty	Source not connected or time filter too narrow	Inspect raw source and UTC window	Labeled synthetic fixture
Correlation returns duplicates	Many-to-many join	Analyze keys, summarize before join	Deduplicated synthetic example
Alert not created	Rule disabled, schedule, no matching real source	Check rule health / actual source data	Design-only assessment
No bookmark creation in Defender	Feature limitation, not learner error	Save text/results in evidence repo	Saved query / hunt report
Playbook invisible	Wrong trigger or service account missing role	Inspect trigger type / playbook RG permissions	Manual workflow review
Unexpected connector prompt	Connector-based delegated OAuth	Validate approved auth and minimal scope	Mock Compose branch
Repeat approvals	No dedup or incident update loop	Disable rule, inspect duplicate runs	Instructor replay log
No approval action	Missing provider licensing/consent	Check connector and organization policy	Explicitly labeled simulated decision
401/403 at runtime	Incorrect identity/resource permissions	Open failed action + IAM mapping	Instructor-operated lab

Verification ledger (this edition)

Verification category	Status	Required next verification
Course coverage A01–A14	Structured against supplied agenda	Instructor confirms institutional objectives
Microsoft Learn portal/feature guidance	Cross-checked in November 2026	Recheck before delivering to a new tenant
KQL synthetic data relationships	Self-contained and designed for stated outputs	Execute in chosen KQL engine; save actual output
ASIM against your specific sources	Not executed	Run parser and raw-source comparisons
NRT/unified custom detection entitlement	Tenant-dependent, not executed	Confirm permitted rule types and roles
Logic Apps approval connector	Not executed	Test approve/reject/timeout with named approver
Automatic playbook invocation	Not executed	Observe incident/case trigger and Logic Apps run history
Costs, RBAC and region	Not verified for your subscription	Verify region, budget, resource IAM and billed usage

Source register — official documentation and technique definitions

These links were consulted for concepts, feature changes or procedural paths as of 1 November 2026. Website guidance may update later. The course is an independently authored educational resource, not a Microsoft-authorized certification lab.

• [R01] Microsoft Sentinel in Microsoft Defender portal / navigation and 2027 cutoff
• [R02] ASIM parsers overview
• [R03] Using ASIM parsers and supported filter parameters
• [R04] Create NRT analytics rules
• [R05] Microsoft Defender custom detection rules
• [R06] Hunting bookmarks and Defender limitations
• [R07] Create and manage Sentinel playbooks
• [R08] Run playbooks, automation rules and required permissions
• [R09] Automation rules and their execution
• [R10] ASIM parsers list by source
• [R11] Microsoft Sentinel threat hunting capabilities
• [R12] MITRE ATT&CK T1078.004 and T1098.003
• [R13] Azure Logic Apps playbooks concepts, authentication, workflow types

End of standalone Day 4 manual. Completion prepares the learner for Day 5 enterprise architecture, data strategy, detection-as-code, governance and capstone; none of those are retaught here.