Module 1: Fundamentals / Essentials / Foundations | Day 1 and Day 2

Edition: 1 November 2026
Format: Two-day, instructor-led, day-wise practical manual; no hourly timetable
Audience: New SOC analysts, security engineers, Azure administrators, DevOps/SRE engineers, technical trainers
Primary product experience: Microsoft Sentinel in the Microsoft Defender portal (https://security.microsoft.com)
Azure provisioning: Azure portal (https://portal.azure.com)
Scope: Exactly the Foundations curriculum, topic IDs F01–F23. Intermediate correlation, DCR/AMA/CEF, custom workbooks, advanced hunting, SOAR playbooks, and enterprise deployment are left to Days 3–5.
Evidence standard: Every hands-on lab has prerequisites, actions, observable pass/fail checks, troubleshooting, and a learner deliverable.
Source basis: User-provided Microsoft_Sentinel_Module_1_Foundations_2_Days(3).md, cross-checked against the official Microsoft documentation listed in References.

Important validation and safety statement

This manual has been checked against the Microsoft Learn procedures and current documented UI paths as of 1 November 2026. It has not been executed inside your Azure subscription or Microsoft Entra tenant. Actual portal labels, regional availability, tenant policy, licensing, role assignment, data volume, and alert-correlation behavior must be verified using the explicit PASS gates below. Never mark an environment-specific step PASS merely because the command or page is documented.

We distinguish four different kinds of proof throughout:

DOC-VERIFIED: The documented approach, prerequisite, or product behavior was checked against a linked Microsoft Learn page.
LAB-PASS: Your learner actually performed the step, captured the required evidence, and met the observable acceptance criterion.
SIMULATED: KQL examples use a local datatable; they demonstrate query syntax and reasoning but do not ingest data, generate a real Sentinel alert, or create an incident.
BLOCKED: An unavoidable permission, license, provisioning, policy, or data-source dependency prevents the live step. Record the blocker, use the approved fallback, and do not claim a live pass.

Non-negotiable guardrails: Use a dedicated approved training subscription or isolated test resource group. Obtain the owner/security team’s written authorization before creating Azure Policy assignments, diagnostic settings, connectors, Sentinel rules, or incident workflow changes. Do not connect production identities, copy confidential logs, disable actual defenses, create false malicious events, or configure disruptive automated response. In particular, do not grant Owner to every learner to make the exercises easier. No exercises require passwords, tokens, API keys, or real attack execution.

1. How to use this complete manual

1.1 End-to-end outcome

After Day 1, the learner can explain how security telemetry reaches Sentinel, deploy or access a correctly scoped workspace, navigate Sentinel through the Defender portal, and prove that an approved Azure Activity event arrived. After Day 2, they can examine records and timestamps, use beginner KQL, install and inspect built-in content, enable a supported scheduled rule, investigate a controlled alert/incident, interpret a workbook, and complete a structured first-line SOC report.

The same fictional organization and activity flow are used across both days so the learner develops a consistent mental model rather than jumping between unrelated demos.

1.2 Course structure and lab navigation

Day	Lab ID	Activity	Key topic IDs	Primary evidence
1	D1-L01	SOC event-to-incident tabletop and 5W1H	F01–F06	5W1H/SOC roles worksheet
1	D1-L02	Draw and defend the Sentinel architecture	F07–F08	Architecture diagram with boundaries
1	D1-L03	Tenant, subscription, permissions, and cost preflight	F08–F10	Approved environment readiness record
1	D1-L04	Create a dedicated Log Analytics workspace	F09, F11	Workspace resource proof
1	D1-L05	Enable Sentinel and confirm the Defender portal	F11	Workspace and Defender proof
1	D1-L06	Install the Azure Activity solution	F12; foundations for F16	Solution install evidence
1	D1-L07	Connect Azure Activity using the approved method	F12	Export/connector configuration
1	D1-L08	Generate safe telemetry and confirm ingestion	F12	Source and destination event match
2	D2-L01	Explore real log records and table fields	F13, F15	Record worksheet
2	D2-L02	KQL fundamentals, filtering, counting, and timelines	F14–F15	Executed query pack
2	D2-L03	Offline synthetic KQL safety net	F14	Marked simulated results
2	D2-L04	Content hub and starter analytics-rule template	F16–F17	Rule prerequisites and active rule
2	D2-L05	Verify the actual alert path using a controlled lab rule	F17–F18	Rule → alert → incident evidence
2	D2-L06	Triage, classify, and escalate the lab incident	F18–F20, F22	Complete SOC incident record
2	D2-L07	Interpret a built-in workbook	F21	Answered visualization questions
2	D2-L08	Troubleshooting challenge and operational checklist	F22–F23	Root-cause worksheet
2	D2-L09	Foundations capstone and entry check for Day 3	F01–F23	Graded evidence folder
Both	END-L01	Safe cleanup, cost review, handoff	F09, F22–F23	Signed cleanup record

Content note: D2-L05 is a controlled demonstration fallback, not a new intermediate-level custom-detection engineering module. Its purpose is to show that alerts and incidents actually work if a generic solution template does not match your harmless test event. Complex detection logic, tuning and correlation remain in Day 3.

1.3 5W1H learning contract

Lens	Day 1 learner must answer	Day 2 learner must answer
What	What are a SIEM, SOAR, XDR, event, alert, incident, workspace?	What are KQL, analytics templates, cases/incidents, workbooks?
Why	Why centralize audit telemetry and maintain SOC ownership?	Why query and verify raw evidence before alerting or escalation?
Who	Who deploys, administers, reads, triages, and approves changes?	Who owns a rule, handles an alert, and closes a case?
When	When do we onboard a source or use a SIEM instead of a dashboard?	When do we query, alert, escalate, or close?
Where	Where do subscription logs, Log Analytics, and Defender navigation live?	Where do rule templates, records, alerts, incidents, and workbooks live?
How	How does an Azure Activity event reach the workspace?	How do `where` → detection threshold → alert → incident → disposition work?

1.4 Learning environment patterns — select one before class

Pattern	Requirements	Appropriate use	Evidence claim
A. Full live lab (preferred)	Approved Azure subscription; live Sentinel workspace; Azure Activity export; authorized instructor/learners	All provisioning, ingestion, and alert/incident labs	End-to-end LAB-PASS if gates all pass
B. Shared instructor-managed lab	One instructor-owned workspace and solution; least-privilege learner access; instructor executes privileged actions	Organizations unable to grant create/policy privileges to students	Learners can pass queries/triage; infrastructure setup may be observed
C. Offline KQL and evidence simulation	A query-capable Kusto/Log Analytics environment supporting `datatable` or instructor-approved example output	No subscription, access, or connector permission	Only syntax and analysis stages are SIMULATED; no claim of live Sentinel operations

Strong recommendation: For a real instructor qualification, use Pattern A or B; a completely offline lab cannot satisfy the hands-on deployment/ingestion/incident progression gate.

2. Instructor preparation — do this before learners begin

2.1 The fictional case: Aster Retail

Aster Retail has an Azure subscription hosting internal applications. The security team wants an auditable trail of Azure control-plane changes. The lab creates or modifies only harmless, preapproved Azure training resources. Every learner receives a unique resource prefix so that a simulated incident can be identified without confusing it with another student’s work.

Sample names — replace before use:

Item	Example	Rule
Tenant	`<TRAINING-TENANT>`	Record the actual tenant selected in the portal
Subscription	`<TRAINING-SUBSCRIPTION-ID>`	Never assume the default Azure CLI or portal subscription is correct
Resource group	`rg-sentinel-foundations-lab01`	Instructor-created, clearly tagged, no production resources
Log Analytics workspace	`law-sentinel-foundations-lab01`	Must meet workspace name/region restrictions
Activity signal group	`rg-sentinel-signal-lab01`	Separate small RG used only to create benign activity events
Demo analytics rule	`LAB01 - Approved Azure Activity Test`	Must be disabled/deleted at teardown
Instructor	`<INSTRUCTOR-UPN>`	Never put a personal email into published lab screenshots
Evidence path	`Day01/`, `Day02/`, `Assessment/`, `Cleanup/`	Local or institution-approved storage only

Naming hygiene: Do not blindly reuse the same names when more than one learner shares the subscription; assign a unique short suffix (such as lab01, lab02) and confirm name availability. For rule queries that contain a sample name, the learner must replace it with their actual unique name.

2.2 Prerequisites matrix: exact operational separation

Persona	Access to request	Scope	Used for	Verification
Instructor / provisioner	Subscription Contributor or equivalent for Sentinel enablement; permissions to create RG/workspace	Approved training subscription	D1-L04/05	Successful deployment and Sentinel addition
Instructor / onboarding approver	Appropriate Microsoft Entra administrator role and unconditional subscription Owner, or supported alternative User Access Administrator + Sentinel Contributor, per Defender onboarding documentation	Tenant + specified subscription	Manual Defender portal connection when required	Workspace visible in Defender
Policy approver	Owner at Azure Policy assignment scope, per the Azure Activity policy-driven connector guidance	Training subscription/scope	D1-L07 Policy route	Policy assignment exists and is effective
Security content engineer	Microsoft Sentinel Contributor, preferably scoped to Sentinel RG	Sentinel workspace RG	Content hub install / analytics rule creation	Can install solution and save rule
SOC analyst / learner	Microsoft Sentinel Responder for incident modification; Reader only for read-only log review	Sentinel RG/workspace as permitted	KQL, incident investigation	Can view records and update assigned lab incident
Workbook viewer	Workbook Reader or appropriate equivalent; creation/editing requires appropriate Workbook Contributor privileges as documented	Workbook/Sentinel RG	D2-L07	Opens installed workbook

Do not confuse: Azure resource roles, Microsoft Entra admin roles, and Microsoft Defender unified RBAC permissions are different security systems. Preview incident cases can additionally require Defender unified RBAC Security Data Read / Security Data Manage. Only grant an entitlement after the instructor or Azure administrator has verified the exact task at the intended scope. See [R02], [R03], [R07], [R13].

Instructor readiness checklist (mandatory)

[ ] Written permission to use the subscription and enable Sentinel obtained.
[ ] Tenant and subscription IDs recorded; no cross-tenant confusion.
[ ] Training region approved for organizational location/residency policy.
[ ] Unique RG/workspace/signal RG names assigned.
[ ] Cloud costs and quotas approved; budget owner identified.
[ ] Provisioner, policy approver, engineer, and analyst roles confirmed.
[ ] Defender portal onboarding permissions confirmed, if manual onboarding is needed.
[ ] Existing Azure Activity diagnostic settings/policy assignments checked to avoid duplicate export.
[ ] Existing Sentinel workspaces and data connector instances inventoried to avoid interfering with them.
[ ] A backup learning path is approved: instructor workspace or synthetic KQL + sample evidence.
[ ] Learners can reach portal.azure.com and security.microsoft.com through approved browser/network access.
[ ] A clean incident/test naming convention and cleanup owner assigned.
[ ] End-of-course evidence folder prepared, with controlled access and retention.

PASS gate PRE-1: Instructor signs the checklist and writes READY / BLOCKED beside each dependency; do not let students begin Azure Policy assignment without approval.

2.3 Cost and lifecycle planning (do not assume “free”)

Review Microsoft Sentinel billing in [R04]. Microsoft documents a 31-day trial for up to the first 10 GB/day of Analytics-tier ingestion, subject to conditions including a per-tenant workspace limit; do not assume the trial applies to a previously enabled workspace or to all ancillary services.
Microsoft separately documents that Azure Activity log ingestion to a Log Analytics workspace is not charged for ingestion; retention beyond the default included duration can incur charges. Do not generalize this exception to other telemetry. [R06]
Review workspace data-retention configuration and organizational policy. Microsoft’s Sentinel quickstart recommends checking/raising legacy 30-day retention to 90 days when needed for full Sentinel features. Do not change retention in a shared workspace without approval. [R01]
In Azure portal, open Cost Management + Billing (or the delegated subscription’s Cost Management view), inspect subscription budgets and cost alerts, and record the approved cost ceiling. A budget is not an automatic hard spending cap.
Do not create paid infrastructure merely to generate events: training RG creation and tagging are enough for the Azure Activity teaching scenario.
At the end of the class, disable/delete temporary rule(s), remove the synthetic signal group, and review which Sentinel workspace/connector/configuration must be retained or removed.

2.4 Recording actual results

Use this same concise form for every lab:

Lab ID:                 D1-LXX / D2-LXX
Learner / group:        __________________
UTC start / end:        __________________
Tenant / subscription:  __________________ (redact in shared materials)
Workspace / region:     __________________
Actions completed:      __________________
Observed result:        __________________
Evidence filename(s):   __________________
Status:                 LAB-PASS / SIMULATED / BLOCKED / NEEDS-RETRY
Error / diagnostic:     __________________
Reviewer signature:     __________________

Screenshots: Include the browser page title and the relevant row/data fields; remove secret identifiers, tokens, other users’ data, and unrelated production resources. Redaction must not hide the exact signal or configuration that proves the acceptance criterion.

DAY 1 — Fundamentals, Architecture, Setup, and First Data

Day 1 goal: Explain the platform with 5W1H, demonstrate understanding of its architecture and security roles, then provide actual evidence that benign Azure administration telemetry is reaching Sentinel.

D1-L01 — SOC fundamentals, responsibilities, and the 5W1H tabletop

Syllabus: F01, F02, F03, F04, F05, F06.
Type: Tabletop; no Azure permissions needed.
Deliverable: Day01/D1-L01-SOC-Worksheet.md (learner-authored).

Concepts the learner needs before clicking anything

Security event: An observed action (for example, creating an Azure resource group).
Telemetry/log: Recorded event data describing actor, resource, time, action, status, and source.
SIEM: Security information/event management — collects, queries, correlates, detects, and supports investigation of security data.
SOAR: Security orchestration, automation and response — coordinates predefined investigative/response actions, often involving workflows and approvals.
EDR/XDR: Endpoint detection/response and extended detection/response; complementary to SIEM, not interchangeable with a raw-log datastore.
Detection/analytic rule: Logic that tests records for an interesting condition.
Alert: A detection result indicating something requires attention. An alert is not proof of a compromise.
Incident: An investigation container grouping one or more relevant alerts and evidence; a security conclusion requires analyst assessment.
False positive / expected test activity: An alert that does not correspond to the harmful activity the rule is intended to find; document the exact disposition used.
Response: Authorized steps to document, contain, recover, and follow up; Day 1–2 permits only documentation and harmless incident administration.

Guided steps

Write a single sentence defining the business purpose of the SOC. Example: “Detect, verify, prioritize, investigate, and coordinate response to important security events.”
Write a six-line answer for What / Why / Who / When / Where / How for Microsoft Sentinel using the terms above.
Your instructor describes this scenario: “A new Azure resource group appears at 10:25 UTC. The creator was a known administrator.” Decide whether this alone is a log, alert, incident, or confirmed threat. Explain why the event by itself is not evidence of malicious activity.
Write a simple escalation chain: Platform admin → SOC L1 → SOC L2/Incident commander → Service owner, and assign a typical responsibility to each role.
Compare these options in a short table: Azure Monitor Logs without Sentinel, Sentinel SIEM, an EDR product, a vendor-operated traditional SIEM, and a spreadsheet or ticket queue.
List two advantages (for example, centralized analytics and integrated cloud collection) and two limitations (for example, data/retention costs and dependency on data quality plus analyst response processes).
Have another learner challenge your definition of “incident” and your decision to escalate. Correct any assumption that “every admin action is malicious.”

Expected answer check

Question	Passing response
Why not alert on every Azure change?	That creates noise; baseline/context and intended behavior matter.
Who should install connectors?	Authorized engineer/administrator, not a reader-only analyst.
What does Sentinel add to raw Log Analytics?	Security content, detection/incident workflows and SOC experiences.
Where is today’s primary UI?	Microsoft Defender portal; Azure still provisions the workspace.
What happens after an alert?	Investigate evidence, choose disposition, document and escalate when justified.

PASS gate D1-01: All six 5W1H prompts addressed, comparison completed, roles assigned, and event/alert/incident correctly distinguished. Common mistake: Treating XDR, SIEM, SOAR, incident ticketing, and Log Analytics as identical products.

D1-L02 — Draw the core Sentinel architecture

Syllabus: F07, F08. Type: Architecture exercise. Deliverable: Day01/D1-L02-Architecture.md or a diagram image made by the learner.

Reference architecture — teach the arrows, not just boxes

Azure subscriptions / and other approved sourcesConnectors and / diagnostic exportLog Analytics workspace / AzureActivity tableSentinel detection content / Analytics rulesSecurity alertsIncident investigation / in Microsoft DefenderKQL hunting and / workbooksAnalyst disposition / and escalation

Clarification: This is a logical view. Actual Microsoft components may share platform services; it is not a network diagram showing independently deployed VMs. Security data in separate Sentinel workspaces is not automatically one merged table.

Guided steps

Draw all seven logical elements, including a boundary around the Azure subscription, a boundary around the Microsoft Entra tenant, and a boundary around the Log Analytics workspace.
Identify the source for the teaching case: Azure Activity (subscription control-plane activity), not VM guest logs or Azure resource data-plane logs.
Label the actual destination table AzureActivity and the time field TimeGenerated.
Label the configuration UI Azure portal, security operations UI Defender portal, and the data store Log Analytics workspace.
Put a lock/role icon beside the policy export, rule authoring, and incident editing arrows; each has different required permissions.
Trace one event: create/tag lab resource → Azure Activity log → configured diagnostic export → workspace AzureActivity → KQL → optional scheduled rule → alert → incident.
Explain what happens if the connector is configured but the source has produced zero matching events; then explain what happens if an analytics rule query returns zero rows.
Have the instructor hide one arrow. Learner identifies which downstream capability will fail and what evidence to check first.

PASS gate D1-02: Diagram contains source, connector, workspace, table, detection, alerts, incident, analyst, portals, and access boundary. Learner can identify three common points of failure: no export, wrong workspace, rule has no matches.

D1-L03 — Identify the actual tenant, subscription, region, access, and constraints

Syllabus: F08–F10. Type: Azure portal preflight. Prerequisite: Instructor-approved account, subscription access.
Deliverable: Day01/D1-L03-Environment-Readiness.md.

Step-by-step

Open https://portal.azure.com using the approved training account.
Check the current directory / tenant in the account selector. If multiple directories are visible, explicitly switch to the instructor-approved one. Record tenant display name and tenant ID in private evidence.
In Azure portal search, type Subscriptions and open the approved training subscription; copy the subscription name/ID into the private readiness form.
Open Subscriptions → [training subscription] → Access control (IAM) → View my access (or the equivalent available access view). Record what this account can actually do. Seeing a subscription does not mean you can create resources or grant roles.
Check the proposed region’s policy, residency requirements, and availability before creating the workspace. Record region and justification. Do not move an existing Sentinel workspace between subscriptions/RGs as a lab task; Microsoft documents this as unsupported for a Sentinel-enabled workspace. [R01]
Under the same subscription, review the existing Resource groups list; verify no resources will be changed by name collision.
Check if a workspace is already supplied by the instructor. If yes, record its name, RG, region, and permissions; do not create a second one unless approved.
Ask the instructor/provisioner to demonstrate that they can create resources and approve Policy/Defender onboarding where required. Do not request a standing subscription Owner grant for learners.
Open the subscription’s Cost Management page. Record budget owner, threshold and who will watch costs. Document that a budget alert is informational, not a spending stop.
Verify browsers can access both Microsoft portals; if the Defender portal opens but Sentinel is absent, record that as an onboarding/permission state, not as proof that Sentinel is broken.
Confirm the unique suffix to be used for lab resources and test rules; do not begin provisioning until instructor sign-off.

Preflight evidence record

Training directory/tenant:      __________________
Training subscription:          __________________
Approved Azure region:          __________________
Sentinel resource group:        __________________
Workspace (existing or new):    __________________
Signal resource group:          __________________
Workspace creation approval:    Yes / No
Azure Policy export approver:   __________________
Content Hub/rule editor:        __________________
Analyst/incident editor:        __________________
Expected cost policy:          __________________
Defender portal ready:         Yes / No / Not yet

PASS gate D1-03: The actual tenant, subscription, workspace/RG plan, region, required role owners, cost owner, and clean name prefix are recorded. STOP if either environment or permission scope is uncertain.

D1-L04 — Create a Log Analytics workspace, or validate the instructor’s workspace

Syllabus: F09, F11. Type: Live provisioning. Authorization: Approved provisioner. DOC-VERIFIED: [R01], [R02].

Branch A — new isolated workspace (preferred for a provisioning class)

In Azure portal, search Microsoft Sentinel.
Select Create. If a suitable workspace does not exist, select Create a new workspace. The provisioning UI may lead into the Log Analytics workspace creation experience.
Select the approved subscription.
Under Resource group, create or choose the preapproved lab RG, e.g. rg-sentinel-foundations-lab01.
Enter a unique Log Analytics workspace name, e.g. law-sentinel-foundations-lab01.
Choose the instructor-approved Azure region; verify it matches the lab plan and residency requirements.
Select Review + Create, review subscription, RG, name, region and any pricing/retention settings, then Create.
Wait for deployment success, and open Log Analytics workspaces → [workspace] → Overview.
Record the workspace name, region, RG, subscription. Take screenshot D1-L04-Workspace-Overview.png.
Check the workspace’s data retention settings with the instructor. If legacy defaults conflict with the intended Sentinel training, obtain approval and configure an appropriate retention period following the current Microsoft instructions. Do not automatically change enterprise retention policy.

Branch B — supplied workspace (shared lab)

Open Log Analytics workspaces and select the provided workspace.
Verify name, RG, region and subscription match the instructor sheet.
Verify read/write rights according to the action the learner will perform; if read-only, provisioning is observed and later labs use the already configured source.
Record that the workspace was pre-existing and whether Sentinel is already enabled.

Validation checklist

[ ] Workspace resource exists and is in the intended subscription/RG.
[ ] Region matches approved plan.
[ ] Provisioner can view the workspace overview without deployment errors.
[ ] No collision with production workspace; no unintended existing configuration modified.
[ ] Retention decisions reviewed; no unapproved changes.

PASS gate D1-04: Workspace successfully provisioned or an approved existing workspace identified and verified. Error branches: “Not authorized” → role/scope admin; “region not supported” → use approved alternate; deployment denied by policy → show denial details to policy admin; workspace not found → wrong subscription or directory.

D1-L05 — Enable Microsoft Sentinel and verify Microsoft Defender access

Syllabus: F11. Type: Live onboarding. DOC-VERIFIED: [R01], [R03].

Step A — Add Sentinel to the workspace

In Azure portal, search and open Microsoft Sentinel.
Select Create (or the option to add a workspace).
Find the workspace from D1-L04. If it does not appear, verify subscription, resource group, supported workspace type, and current permissions before retrying.
Select the correct workspace and choose Add.
Confirm the onboarding operation has completed, then check that the workspace is displayed as Sentinel-enabled. Capture D1-L05-Sentinel-Enabled.png.
If the workspace was already enabled, record existing state instead of trying to re-enable it.

Step B — Confirm the Defender portal (standard experience)

Go to https://security.microsoft.com with the same intended tenant.
On a newly onboarded workspace, check whether Sentinel already appears in the left navigation. Microsoft documents that many new workspaces are automatically connected to Defender. [R03]
In the Defender navigation, open System → Settings → Microsoft Sentinel → Workspaces (navigation wording may show Settings directly in some layouts).
Confirm the expected workspace is listed, verify whether it is the primary workspace, and capture D1-L05-Defender-Workspace.png.
If not connected, stop and request an authorized onboarding administrator. An authorized admin can open System → Settings → Microsoft Sentinel → Connect a workspace, select the workspace, choose the primary workspace, review changes, and select Connect. This requires the documented combination of Entra/Azure permissions, not simply Sentinel Reader. [R03]
Reopen the Defender portal after provisioning/connection. Allow for initial tenant provisioning delay; refresh after the admin confirms successful connection.
Expand Microsoft Sentinel and identify Configuration, Content management, and Threat management menu groups. Open each without changing anything. In some views, the Advanced hunting query editor is opened through the connector’s Go to log analytics shortcut.
Explain why a Microsoft Defender XDR/E5 license is not required solely to access Sentinel in the Defender portal, but access to additional Defender XDR data and features depends on separate licensing/entitlements. [R03]

Troubleshooting and gate

Symptom	First test	Next action
Workspace missing from Sentinel Add list	Correct tenant/subscription/workspace	Verify eligibility and provisioner permissions
Sentinel enabled, invisible in Defender	Check Workspaces under Sentinel settings	Auto-provisioning delay, then authorized manual connect
Learner sees portal but cannot view incidents/logs	Check effective Sentinel/Defender roles	Correct specific role scope and RBAC as needed
Cannot manually connect	Check Entra admin role and subscription authorization	Escalate to onboarding administrator; no blanket Owner grant

PASS gate D1-05: Learner shows a correctly Sentinel-enabled workspace and its association in the Defender portal. If onboarding is instructor-performed, explicitly mark the provisioning portion “observed” and verify learner read access separately.

D1-L06 — Install the Azure Activity solution from Content hub

Syllabus: F12 (introduces Day 2 F16). Type: Guided content deployment. Role: Sentinel Contributor. DOC-VERIFIED: [R01], [R08].

Steps

In Defender portal, expand Microsoft Sentinel → Content management → Content hub.
Enter Azure Activity in the search box and run the search.
Select the Azure Activity solution; read its publisher/provider, description, version/support information and included types of content.
Check whether the solution shows Installed, Not installed, or an available Update. Do not blindly update shared content.
If not installed and approved, select Install (or View details → Create / Update, depending on the current Content hub flow).
Select the approved subscription, RG, and Sentinel workspace when the content deployment wizard requires them; confirm the destination is not a different workspace.
Review content items, select Create/Install, and wait for a success status.
Return to Content hub and confirm the item reports installed; record its name and version in D1-L06-Content-Record.md.
For learning, identify the difference among Solution, Data connector, Analytics rule template, and Workbook template. Installing a solution does not itself start all its connectors or schedule all its rules.

PASS gate D1-06: Azure Activity solution installed in the correct workspace; learner explains why additional connector configuration is required.

Failure paths

Install disabled: inspect Microsoft Sentinel Contributor permission on the appropriate RG.
Solution not found: clear Content hub filters or refine search; check region/tenant content access.
Deployment failure: open deployment details, record failure code and resource provider/permission issue; do not guess.
A similar solution is already installed: document and reuse; do not create a duplicate.

D1-L07 — Configure the Azure Activity connector safely

Syllabus: F12. Type: Approved subscription-level diagnostic export. DOC-VERIFIED: [R01], [R06], [R09].

Scope alert: Azure Activity is a subscription/management control-plane log, not VM Syslog. The typical connector uses the Azure Monitor diagnostic-settings pipeline; the Sentinel connector walkthrough provides an Azure Policy assignment wizard. The policy-based route has a higher permission bar than simply reading Sentinel. Do this only in the preapproved training subscription. Check existing exports first to avoid duplicate data flows.

Step A — identify the data source and current state

In Defender portal, open Microsoft Sentinel → Configuration → Data connectors.
Search Azure Activity, select the connector, and choose Open connector page.
Read its Prerequisites, Data types, Instructions, and current Status. Record whether it is Connected, Not connected, or not yet reporting.
In Azure portal, check whether the training subscription already exports Activity logs to the intended workspace. Typical route: Monitor → Activity log → Export Activity Logs; inspect existing diagnostic settings. Alternatively inspect the approved Azure Policy assignment for Activity Log forwarding.
If an existing export sends the correct required categories to the correct workspace, reuse and verify, rather than adding another export blindly.
If the environment uses the legacy Activity Log collection method, follow the Microsoft’s documented migration/disable guidance with the environment owner before enabling a new pipeline. Do not unilaterally disconnect business-critical collection. [R09]

Step B — preferred Microsoft Sentinel connector route (Azure Policy wizard)

Perform only with an authorized policy assignment owner.

On the Azure Activity connector page, choose Launch Azure Policy Assignment Wizard.
Set assignment Scope to the instructor-approved subscription containing the benign lab activity. Avoid an entire management group or production subscription.
Review the policy identity, exclusions, effects, and any needed remediation/permissions that the actual wizard shows; involve the policy owner if those prompts appear.
Open Parameters; set Primary Log Analytics workspace to the exact workspace from D1-L04.
If a non-default policy assignment name is requested, choose a recognizable lab-specific name. Record it and its scope for cleanup.
Review assignment details; confirm subscription, scope, destination workspace, effect, and approving owner.
Select Review + create → Create only after approval.
In Azure Policy → Assignments, locate the new assignment. Record scope, identity/remediation state, and compliance/provisioning outcome. Initial policy evaluation/diagnostic flow can take time.
Return to the connector and review status, but do not treat a Connected badge alone as proof that a particular event arrived.

Step C — approved direct diagnostic-setting alternative

Use only if approved by the instructor/cloud administrator and the standard policy route cannot be used or is not appropriate; do not configure both routes for the same source/destination without a reason.

In Azure portal, open Monitor → Activity log → Export Activity Logs.
Select the training subscription and choose Add diagnostic setting.
Give it a descriptive name, e.g. diag-sentinel-activity-lab01.
Select the Administrative Activity Log category at a minimum for the group-change exercise; add other categories only when approved by policy and training requirements.
Under destination details, choose Send to Log Analytics workspace.
Select the approved subscription and the Sentinel-enabled Log Analytics workspace.
Review scope, log categories, destination workspace, then Save. Record the exact diagnostic setting name and owner for teardown.
Return to the training subscription’s Activity log, confirm there are recent administrative events, then use D1-L08 to verify they also reach AzureActivity in the destination workspace.

Important: Direct diagnostic configuration and policy-managed settings are two documented mechanisms with different administrative routes. The approved approach is determined by the instructor/environment owner, not by convenience. [R06], [R09]

PASS gate D1-07

[ ] Documented connector method and approver.
[ ] Approved source subscription/scope.
[ ] Correct destination Log Analytics workspace.
[ ] Export/policy config exists with no accidental duplicate export.
[ ] No production resources or unrelated subscriptions changed.
[ ] Named cleanup owner and configuration ID recorded.

Status distinction: This passes configuration. The separate D1-L08 telemetry proof is mandatory for ingestion.

D1-L08 — Generate harmless activity and prove first data ingestion

Syllabus: F12. Type: Live controlled activity. DOC-VERIFIED: Azure Activity logs, destination table and official quickstart [R01], [R06], [R10].

Why this lab is necessary

A configured connector and a working rule template are not the same as telemetry arriving in a particular workspace. Conversely, a rule being enabled does not mean it has found an event or created an alert. We verify each distinct boundary.

Step A — create an approved, non-disruptive Azure change

Wait for the instructor to confirm the diagnostic export is active or no provisioning blockers remain.
In Azure portal, open Resource groups → Create.
Select the training subscription; enter the unique activity group name, e.g. rg-sentinel-signal-lab01.
Choose the approved region and add tags such as purpose=sentinel-foundations-lab, owner=training, and cleanup=required if the portal requests tags or after creation.
Select Review + create → Create. Only create this empty RG; do not deploy a VM, firewall, storage account, or additional paid service.
Open the new signal RG, go to Tags, add or update exercise=D1-L08, and Save. This creates another harmless resource-management operation.
Open Monitor → Activity log in Azure portal. Set scope/subscription/time window to include your changes; filter the resource group or resource ID, if available. Record the observed operation name, status, timestamp in UTC, and resource ID. This is the source-side proof.
Note the actual event’s ResourceGroup value might be blank or differ for subscription/RG-level operations; use ResourceId as a cross-check rather than demanding a populated ResourceGroup field.

Step B — query the Sentinel-enabled destination

In Defender portal, select Microsoft Sentinel → Configuration → Data connectors → Azure Activity → Open connector page.
Review connector status, then select Go to log analytics (the official quickstart may open the Advanced hunting editor). You can instead open the approved Log Analytics workspace’s Logs experience if your tenant supports that route.
If the editor presents a table/workspace scope selector, confirm the intended Sentinel workspace. Do not assume default scope.
Start with the shortest possible query:

AzureActivity
| where TimeGenerated >= ago(24h)
| take 20

Select Run. If rows are returned, inspect TimeGenerated, CategoryValue, OperationNameValue, ActivityStatusValue, ResourceId, ResourceGroup, CorrelationId, and Caller where populated.
Narrow to the unique signal RG by replacing the sample string:

let signalGroup = "rg-sentinel-signal-lab01";
AzureActivity
| where TimeGenerated >= ago(24h)
| where ResourceId contains signalGroup or ResourceGroup contains signalGroup
| project TimeGenerated, CategoryValue, OperationNameValue,
          ActivityStatusValue, ResourceGroup, ResourceId,
          Caller, CorrelationId
| sort by TimeGenerated desc

Compare one record with the earlier source-side Activity log: resource ID, operation, timestamp, status, and (when present) CorrelationId. Timestamps may differ slightly between event occurrence and ingestion availability; do not require exact arrival instant.
Save query text in the evidence folder and capture D1-L08-Sentinel-AzureActivity-Result.png.
If the result contains no rows, continue the diagnostic ladder below; never fabricate a screenshot or claim the connector worked.

Diagnostic ladder: source → export → destination → query

Source: Does Azure portal Activity log display the actual benign RG action? If no, check subscription/time filters and whether the operation succeeded.
Export: Is the diagnostic setting/policy assigned to the correct subscription and correct workspace? Check deployment, policy compliance/remediation and existing settings.
Delay: Microsoft notes that diagnostic-export initiation can take on the order of tens of minutes (their troubleshooting guide cites around 30 minutes in a common export scenario). Wait within the instructor’s authorized lab window and recheck; never promise instantaneous arrival. [R11]
Destination: Run an unfiltered AzureActivity | where TimeGenerated >= ago(48h) | count against the correct workspace. If there are no records, investigate pipeline setup before fine-tuning KQL.
Filter: Remove ResourceGroup filtering; use ResourceId, broaden time, compare casing and source event structure. Microsoft documents case differences across Activity Log fields; prefer case-insensitive operators. [R06]
Rights: A query access error is not the same as no telemetry; verify workspace read/query privileges.

PASS gate D1-08

At minimum: Show an actual Azure portal Activity log event and corresponding AzureActivity record in the intended Log Analytics workspace, or record a genuine BLOCKED outcome with the first failing boundary. Preserve source evidence, destination query, recorded UTC timestamps and sample resource identifier. This ends Day 1’s technical progression gate.

Day 1 completion check

[ ] D1-L01 5W1H + SOC roles + alternatives.
[ ] D1-L02 architecture explanation.
[ ] D1-L03 safe tenant/subscription/RBAC/cost preflight.
[ ] D1-L04 workspace proof.
[ ] D1-L05 Sentinel/Defender proof.
[ ] D1-L06 Azure Activity solution proof.
[ ] D1-L07 authorized export proof.
[ ] D1-L08 matching source and ingested record, or clearly documented blocker.

DAY 2 — Log Analysis, Detection, Incidents, Workbooks, and Assessment

Day 2 entry requirements: Learner has completed Day 1’s conceptual exercises and can access a Sentinel-enabled workspace. The instructor has produced or approved a real AzureActivity event for the live branch. If not, start with D2-L03’s simulated KQL branch and record any live tasks as BLOCKED until the source is repaired.

D2-L01 — Inspect real security records and explain the schema

Syllabus: F13, F15. Type: Live read-only log analysis.
Prerequisites: D1-L08, permission to query the intended workspace.
Deliverable: Day02/D2-L01-Record-Worksheet.md. Reference: [R10].

Guided steps

Open Defender portal and navigate to the Azure Activity connector, then select Go to log analytics, or go to the workspace’s Logs editor as approved by the instructor.
Confirm tenant, workspace/data scope, and time window. Use Last 24 hours first, then broaden if your approved signal is older.
Run:

AzureActivity
| where TimeGenerated >= ago(24h)
| sort by TimeGenerated desc
| take 20

Open one record and inspect every column available. Compare the actual schema with the reference fields in [R10]. Do not assume that all optional values are populated.
For one known lab action, note the following:

Question	Field to inspect	Learner finding
When did it occur?	`TimeGenerated` (UTC)	__________
Which operation occurred?	`OperationNameValue`	__________
Was it successful?	`ActivityStatusValue`	__________
Which resource was affected?	`ResourceId`	__________
Which subscription?	`SubscriptionId`	__________
Which resource group?	`ResourceGroup` (may be empty for scope-level operations)	__________
Who made the request?	`Caller` (may be UPN/service principal identifier/GUID)	__________
Which related operation group?	`CorrelationId`	__________
Which category?	`CategoryValue`	__________

Compare TimeGenerated to EventSubmissionTimestamp when the latter is populated. Explain event occurrence versus availability/submission; do not treat these as guaranteed-identical timestamps.
Explain the difference between an empty field, a missing field, zero records, a failed query, and a valid query with no matching events.
Open the raw Azure portal Activity log for the same test resource and look for corroborating evidence. Compare one non-secret identifier and the timeline.
Capture query results with the table headers visible.

PASS gate D2-01: Learner correctly identifies one real action, its timestamp, actor or actor identifier, resource, result, and scope. They can explain why a blank ResourceGroup field does not necessarily mean the record is invalid.

D2-L02 — Complete KQL essentials laboratory (real data)

Syllabus: F14–F15. Type: Live KQL. Outcome: Independently operate where, project, take, sort, count, summarize, and bin. Reference: [R12], [R10].

Execution rule: Run queries one at a time. First make sure the appropriate source workspace is in scope. Queries operate on your training records: exact row counts and actor names will vary and are not prescribed answer values.

Exercise K01 — Prove the table can be queried

AzureActivity
| take 10

Observe: A sample of records, provided the table exists and contains data in the selected time range. Check: Results are not a substitute for recording the workspace/time filter.

Exercise K02 — Count events in a 24-hour lookback

AzureActivity
| where TimeGenerated >= ago(24h)
| count

Observe: One numerical row. A count of zero is a valid query result and requires source/time investigation, not a syntax correction.

Exercise K03 — Project only investigation-relevant fields

AzureActivity
| where TimeGenerated >= ago(24h)
| project TimeGenerated, Caller, OperationNameValue,
          ActivityStatusValue, ResourceId
| take 30

Observe: Five columns (some values may be blank); explain why project improves readability.

Exercise K04 — Sort latest changes first

AzureActivity
| where TimeGenerated >= ago(24h)
| project TimeGenerated, OperationNameValue, ResourceId
| sort by TimeGenerated desc
| take 20

Observe: Descending UTC event times; most recent first.

Exercise K05 — Administrative events only

AzureActivity
| where TimeGenerated >= ago(24h)
| where CategoryValue =~ "Administrative"
| project TimeGenerated, CategoryValue, OperationNameValue,
          ActivityStatusValue
| sort by TimeGenerated desc

Observe: Only matching category values. =~ means case-insensitive equality for strings.

Exercise K06 — Filter specifically to your safe lab resource

let signalGroup = "rg-sentinel-signal-lab01";  // Replace with your actual name.
AzureActivity
| where TimeGenerated >= ago(48h)
| where ResourceId contains signalGroup or ResourceGroup contains signalGroup
| project TimeGenerated, OperationNameValue, ActivityStatusValue,
          ResourceGroup, ResourceId, CorrelationId
| sort by TimeGenerated desc

Observe: Records related to the unique lab RG. If empty: inspect the broad unfiltered table query first; the RG name could differ, the signal could be older, or the connector could be misconfigured.

Exercise K07 — Number of events per operation

AzureActivity
| where TimeGenerated >= ago(24h)
| summarize Events = count() by OperationNameValue
| sort by Events desc

Observe: One row per distinct operation and a count. Explain the difference between events and unique operations.

Exercise K08 — Number of operations by status

AzureActivity
| where TimeGenerated >= ago(24h)
| summarize Events = count() by ActivityStatusValue
| sort by Events desc

Observe: A status distribution; discuss why an operation can generate records in different states and why you should not label all failures as attacks.

Exercise K09 — Visualize basic activity over time

AzureActivity
| where TimeGenerated >= ago(24h)
| summarize Events = count() by bin(TimeGenerated, 1h)
| sort by TimeGenerated asc

Observe: Time-bucketed records. In a Logs editor that offers a chart view, choose an appropriate line/column visualization. If the chart isn’t available in the current editor, the returned table is still valid evidence.

Exercise K10 — Summarize unique actors (if present)

AzureActivity
| where TimeGenerated >= ago(24h)
| where isnotempty(Caller)
| summarize Events = count() by Caller
| sort by Events desc
| take 20

Observe: Top identified callers. Be cautious: a Caller may be a GUID or service principal, not necessarily a human username.

Exercise K11 — Find recent failed administrative operations

AzureActivity
| where TimeGenerated >= ago(48h)
| where CategoryValue =~ "Administrative"
| where ActivityStatusValue =~ "Failed"
| project TimeGenerated, OperationNameValue, Caller,
          ResourceId, ActivitySubstatusValue
| sort by TimeGenerated desc

Observe: A valid empty result is acceptable. Do not invent failed operations. Discuss least-privilege and operational causes versus threats.

Exercise K12 — Build a concise daily SOC summary

AzureActivity
| where TimeGenerated >= ago(7d)
| summarize Events = count(),
            LastObserved = max(TimeGenerated)
  by CategoryValue
| sort by Events desc

Observe: A compact category-level view; no table joins or advanced functions required.

Troubleshooting experiment (mandatory)

Change the K02 window from ago(24h) to ago(5m) and compare counts.
Change K06’s signalGroup to a deliberately wrong lab name. Observe zero results.
Restore the right name and a sufficiently broad time range. Confirm that records return.
Explain in plain English why the first empty result is not an ingestion failure.
Save your best five queries as plain .kql or .txt files, along with the observed record counts and UTC execution times.

PASS gate D2-02: Learner executes K02, K03, K05, K07 and K09 successfully, explains the pipeline table | filter | project/summarize | sort, and diagnoses the intentionally empty KQL filter. Extra credit: all K01–K12.

D2-L03 — Synthetic KQL laboratory (when no real data is permitted)

Syllabus: F14. Type: SIMULATED only, not a replacement for ingestion/incident pass gates.

Exercise S01 — Seed fictional table rows in the query engine

Paste the complete query below into an environment that supports Kusto datatable:

// SIMULATION: Rows exist only during this query; nothing is ingested.
datatable(Actor:string, Action:string, Result:string)
[
    "admin1@aster.example", "CreateResourceGroup", "Succeeded",
    "admin2@aster.example", "UpdateTags", "Succeeded",
    "admin3@aster.example", "DeleteResourceGroup", "Failed",
    "admin1@aster.example", "UpdateTags", "Succeeded"
]
| extend TimeGenerated = ago(5m)
| project TimeGenerated, Actor, Action, Result

Expected: Four fictional rows; all timestamps are relative to the query run. They represent no real Azure operation, cannot be queried in AzureActivity, and cannot by themselves produce a genuine Sentinel analytic-rule alert.

Exercise S02 — Summarize the same fictional events

let LabEvents = datatable(Actor:string, Action:string, Result:string)
[
    "admin1@aster.example", "CreateResourceGroup", "Succeeded",
    "admin2@aster.example", "UpdateTags", "Succeeded",
    "admin3@aster.example", "DeleteResourceGroup", "Failed",
    "admin1@aster.example", "UpdateTags", "Succeeded"
];
LabEvents
| where Result =~ "Succeeded"
| summarize Events = count() by Actor
| sort by Events desc

Expected: admin1@aster.example → 2 and admin2@aster.example → 1. The failed record is excluded. Do not import fictional @aster.example accounts into a real watchlist, Entra ID or production workspace.

Exercise S03 — Brief written interpretation

Why did the count decrease from four total records to three successful ones?
Why is this exercise not proof that a data connector works?
What missing evidence would be required before recording the Day 1 ingestion gate as PASS?
Why must you not call these fictional records a confirmed security incident?

SIMULATED gate D2-03: Learner gets expected S02 counts and labels the output as SIMULATED — NO AZURE INGESTION, NO INCIDENT.

D2-L04 — Explore built-in content and deploy a starter rule template

Syllabus: F16, F17. Type: Live content/rule exercise. Prerequisites: Azure Activity solution installed; Sentinel Contributor at required scope; inspect source data. DOC-VERIFIED: [R01], [R08], [R14].

First: understand installed content versus active detection

Object	What exists after installation?	What must you still do?
Content Hub solution	Package of content definitions	Review requirements and configure included components
Data connector	Integration instructions/connector instance	Authorize export/connection and verify telemetry
Analytics rule template	Reusable starting query/settings	Create and enable an active rule, with available data sources
Active scheduled rule	Scheduled analytic evaluation	Wait for matching data and execution; verify alert/incident
Workbook template	Reusable dashboard definition	Satisfy data-source prerequisites and open or save it

Step A — locate a Microsoft-documented starter example

In Defender portal, expand Microsoft Sentinel → Content management → Content hub.
Locate the installed Azure Activity solution. Expand it and inspect the available detection content.
Find Suspicious Resource deployment, which is named in the official onboarding quickstart as an example rule template. [R01]
Verify this rule’s required data sources are available. The Defender Analytics → Rule templates view also shows prerequisite availability; if it reports missing data, investigate before enabling.
Read the rule’s name, description, KQL, scheduling window, result threshold, and severity. Ask: What exact activity would match this rule?
Explain why the lab’s harmless UpdateTags action might not match a suspicious resource-deployment template. Do not promise that enabling it will create a test incident.

Step B — create the rule from its template (only in isolated lab)

Open Microsoft Sentinel → Configuration → Analytics.
Select the Rule templates tab, filter to Scheduled if useful.
Find the intended template (for example Suspicious Resource deployment) and inspect source compatibility.
Select Create rule. If disabled, stop and record the exact missing prerequisite; do not blindly install unrelated connectors or licenses.
The wizard loads the template defaults. On General, set the enabled state appropriate to your instructor’s safe lab; leave the severity and query intact unless specifically approved.
On Set rule logic, verify query syntax, workspace tables, scheduling, Results simulation (if available), and match conditions. A simulated result graph is not an actual alert.
On Incident settings, confirm Create incidents from alerts triggered by this analytics rule remains enabled when the intent is end-to-end detection. Defender’s incident correlation may later group alerts differently than a simple “one alert equals one incident” assumption. [R15]
On Automated responses, do not add playbooks, disruptive actions, or incident-wide automation for this foundation exercise.
Select Review and create; confirm Validation passed, then Create.
Return to Analytics → Active rules. Find the new active rule, record name, status, source template, run interval/lookback, and creator.

Step C — check and document actual behavior

Check Microsoft Sentinel → Configuration → Analytics → Active rules to verify the rule exists and is enabled.
Search the appropriate Incidents & alerts queue for activity associated with that rule over the allowed lab window.
If zero alerts appear, explain whether the template query returned no matching events, is waiting for its scheduled run, has source prerequisites missing, or generated an alert correlated into an existing incident.
Save a copy or screenshot of the rule query and the observed results. Record ACTIVE RULE = YES separately from ACTUAL ALERT OBSERVED = YES/NO.
Keep the template only if required by the next step; otherwise disable the lab instance at the end of the exercise to avoid background monitoring in a shared workspace.

PASS gate D2-04: Learner demonstrates the template’s existence, prerequisites, configured active scheduled rule, and validation status. An incident is not assumed. If this template cannot be created due to tenant content/source restrictions, document the blocker and move to D2-L05 with instructor approval.

D2-L05 — Prove event → rule → alert → incident using an approved controlled rule

Syllabus: F17–F18. Type: Fallback end-to-end demonstration only if needed. Prerequisites: Actual AzureActivity records, approved instructor, Sentinel Contributor. DOC-VERIFIED: [R15].

Security intent: This short-lived beginner rule detects your uniquely named training resource group, not suspicious enterprise behavior. It deliberately has low severity and is disabled/deleted after use. It is not a production security detection and is not an invitation to develop attack simulation playbooks.

Phase 1 — prove the query can find only your approved lab activity

Have the instructor confirm the signal RG name is unique, under the training subscription, and safely modifiable.
From Azure portal, add or update a benign tag on rg-sentinel-signal-lab01 (for example exercise=D2-L05). This refreshes a legitimate, low-risk Azure Activity record.
Check source Activity log to confirm the tag/update action exists. If the tag change produces no relevant AzureActivity record yet, wait for export and verify the destination first.
Run this KQL in the real Sentinel workspace, replacing both placeholders. Do not run with placeholders left intact:

let labRG = "rg-sentinel-signal-lab01"; // Replace with actual signal RG.
let labSubscription = "00000000-0000-0000-0000-000000000000"; // Replace.
AzureActivity
| where TimeGenerated >= ago(2h)
| where SubscriptionId =~ labSubscription
| where CategoryValue =~ "Administrative"
| where ResourceId contains labRG or ResourceGroup contains labRG
| project TimeGenerated, Caller, ResourceId, ResourceGroup,
          OperationNameValue, ActivityStatusValue, CorrelationId
| sort by TimeGenerated desc

Confirm at least one row, matching your approved subscription/RG. If zero rows, stop and repair source/connector/time filters first. A rule that can never match cannot prove alert generation.
Save the query as D2-L05-Lab-Rule-Query.kql and evidence of at least one real matched row.

Phase 2 — create the temporary scheduled rule

In the Defender portal open Microsoft Sentinel → Configuration → Analytics → + Create → Scheduled query rule.
Enter Name: LAB01 - Approved Azure Activity Test (use your unique ID). Add a description such as TRAINING ONLY. Detects approved tag or group changes on lab RG; disable after assessment.
Set Severity = Low or Informational as the instructor approves. Leave threat-technique mapping unset if the activity does not truthfully represent a MITRE ATT&CK technique.
Set Status = Enabled and start automatically, unless the instructor wants the learner to enable it only after a final review.
In Set rule logic, paste the tested KQL. Retain TimeGenerated in its output; Microsoft’s scheduled-rule documentation specifically requires it for lookback evaluation. [R15]
Under Query scheduling, use Run query every = 5 minutes and Lookup data from the last = 2 hours, a valid documented interval/lookback pair. These values are a practical lab configuration, not a recommended production default.
Under Alert threshold, choose Number of query results is greater than 0, so a real matching row can produce an alert.
Under Event grouping, choose Group all events into a single alert for the initial demonstration.
Under the option for stopping the query after an alert is generated, enable a finite suppression period (for example 1 hour) if supported; this limits a flood of repeated classroom alerts. If that option is unavailable, disable the rule promptly after first alert evidence, and monitor for duplicates.
Select Test with current data / Results simulation when present. Expected: A matching period is indicated if the recent test event fits the scheduling settings; this is still not a production alert.
Under Incident settings, leave Create incidents from alerts enabled. Microsoft documents that Defender XDR processes incident creation/correlation for onboarded workspaces, even if the rule was authored in Sentinel. [R15]
Under Automated responses, choose none. Do not add notifications to real business teams or remediation actions.
Review the complete configuration, check Validation passed, and select Create.
Return to Active rules and verify the temporary rule is enabled and query/scope match the approved lab.

Phase 3 — verify the real output (do not stop at a saved rule)

In Defender portal open Investigation & response → Incidents & alerts → Alerts (navigation may be reorganized in the current unified interface).
Filter by a recent time range and the lab rule name. Allow enough time for scheduled execution, ingestion, and Defender correlation; there is no guarantee of an instant alert.
Record Alert name/ID, rule name, created time, severity, resource or evidence, and source. Screenshot D2-L05-Alert.png.
Next open Incidents & alerts → Incidents, or Cases → Incident if your Defender tenant uses the incident-cases preview. Locate the incident containing the alert.
Record Incident/case ID, status, related alert count, associated activity time, and owner if set. Screenshot D2-L05-Incident.png.
Compare the alert evidence back to the AzureActivity event (same subscription/resource/operation/approximate time).
If an alert appears but no new incident row, check if it was correlated into an existing incident, the incident-creation setting, permission/filter scope, and Defender processing before concluding “broken”. The documented Defender engine may group alerts differently than the scheduled rule’s initial settings. [R15]
After obtaining evidence, disable the temporary rule immediately or have the instructor disable it; verify the disabled state. Keep the incident/case available for D2-L06 and delete the rule during final cleanup.

PASS gate D2-05 — must have the complete evidence chain

Boundary	Evidence	Actual result
Approved Azure event	Source Activity log / signal RG change	PASS / BLOCKED
Ingested destination record	`AzureActivity` query result in intended workspace	PASS / BLOCKED
Query matches data	`D2-L05-Lab-Rule-Query.kql` returns ≥1 row	PASS / BLOCKED
Active rule	Rule saved, then enabled/runs	PASS / BLOCKED
Actual alert	Alert ID from the controlled rule	PASS / BLOCKED
Actual incident/case	Incident ID containing the alert	PASS / BLOCKED
Noise prevention	Lab rule disabled/suppressed after test	PASS / BLOCKED

Critical: A SIMULATED KQL result or a “test with current data” preview does not satisfy the actual-alert or actual-incident gates. If the portal hasn’t produced the real alert/incident, mark those steps BLOCKED and document the cause/last observed boundary.

D2-L06 — First-line SOC triage: classify, document, escalate

Syllabus: F18, F19, F20, F22. Type: Real training alert incident; learner may be Responder or instructor-managed. DOC-VERIFIED: [R13], [R16], [R17].

Part A — identify which incident UI your tenant actually uses

Path A: Current documented standard/legacy Defender incident queue

Open Investigation & response → Incidents & alerts → Incidents in Defender portal.
Filter for the approved lab rule, the appropriate workspace/source, and recent creation time.
Open the incident and look for the Summary/overview, Alerts, Evidence/entities, Activity/Comments, and any available attack story or timeline.
Use Manage incident or the management pane to set a training owner, appropriate status, and notes (if the learner has permission).

Path B: Newer incident-cases preview (where enabled)

Open Cases → Incident in Defender portal.
Select the incident case and check Summary, Attack graph, and Artifacts → Alerts / Assets / Evidence / Activities as available.
To manage case fields, select the three-dot menu → Manage case (or the available Manage case control).
Verify the learner has appropriate Defender unified RBAC Security Data Read to view or Security Data Manage to update case information. [R16], [R17]

Important: As of this edition, Microsoft identifies incident cases as a preview and maintains a legacy incident experience. Do not treat an unavailable preview menu as a learner failure; use the supported incident interface actually provisioned. [R16]

Part B — perform the evidence-based triage

Record incident or case ID, creation time, severity, status, owner, associated alerts, and detection source.
Read the alert’s detection description before taking action. Ask: “What condition did the analytic rule actually test?”
Inspect the known ResourceId, OperationNameValue, ActivityStatusValue, Caller, and TimeGenerated. If the alert view omits fields, use a saved workspace query from D2-L05.
Confirm that the resource belongs to the preapproved lab subscription and lab signal group.
Compare the timestamps: known trainee action, source Activity log record, AzureActivity record, alert, and incident. Account for processing delays.
Review available entity or evidence panes, but do not invent user, IP, device, or UEBA signals if they are not present or licensed in the tenant.
Test two alternate hypotheses: (H1) expected lab action correctly detected; (H2) activity outside the lab or unapproved scope. State what source evidence would distinguish them.
Decide risk level and disposition based on evidence; do not mark the activity malicious merely because an alert exists.
In a writable lab case, set an approved status such as In progress while analyzing. Assign to yourself or the instructor as permitted.
Add a short evidence-based comment: TRAINING EVENT — lab rule [name] matched approved RG [name], action [operation], UTC [time]; no disruptive response taken.
Resolve/close the training case using the actual classification/determination choices supported in your portal. For an authorized test that behaved as designed, an expected activity/security testing outcome (where offered) is generally more faithful than “malicious attack”. Discuss options with the instructor if different portal choices are available.
Note where a case update and related incident/alert status are or are not synchronized; avoid assuming that closing the case automatically closes each underlying alert in every preview flow. [R17]
Save the incident record, its query evidence, and the final disposition in the evidence folder.

Incident report template — fill this completely

# Aster Retail — Approved Training Incident

- Exercise: D2-L06
- Incident/case ID:
- Analytics rule name / ID:
- Azure training subscription / resource identifier:
- Initial alert UTC time:
- Relevant event UTC time:
- Severity / status / assigned owner:
- Alert(s) associated:
- Evidence examined (query filenames, fields, screenshots):
- Observed action and actor identifier:
- Why this looked interesting to a detection rule:
- Alternate benign explanation:
- Conclusion (evidence-based, avoid unsupported claims):
- Classification / determination selected in portal:
- Actions performed (training-only; no remediation):
- Escalation required? To whom and why?:
- Follow-up / rule improvement suggestion:
- Final status / reviewer / UTC timestamp:

Escalation decision matrix

Situation	Learner action	Who reviews?
Approved signal group and action match planned lab	Document and close as expected security testing	Instructor / SOC lead
Different subscription, unexpected account, or non-lab target	Stop remediation; preserve facts, escalate for verification	Instructor + authorized SOC lead
Query missing evidence or timestamps inconsistent	Leave investigation open; collect source/destination proof	SOC L2 or connector owner
Scope/permissions preventing incident updates	Do not elevate yourself; request authorized owner	Admin / incident manager
Actual signs of account misuse outside the exercise	Follow real security incident policy, not training steps	Organization’s real security team

PASS gate D2-06: Incident record is complete, evidence directly supports the conclusion, appropriate status/owner/disposition are recorded, and the learner can explain at least one alternative hypothesis. If a learner cannot change status because of role boundaries, the instructor performs the action and records OBSERVED (role restricted); do not make unsupported changes.

D2-L07 — Read and interpret a built-in Microsoft Sentinel workbook

Syllabus: F21. Type: Consume existing visualizations; not an advanced custom-workbook lesson. DOC-VERIFIED: [R18].

Prerequisites

A workbook template installed through Content hub, or an instructor-provided saved workbook with a data source supported by your lab.
Sufficient workbook read permission; access to the specific Log Analytics workspace table used by the workbook.
A plan for empty visualizations: not all template workbooks accept AzureActivity; some require other connectors. Do not assume the installed Azure Activity solution provides a usable workbook for every environment.

Guided steps

In Defender portal expand Microsoft Sentinel → Threat management → Workbooks.
Select Templates to view installed workbook templates.
Open a workbook whose required data types are actually present in the training workspace. If none qualifies, use an instructor-provided saved workbook and record that source. Do not install unrelated enterprise connectors solely to populate a dashboard.
Read its description, named data dependencies, workspaces and purpose before opening it.
If the instructor has authorized saving an instance, select Save, choose the training subscription/RG location, then View saved workbook. Otherwise open the instructor-provided workbook read-only.
Locate and record the time-range filter. Compare a narrow range and a wider range, keeping the same source scope.
Locate the chart/table most relevant to the lab (for example, administrative operations by time or status if available).
Identify one chart axis, one filter, one number, and one actionable SOC question answered by the visualization.
If the view is empty, inspect whether the required tables exist and time filters include matching data. A working template with no source data is not a platform failure.
If the Defender portal displays a feature that requires Open in Azure, follow the permitted view workflow only; do not switch the core course experience to the legacy Azure Sentinel interface. [R18]
Save or screenshot the supported visualization, with time range and workspace displayed. File: D2-L07-Workbook-Interpretation.png.

Interpretation questions — learner writes answers

What population of records and what time range are shown?
Does the chart show events, unique users/resources, alerts, or incidents? Explain.
What could make a chart show zero events even when ingestion works?
What follow-up KQL query would you run if the chart shows a sudden spike?
Can a dashboard alone prove that a resource action was malicious? Why not?

PASS gate D2-07: Workbook of a compatible type was opened; learner accurately interprets one visual, its scope and filters, and states one query-driven investigative follow-up. If no compatible workbook exists, record BLOCKED — missing supported template/source rather than inventing workbook data.

D2-L08 — Entry-level SOC operational SOP and guided troubleshooting

Syllabus: F22–F23. Type: Diagnostic workshop. Deliverable: Day02/D2-L08-Troubleshooting-Worksheet.md.

Reusable L1 SOC checklist (start with observation, never remediation)

Confirm the incident ID, created UTC time, source detection, severity and current owner.
Validate the detection has a real triggering alert, not merely an enabled rule.
Check workspace/source and that query time range includes the signal.
Verify event details, relevant entities, and any linked alerts.
Check whether the incident represents planned training, expected activity, a false alarm, or possible real threat.
Identify the one next question that would most reduce uncertainty, plus the KQL/source needed to answer it.
Add factual case notes and a secure evidence link, avoiding secrets or unrelated PII.
Escalate to the correct role or close only within allowed permissions and documented process.
Review whether the rule/template data prerequisites and signal quality are sufficient.
Confirm lab rule suppression/disablement at the end of the exercise.

Troubleshooting Challenge T01 — Table error / missing data

Instructor injects: Learner queries AzureActivity in a workspace with no Activity export, or selects the wrong workspace.
Symptoms: Table may be missing, query returns zero rows, or access is denied.
Student action: Confirm tenant/workspace scope → inspect broad table query → inspect Azure Activity export and source → distinguish missing table / no data / no permission.
Evidence: Screenshot/command showing the first point where expected state fails.

Troubleshooting Challenge T02 — Overly narrow time filter

Instructor injects: Recent event exists, but query uses ago(1m) or UI filter excludes it.
Student action: Compare source UTC time → expand query window → remove conflicting filters → rerun.
Correct finding: Query was valid; lookback did not cover available telemetry.

Troubleshooting Challenge T03 — Analytic rule enabled, no alert

Instructor injects: Template is active, but its KQL has no matching rows for a benign tag update.
Student action: Verify required source tables → run rule KQL with current source → inspect schedule/threshold → explain mismatch; if approved, use controlled D2-L05 fallback.
Correct finding: “Enabled” is not equal to “triggered”.

Troubleshooting Challenge T04 — Alert present, incident not found

Instructor injects: Alert visible, but the analyst’s time filter/workspace selection differs; or Defender correlates into an existing incident.
Student action: Find alert ID and linked incident; examine rule incident settings; search both current Incidents and Cases → Incident if applicable; check permission and creation delay.
Correct finding: Confirm whether correlation, UI scope or timing explains the missing new row.

Troubleshooting Challenge T05 — Workbook has no charts

Instructor injects: Selected workbook depends on a table absent in the training workspace.
Student action: Check Required data types and actual workspace tables; switch to a supported template / provided workbook.
Correct finding: Lack of required data is different from workbook corruption.

Troubleshooting Challenge T06 — Unauthorized action blocked

Instructor injects: Reader tries to install a solution or edit an incident.
Student action: Identify the actual task → map it to a role and scope → request the minimum authorized grant or instructor action.
Correct finding: Reader can inspect some resources but not create rules or manage incidents.

General diagnostic decision tree

NoYesNoYesNoYesNoYesNoYesNoYesExpected result absentSource event exists?Check Azure Activity scope, action, UTC filterExport configured to right workspace?Check Policy/diagnostic destination and approvalAzureActivity query returns signal?Check delay, permissions, workspace, table, KQL filtersRule query returns matches?Check template prerequisites, window, predicatesActual alert created?Check enabled state, schedule, threshold, suppressionIncident/case contains alert?Check correlation, incident settings, portal filtersReview evidence, document, classify, close/escalate

PASS gate D2-08: Each learner correctly diagnoses four distinct failure classes from source, export, KQL, rule, incident or workbook, and identifies a non-disruptive next step. Correctly stopping and escalating is acceptable when privileges or environment controls block action.

D2-L09 — Final Foundations capstone: from a change to a documented incident

Syllabus: Entire Foundations range F01–F23. Type: Supervised applied assessment. No hourly schedule.
Prerequisites: Day 1 architecture/readiness evidence, at least one relevant source signal, query permissions, and instructor-approved detection. Deliverable: Assessment/<Learner-ID>-Foundations-Capstone.md plus evidence.

Practical scenario

The training cloud administrator announces an approved change in the unique Aster Retail signal RG. Your task is to prove the change occurred, determine whether Sentinel observed it, ensure an authorized rule evaluated relevant data, and record the resulting incident according to the SOC checklist. The activity is expected security testing, not an attack.

Assessment execution steps

Write What, Why, Who, When, Where, How for this event-to-incident exercise in no more than six short lines.
Submit or point to the architecture diagram; identify the exact data source, connector method, Sentinel workspace and Defender experience.
Show the approved subscription, workspace, and least privilege separation; do not expose private account details in exported evidence.
Capture the Azure portal source Activity log evidence for the instructor’s designated benign change.
Write and execute a KQL query identifying the same action in AzureActivity, with at least one scope filter and a sensible time range.
Write a KQL summary grouped by operation or status and explain what its rows represent.
Show the enabled starter template rule and explain its source prerequisites and why it might or might not fire for this action.
If necessary and expressly approved, demonstrate D2-L05’s limited lab rule. Show real rule, real matching query, actual alert, and incident/case ID. Disable lab rule as soon as this evidence is captured.
Investigate the incident: identify owner, severity, linked alert, relevant resource, timeline, and evidence; describe at least one alternative benign explanation.
Record the correct disposition: approved security testing/expected lab event. Choose available portal classification/determination values faithfully; do not misclassify harmless activity as a real compromise.
Open a compatible built-in workbook and explain its scope, time filter, and one chart or table.
Diagnose one injected negative test: wrong workspace, wrong filter, missing prerequisite, no alert, or insufficient role.
Submit the completed report and cleanup acknowledgment. Instructor evaluates the actual evidence, not simply attendance.

Objective assessment rubric — 100 points

Criterion	Points	Observable pass evidence
5W1H, SOC roles, SIEM/XDR comparisons, architecture	15	Correct definitions and arrows; ownership boundaries
Tenant/role/cost readiness and safe workspace/Sentinel onboarding	15	Correct workspace, region, RG and Defender association; approvals
Authorized Azure Activity source/export/ingestion	20	Match between real source event and `AzureActivity` record
Basic KQL and data interpretation	20	Correct `where`/`project`/`sort`/`summarize`/`bin`, timestamps, counts
Template content and real detection validation	10	Installed solution, active template, prerequisite explanation; real alert if available
Incident triage and case record	10	Alert/incident link, facts, hypotheses, correct disposition
Workbook interpretation	5	Actual relevant visualization and filter explanation
Troubleshooting, safe actions, cleanup	5	Diagnoses root cause, disables lab rule, records owner
TOTAL	100

Suggested academic threshold: 80/100, plus mandatory critical-skill gates below. This passing score is a training recommendation, not a Microsoft certification policy.

Mandatory critical-skill gates

G1 — Access & safe scope: Learner knows which subscription/workspace is in use and respects role/approval limits.
G2 — Genuine ingestion (or instructor-attested shared environment): A real Azure Activity event is linked to a real AzureActivity workspace record. Offline datatable cannot replace this.
G3 — Query competency: Learner independently executes the required KQL operators and can explain empty results.
G4 — Detection/incident workflow: Either a real lab alert and related incident are demonstrated, or an explicit, signed environment blocker is documented and a controlled supervised remediation/retest is scheduled.
G5 — Investigation discipline: Correct evidence-based disposition and no unauthorized remediation.

Decision: PASS / PASS-WITH-APPROVED-OBSERVED-SETUP / REMEDIATION-REQUIRED / BLOCKED-BY-ENVIRONMENT. Do not issue an unconditional live-lab PASS when the connector, alert, or incident has never been observed. Learners should remediate and reattempt missed mandatory gates before being marked fully eligible for Day 3 Intermediate.

Instructor answer key — check outcomes, not fixed row counts

Workspaces: Azure Log Analytics workspace holds relevant tables; Sentinel is enabled on that workspace; Defender provides the primary operations experience.
Source: Azure Activity tracks Azure control-plane actions; the approved diagnostic pipeline sends events to the intended workspace.
Query: Count may vary. A correct query returns a matching ResourceId or ResourceGroup, reasonable UTC time, and action/status fields.
Template: An installed template is not yet an active rule, and an active rule is not proof an alert fired.
Testing: A scheduled-rule result preview is not an actual alert. A real alert carries a record/ID and appears in the Alerts queue.
Incident: Defender may correlate multiple alerts into an incident; a missing new row is not proof that no incident exists.
Disposition: This scenario is preapproved lab activity, so justify an expected/security-testing classification where available.
Workbook: A workbook visual reflects data source/time filters; it does not independently establish maliciousness.
Permissions: Least privilege and scoped elevation through instructor/admin, not blanket Owner access.
Cleanup: Rule is disabled/deleted, signal RG is removed when approved, data connector/policy and workspace lifecycle are recorded.

3. Safe lab closure — END-L01

Purpose: Ensure the exercise does not leave alert storms, orphaned billable telemetry, unwanted Azure Policy assignments, unused workspaces or sensitive evidence. Only the instructor/cloud owner performs deletion or offboarding. [R19], [R20], [R21].

Step 1 — stop active classroom detection

In Defender portal open Microsoft Sentinel → Configuration → Analytics → Active rules.
Filter by the exact lab ID/name, such as LAB01 - Approved Azure Activity Test.
Confirm the exact rule belongs to your training workspace and was created for the class.
Disable it and verify its status. If authorized and the retention policy allows, delete the temporary lab rule; capture the deletion confirmation.
Review the rule created from Suspicious Resource deployment. If it was installed only for this class and is not used by anyone else, disable/remove it as the instructor approves; do not touch a shared enterprise active rule.
Search for unexpected additional training rules and confirm none remain enabled. Record that the last query-run/alert test is complete.

Step 2 — close the training incident properly

Open the relevant Incidents queue or Cases → Incident view for the tenant.
Confirm the lab event disposition and the case/incident closure status.
Leave a last comment containing the training rule ID and the statement TRAINING ONLY; no production remediation authorized.
Record incident/case IDs for assessment, but follow the institution’s retention and redaction rules for exported evidence.
Never bulk-close unrelated incidents in a shared tenant.

Step 3 — clean up the benign signal resource group

In Azure portal open Resource groups → [your unique signal group].
Review all contained resources. It should be empty or contain only instructor-approved disposable lab resources.
If it contains anything unexpected, STOP and ask the subscription owner; do not delete.
If verified empty/disposable, use Delete resource group, type the exact name when prompted, and confirm only under the authorized cleanup plan.
Confirm the group is absent from the active RG list and record cleanup evidence. Note that its prior Azure Activity events may remain in logs for the configured retention period.

Step 4 — remove lab-created export / Policy only when exclusive to the lab

Use the instructor’s configuration inventory from D1-L07: export method, diagnostic setting name or policy assignment, scope, destination, owner and creation time.
If using a unique lab-only diagnostic setting, ask the subscription owner to remove that setting in Monitor → Activity log → Export Activity Logs after checking that no other process relies on it.
If using a unique lab-only Azure Policy assignment, ask the policy owner to verify the assignment and any created diagnostic settings/remediation resources before removing them. Removing a policy assignment may not automatically remove every diagnostic setting it created. Verify the final state separately.
If the export predates the class, is shared, or is enterprise-mandated, leave it in place and document “pre-existing; retained by owner.”
Recheck that the affected subscription is not unintentionally exporting duplicate data to the training workspace.

Step 5 — decide what happens to Sentinel and the Log Analytics workspace

In the instructor inventory, mark workspace as keep for the five-day program, keep for later approved reuse, or dispose.
If Days 3–5 will reuse the workspace, do not delete or offboard it simply because Day 2 ended.
If the workspace is dedicated to the class and must be removed, review the documented Remove Microsoft Sentinel process and implications before doing so. Removing Sentinel may delete Sentinel-specific data connector configurations and tables and can take time; it is not the same operation as deleting a resource group. [R19], [R20]
If deleting an unneeded Log Analytics workspace, the owner must understand its soft-delete/recovery behavior and downstream effects. Microsoft documents a soft-delete recovery window and potential permanent loss of linked solution configurations. Never force permanent deletion as part of a learner exercise. [R21]
Confirm with the cost owner that no new lab-only connector/workspace resource is left without documented ownership and billing review.

Step 6 — submit final signed cleanup record

Instructor:                             __________________
Subscription / tenant reviewed:         __________________
Training alert rule disabled/deleted:   Yes / No / Retained by owner
Template rule disabled/deleted:         Yes / No / Pre-existing
Training incident disposition complete: Yes / No
Signal RG deleted or retained:          __________________
Activity export retained/removed:       __________________
Policy assignment retained/removed:     __________________
Sentinel workspace retained/removed:    __________________
Cost owner informed:                    Yes / No
Evidence archived under policy:        __________________
Cleanup UTC timestamp:                 __________________
Reviewer approval:                     __________________

PASS gate END-01: Nothing lab-only remains enabled without a named owner. STOP on any ambiguity about deleting a shared RG, policy assignment, workspace, data connector or incident.

4. Extended troubleshooting reference — symptom → check → safe resolution

This table is designed for live classroom diagnosis. Error text, portal wording, and feature availability depend on tenant configuration. Always capture the actual error message.

#	Symptom	Most useful verification	Safe next step / expected diagnosis
1	Wrong Azure directory or tenant	Account selector + subscription tenant	Switch to authorized tenant; repeat access check
2	Subscription invisible	Subscriptions page / current directory	Ask identity admin for scoped access; no account guessing
3	RG/workspace create button disabled	IAM at resource scope, Azure Policy denial	Contact provisioner/policy owner
4	Workspace creation returns a policy error	Deployment details show deny policy assignment	Use approved region/parameters, or ask policy owner
5	Workspace not listed when adding Sentinel	Name/region/type/subscription and current role	Verify supported workspace type and effective permissions
6	Sentinel appears in Azure, not Defender	Sentinel Workspaces settings in Defender	Confirm onboarding/admin rights; allow initial provisioning
7	Azure Activity solution not in Content hub	Search filters, content status, tenant	Clear filters; select supported content; log blocker
8	Content Hub install denied	Sentinel Contributor at correct RG	Instructor/admin performs install; do not grant broad Owner
9	Azure Activity connector shows disconnected	Diagnostic export or policy assignment existence	Inspect actual approved scope/destination; check delays
10	Cannot assign Azure Policy	Owner at policy assignment scope	Authorized policy owner executes assignment
11	Activity log visible, `AzureActivity` absent	Export config / status / correct workspace	Repair pipeline, not KQL syntax
12	Activity log contains event but KQL no match	Query time range and `ResourceId`/`ResourceGroup`	Broaden scope/time, use case-insensitive comparison
13	`AzureActivity` table unknown	Confirm Log Analytics workspace has connector data	Inspect table/permission; no invented data
14	“Forbidden” on query	Actual workspace query/read permissions	Grant only minimum required access after admin review
15	Wrong `Caller` identity interpretation	Real field value and claims context	Treat GUID/SPN as identity identifier, not always a human
16	Query `where` filter gives zero	Run unfiltered query and compare field values	Fix predicate, casing or lookback
17	Chart is empty despite query success	Query aggregation and selected time range	Use `summarize ... by bin(TimeGenerated, 1h)` on numeric result
18	Template Create rule disabled	Template required data source status	Enable approved source or use permitted alternative
19	Template enabled but no alert	Query matches, schedule, threshold, suppression	Explain no matching behavior; do not fake alert
20	Rule query rejected	Test KQL, required `TimeGenerated`, output schema	Correct query and pass wizard validation
21	Alert storm in classroom	Rule filters too broad; repeated matching window	Disable lab rule, narrow unique RG scope; suppress when available
22	Alert exists but no new incident	Alert’s related incident link and Defender grouping	Check existing correlated incident and incident settings
23	Analyst cannot update incident	Sentinel Responder/Contributor; Defender RBAC for cases	Ask authorized SOC role owner; don’t elevate self
24	Incident/case menu not available	Preview entitlement vs standard Defender incident view	Use supported incident queue; document UI branch
25	Workbook displays blanks	Required tables, query scope, workbook filters	Use compatible template or instructor-provided workbook
26	Workbook save denied	Workbook Contributor / RG permission	Use read-only template or ask authorized editor
27	Source data delay	Event time vs `EventSubmissionTimestamp`; export timing	Recheck, record actual latency; no fixed SLA assumed
28	Unexpected duplicate Azure Activity rows	Subscription vs management group exports	Review diagnostic export topology; investigate overlap
29	Costs still accruing after class	Active workspace/connector/retention and Cost Management	Verify retained owner or approved offboarding/cleanup
30	“No access” after workspace deletion	Workspace may have been soft-deleted or changed	Stop; check Azure Monitor documented recovery route

Root-cause worksheet

# Lab Troubleshooting Record

- Symptom as observed:
- Exact error code/text (if any):
- Current portal and selected tenant/subscription/workspace:
- First failing boundary: SOURCE / EXPORT / INGESTION / QUERY / RULE / ALERT / INCIDENT / WORKBOOK / RBAC
- What was expected:
- What was actually observed:
- Three hypotheses (ranked):
  1.
  2.
  3.
- Non-destructive tests performed:
- Evidence (links/filenames):
- Most likely root cause:
- Correct remediation owner and scope:
- Retest outcome: PASS / BLOCKED / PENDING

5. Optional Azure CLI verification (instructor or provisioner)

Optional, not required for the portal-based core course. Commands here are documented Azure CLI patterns; use an approved Azure Cloud Shell or preinstalled Azure CLI. Do not paste production credentials or run CLI delete commands from a learner laptop. A CLI success message does not prove the Sentinel connector is working: validate AzureActivity separately. [R22], [R23]

Verify the actual signed-in Azure context

az account show --output table
az account list --output table
# Replace with the training subscription ID, and re-check.
az account set --subscription "<TRAINING-SUBSCRIPTION-ID>"
az account show --query "{subscription:id, tenant:tenantId, name:name}" --output table

Read-only resource and workspace verification

az group show --name "rg-sentinel-foundations-lab01" --output table
az monitor log-analytics workspace show \
  --resource-group "rg-sentinel-foundations-lab01" \
  --workspace-name "law-sentinel-foundations-lab01" \
  --query "{name:name, id:id, location:location, provisioningState:provisioningState}" \
  --output json

Read subscription Activity Log events independently from workspace ingestion

# This queries the Azure control-plane Activity Log, NOT the Sentinel workspace.
az monitor activity-log list \
  --resource-group "rg-sentinel-signal-lab01" \
  --offset 24h \
  --output json

Interpret carefully: Azure Activity CLI/API filters and the workspace query target different points of the pipeline. For subscription-level activity, some RG-scope filters may miss events; check an appropriately scoped subscription Activity Log view if needed. Prefer the Azure portal source-versus-destination comparison in D1-L08 when teaching beginners.

Why no scripted bulk-provisioning or deletion in this Foundations guide?

A teaching environment differs from a controlled production deployment pipeline. Portal-guided provisioning makes learners explicitly inspect the tenant, scope, RBAC, export destination, cost, and consent. Infrastructure as Code, automated deployment and robust multi-environment cleanup belong to the Advanced module (Day 5). This is an intentional progression boundary, not a missing capability.

6. Instructor’s preflight, learner handoff, and evidence packaging

6.1 Instructor day-wise readiness matrix

Checklist	Before Day 1	Before Day 2
Approved Azure subscription and correct directory	Required	Recheck
Known workspace/RG/region and resource suffixes	Required	Verify unchanged
Engineer/provisioner/analyst access separation	Required	Required for rule/incident
Cost owner and cleanup plan	Required	Review again
Defender portal navigation	Check	Required
Azure Activity diagnostic export plan	Check and approve	Must function for live labs
At least one safe Azure Activity signal	Generated in D1-L08	Refresh as needed
Synthetic KQL fallback	Available	Available if live environment blocked
Built-in Azure Activity solution/template	Install/verify	Rule template visible
Controlled temporary-rule naming and suppression	Draft policy	Approve before creation
Incident-cases preview vs standard UI path	Discover	Select documented path
Compatible workbook present	Preselect	Required for workbook exercise
Assessment screenshots and redaction policy	Prepare	Collect
Rule/connector/workspace cleanup ownership	Assigned	Execute or document retention

6.2 Evidence-folder template

Microsoft-Sentinel-Foundations-Labs/
  Day01/
    D1-L01-SOC-Worksheet.md
    D1-L02-Architecture.md
    D1-L03-Environment-Readiness.md
    D1-L04-Workspace-Overview.png
    D1-L05-Sentinel-Enabled.png
    D1-L05-Defender-Workspace.png
    D1-L06-Content-Record.md
    D1-L07-Connector-Configuration.md
    D1-L08-Azure-Source-Activity.png
    D1-L08-Sentinel-AzureActivity-Result.png
  Day02/
    D2-L01-Record-Worksheet.md
    D2-L02-KQL-Queries.kql
    D2-L03-Simulation-Results.md
    D2-L04-Analytics-Template-Rule.png
    D2-L05-Lab-Rule-Query.kql
    D2-L05-Alert.png
    D2-L05-Incident.png
    D2-L06-Incident-Report.md
    D2-L07-Workbook-Interpretation.png
    D2-L08-Troubleshooting-Worksheet.md
  Assessment/
    LearnerID-Foundations-Capstone.md
    Grading-Sheet.md
  Cleanup/
    END-L01-Signed-Cleanup-Record.md

Note: This is an illustrative tree, not automatically generated files; the user requested one Markdown guide, which contains all the templates and instructions. If learner evidence includes sensitive tenant identifiers or security telemetry, use an approved private repository/document store, not a public file share.

6.3 Curriculum traceability — every Foundation topic accounted for

Topic ID	Exact syllabus topic	Where it is practiced/verified
F01	The security operations problem	D1-L01 event vs alert tabletop
F02	Fundamental security terminology	D1-L01 definitions and answer checks
F03	What Microsoft Sentinel provides	D1-L01 SIEM and product benefits/limits
F04	People and responsibilities	D1-L01 escalation chain; D1-L03 RBAC
F05	Where Sentinel fits and when to adopt it	D1-L01 5W1H and adoption scenarios
F06	Comparison with alternative approaches	D1-L01 SIEM vs EDR/XDR/log-only comparison
F07	Foundational platform architecture	D1-L02 source→ingestion→detection→incident diagram
F08	Azure resource dependencies	D1-L02/D1-L03 tenant/subscription/RG/workspace
F09	Prerequisites and deployment planning	Instructor checklist, D1-L03/L04, cost and cleanup
F10	Baseline access permissions	D1-L03 least-privilege, role matrix
F11	Initial workspace setup	D1-L04/L05 Log Analytics → Sentinel → Defender
F12	First data connection	D1-L06/L07/L08 Azure Activity with source/destination proof
F13	Understanding ingested security records	D2-L01 field/timestamp worksheet
F14	KQL essentials	D2-L02 K01–K12; D2-L03 synthetic alternative
F15	Basic log validation	D1-L08 ingestion checks; D2-L01/L02 queries
F16	Built-in security content	D2-L04 template/content roles and prerequisites
F17	Activate a starter analytic rule	D2-L04 Azure Activity template; D2-L05 controlled validation
F18	Detection-to-incident fundamentals	D2-L05 actual alert/incident chain
F19	Guided first-line triage	D2-L06 evidence/alternate hypothesis
F20	Basic disposition and escalation	D2-L06 classification and escalation matrix
F21	Consume an out-of-box workbook	D2-L07 compatible workbook interpretation
F22	Entry-level SOC operating procedure	D2-L06 SOP, D2-L08 checklist, final capstone
F23	Entry-level troubleshooting	D2-L08 T01–T06, extended table, root-cause record

6.4 What this course does not claim to do

It does not treat an offline datatable as proof of real Sentinel ingestion.
It does not guarantee a suspicious deployment template will fire on a safe tag update.
It does not require a Microsoft Defender XDR E5 license solely to connect Sentinel to the Defender portal.
It does not say all workspaces automatically appear to all users; Defender onboarding and role scope matter.
It does not claim all tenants have incident-cases preview enabled.
It does not assume a data connector’s Connected status proves every data record arrived.
It does not require dangerous remediation, production changes, or privilege escalation to pass.
It does not teach advanced AMA/DCR/CEF, multi-table detection correlation, UEBA enrichment, custom workbook design, SOAR playbooks, repository CI/CD or lake/enterprise architecture; those are later-module topics.

7. Official Microsoft documentation and verification log

Review date: 1 November 2026. Verification type: Documentation/technical-reference review using Microsoft Learn; no authenticated live tenant execution. Links below are primary sources and should be rechecked immediately before future instructor delivery. Where Microsoft changes navigation, use the referenced article’s Defender portal tab and record actual UI differences.

Ref	Official source	Guidance verified for this guide
R01	Onboard Microsoft Sentinel to a Log Analytics workspace	End-to-end quickstart, workspace, Content hub, Azure Activity connector, example Suspicious Resource deployment template, querying AzureActivity
R02	Prerequisites to deploy Microsoft Sentinel	Azure/tenant/workspace requirements and role planning
R03	Connect Microsoft Sentinel to the Microsoft Defender portal	Defender onboarding paths, automatic/manual connection, required roles, primary workspace, no Defender XDR license just to connect Sentinel
R04	Plan Microsoft Sentinel costs and billing	31-day / 10 GB/day Analytics-tier trial conditions, additional charge categories, pay-as-you-go
R05	Roles and permissions in Microsoft Sentinel	Reader/Responder/Contributor, Content hub, query/workbook permissions and least privilege
R06	Azure Activity Log overview and export	Subscription Activity logs, export to Log Analytics, AzureActivity table, source-vs-destination comparison, case-insensitive field values
R07	Microsoft Defender unified RBAC permission details	Defender permissions are distinct from Azure resource RBAC and can affect case management
R08	Discover and manage content from Microsoft Sentinel Content hub	Solution installation, templates vs active content, Contributor role
R09	Microsoft Sentinel diagnostic-setting-based data connectors	Azure Policy-based connector requirements and diagnostic setting alternative, legacy Azure Activity transition
R10	AzureActivity table schema	Field spelling and types: TimeGenerated, CategoryValue, ResourceId, ResourceGroup, Caller, OperationNameValue, ActivityStatusValue, CorrelationId
R11	Azure Activity Log export troubleshooting	Diagnostic export and non-instant data availability checks
R12	Log Analytics tutorial and Getting started with log queries	KQL query execution, time filters, display of data, common no-result troubleshooting
R13	Investigate incidents in Microsoft Defender (legacy)	Supported older incident workflow and evidence interpretation
R14	Create scheduled analytics rules from templates	Rule templates view, source prerequisite checks, activation workflow
R15	Create a scheduled analytics rule from scratch	`TimeGenerated`, allowed intervals, lookback, simulation, threshold, suppression, incident creation and Defender correlation caveats
R16	Investigate incident cases in Microsoft Defender	Preview case navigation, alerts/assets/evidence, preview access requirements
R17	Manage incident cases in Microsoft Defender	Case owner/status/classification/actions and sync behavior
R18	Visualize and monitor data using Microsoft Sentinel workbooks	Threat management → Workbooks, template source prerequisites, save/view process
R19	Remove Microsoft Sentinel from your workspace	Authorized offboarding process versus deleting workspace
R20	Implications of removing Microsoft Sentinel	Connector/table impacts and consequences of offboarding
R21	Delete and recover a Log Analytics workspace	Soft delete/recovery and safe deletion scope
R22	Azure CLI Log Analytics workspace reference	Read-only workspace show command
R23	Azure CLI account commands and Azure Activity Log Azure CLI examples	Verify Azure CLI identity and inspect activity independently

7.1 Verification gaps and delivery controls

Claim	Documentation verified?	Requires actual tenant test?	How to close the gap
Onboarding workspace from Azure portal	Yes, R01	Yes	D1-L04/L05 PASS with actual workspace screenshots
Defender manual/automatic connection	Yes, R03	Yes	D1-L05 workspace listed in tenant
Policy route and diagnostic export configuration	Yes, R01/R09	Yes	D1-L07 live export config and owner approval
`AzureActivity` table/fields	Yes, R10	Yes (data contents)	D1-L08 actual matching event
Beginner KQL operators	Yes, R12	Yes (environment and data)	D2-L02 query executions
`datatable` simulated syntax	Yes, Kusto-compatible operator pattern	Yes, if no Kusto service is accessible	D2-L03 outputs marked simulated
Starter analytics template	Yes, R01/R14	Yes (specific tenant/version)	D2-L04 template active and prerequisites satisfied
Actual alert and incident creation	Yes, R15 explains mechanism	Always	D2-L05 Alert ID and incident/case ID
Defender incident cases preview	Yes, R16/R17	Yes (preview scope)	Choose available Path A/Path B in D2-L06
Workbook availability	Yes, R18 explains mechanism	Yes (installed compatible template)	D2-L07 actual chart/filter evidence
Cleanup, billing, policy ownership	Yes, R19–R21 for product behavior	Always	END-L01 signed cleanup and subscription review

Final editorial check for instructors: Microsoft Sentinel and the Defender portal evolve quickly. Before repeating this class, reopen R01, R03, R08, R14–R18, verify the portal-selected paths, verify new pricing/trial terms, retest the lab signal in a disposable subscription, and update screenshots and gate expectations. An outdated icon is a cosmetic issue; a changed role prerequisite, missing connector or unsupported incident flow is a blocking lab issue.

8. Final instructor sign-off and progression decision

Course: Microsoft Sentinel — Foundations, Days 1 and 2
Edition: 1 November 2026
Learner/Group ID: __________________________________
Delivery model: A Full live / B Instructor-managed / C Simulation
Approved tenant/subscription: _______________________
Training workspace/region: __________________________
Day 1 labs completed: ______ / 8
Day 2 labs completed: ______ / 9
Real AzureActivity source→workspace matched: Yes / No
Real alert ID recorded: Yes / No / Blocked
Real incident/case ID recorded: Yes / No / Blocked
KQL competency passed: Yes / No
Incident disposition passed: Yes / No / Observed
Workbook interpretation passed: Yes / No / Blocked
Assessment score: ______ / 100
Mandatory gate result: ______________________________
Incomplete live steps and exact remediation owner: ____
Cleanup owner/sign-off: ______________________________
Overall result: PASS / OBSERVED-SETUP / REMEDIATION / BLOCKED
Eligible for Intermediate Day 3? YES / NO / AFTER REMEDIATION
Instructor signature/date (UTC): _____________________

Course completion principle: A learner who merely watched a video or copied a KQL query has not necessarily mastered security operations. Award completion based on reproducible queries, cross-verified telemetry, an investigated training incident, a reasoned decision, and responsible cleanup. When a real deployment dependency is unavailable, keep the simulated learning credit but record the missing live evidence transparently.

End of the single-file Day 1 + Day 2 Foundations lab manual.

rajeshkumar