Student workbook + instructor validation and answer key | Days 1-2 | 2026-11-01 edition

One lab, one continuous story: Build a Microsoft Sentinel environment, connect Azure Activity logs, make a harmless Azure configuration change, prove that the event reaches the AzureActivity table, investigate it using KQL, turn a tested query into a temporary scheduled detection, find its actual alert and incident, complete a first-line SOC triage record, visualize the data with a workbook, and clean up safely.

Primary interface: Microsoft Defender portal (https://security.microsoft.com), with Azure portal (https://portal.azure.com) for initial Azure resources and subscription-level activity-log configuration. This matches Microsoft’s current direction for Sentinel. [MS01] [MS02]

This is a Foundation lab, not a red-team exercise. Do not attack resources, intentionally compromise identities, turn on disruptive automations, export real secrets, or run changes in production. Never equate a saved rule or KQL simulation with a genuine alert or incident.

1. The outcome: what a successful student can demonstrate

At the end, you should be able to show evidence, not simply explain terminology:

A named, approved Azure subscription and its access boundaries.
A Log Analytics workspace with Microsoft Sentinel enabled and visible in the Defender portal.
The Azure Activity solution and a documented, working route from the source subscription to that workspace.
A harmless resource-group write visible in the source Azure Activity log and in the destination AzureActivity table.
A working KQL query that isolates the test event, displays a timestamp and identifies the actor/resource.
A temporary enabled scheduled analytics rule with verified settings and minimal alert noise.
A real generated alert and a real incident containing that alert (or clearly recorded environment blocker).
An incident investigation report with disposition, evidence, owner, and escalation rationale.
A relevant Azure Activity workbook interpreted correctly.
Cleanup evidence showing that the test rule is disabled/removed and lab resources are handled safely.

Foundation qualification: Complete the entire evidence chain and meet the rubric in Section 16. Installing Sentinel or obtaining a screenshot of the portal alone does not constitute a pass.

Where this lab fits in the five-day program

Previous teaching	This continuous workflow practices	Reserved for later days
F01-F12, Day 1	SOC context, architecture, roles, workspace, data connector	Advanced source onboarding and DCRs (Day 3)
F13-F23, Day 2	KQL, content, rule, alert, incident, triage, workbook, troubleshooting	Multi-table correlation/UEBA (Day 3); ASIM/SOAR (Day 4); enterprise CI/CD/data lake (Day 5)

This manual intentionally uses one connected exercise, instead of repeating the 17 individual practice labs in the more detailed Day 1-2 workbook.

2. 5W1H: understand what you will build before clicking

Question	Foundation-level answer
What?	Microsoft Sentinel is a SIEM capability that collects security telemetry and supports detection, investigation, and response.
Why?	An isolated activity record is difficult for a SOC to investigate consistently; centralized logs, rules, and incidents create a repeatable trail.
Who?	The Azure/platform administrator authorizes data collection; the security engineer configures Sentinel; the SOC analyst investigates alerts; the instructor approves training changes.
When?	Use the workflow when an approved activity needs visibility, detection, triage, and documented resolution.
Where?	Azure control-plane events originate in the subscription, flow to a Log Analytics workspace, and are examined in Microsoft Sentinel through the Defender portal.
How?	Source event -> approved diagnostic export/policy -> `AzureActivity` -> KQL -> scheduled analytics rule -> alert -> Defender incident -> SOC triage -> workbook.

The architecture you will prove

Approved student action: change a tag on a test resource groupAzure subscription Activity logAzure Activity connector configuration: policy or diagnostic exportLog Analytics workspace: AzureActivity tableMicrosoft Sentinel analytics rule: scheduled KQLSecurity alertMicrosoft Defender incident queueAnalyst triage, evidence, classificationAzure Activity workbook

Important boundaries: Creating a resource-group tag is not a cyberattack. For this lab, the detection identifies authorized training activity and must be labeled as such; it must never be marketed as a high-fidelity threat detection. A scheduled rule may raise an alert without proving an actual security incident.

3. Choose a delivery mode and establish safety controls

3.1 Three supported classroom modes

Mode	What the instructor prepares	What the learner can pass
A – Full build (preferred)	Dedicated non-production Azure subscription or approved sandbox, rights to provision workspace, export subscription activity, and configure Sentinel	All ten outcomes
B – Instructor-managed collection	Prebuilt Sentinel workspace and Azure Activity export; learner may edit a dedicated signal resource group and create a temporary rule	End-to-end event-to-incident workflow without repeating administrative provisioning
C – Read-only / offline	Screenshots and synthetic `datatable()` examples, optionally a read-only Sentinel workspace	Concepts and KQL only; cannot claim to have created a real alert or incident

If an approval, permission, subscription, billing entitlement, or data-collection requirement fails, select Mode B or C and label the blocked checkpoint. Do not grant students broad permissions only to make a lab appear successful.

3.2 Minimum preparation and role separation

Activity	Typical required access or approval	Responsible party
Create a resource group / workspace	Azure subscription or resource-group write permission; enabling Sentinel requires subscription Contributor-equivalent permission	Instructor/platform admin
Use Sentinel and view logs	Microsoft Sentinel Reader or appropriate Log Analytics read permissions	Student or instructor
Install Content hub solution / author analytics rule	Microsoft Sentinel Contributor on workspace resource group	Instructor/security engineer or delegated student
Manage the incident	Microsoft Sentinel Responder (or Contributor) and any relevant Defender unified incident permissions	SOC student
Configure Azure Activity export	Subscription-level diagnostic setting or Azure Policy assignment permission; assignment/managed-identity remediation may need additional rights	Subscription/policy owner
Use or save workbooks	Workbook Reader / Workbook Contributor and relevant Sentinel rights	Student/instructor
Connect workspace to Defender if not already connected	Additional onboarding permission requirements in Microsoft documentation; instructor should perform it if not already onboarded	Tenant/subscription administrator

Microsoft’s permissions are task-specific. A Sentinel Contributor assignment does not automatically authorize every subscription-level Azure Policy change, and a Sentinel Reader cannot manage incidents. Review the exact role scope before starting. [MS01] [MS03] [MS04]

3.3 Preflight requirements – instructor checks

[ ] A non-production training subscription exists; its subscription ID, tenant, and billing owner are documented.
[ ] There is an approved Azure region and naming pattern; no sensitive customer data is needed.
[ ] Learner identities have approved scopes, not unnecessarily broad Owner rights.
[ ] The instructor has a plan for Azure Activity export: existing approved export, Azure Policy wizard, or direct subscription diagnostic setting. Avoid creating duplicate exports of the same categories to the same workspace.
[ ] The sandbox has approval for potential Sentinel/Log Analytics and other service charges. Azure Activity ingestion has specific no-ingestion-charge guidance, but this does not mean every Sentinel or lab component is free. Confirm pricing for the selected plan. [MS05] [MS06]
[ ] The instructor has confirmed which incident experience is available: Incidents or the preview Cases > Incident. [MS10] [MS11]
[ ] The instructor has approved cleanup ownership and whether the lab workspace will be retained for subsequent training.

Safety stop: If any requested change affects a shared production diagnostic setting, permission assignment, data-retention policy, or real customer incident, do not perform that step. Ask the instructor to complete it or provide a safe sandbox artifact.

3.4 Student fill-in sheet – use actual values

Parameter	Your value
Cohort and student ID	`________________`
Training tenant/domain (non-sensitive label)	`________________`
Approved subscription ID	`________________`
Workspace resource group	`rg-sentinel-foundation-________`
Log Analytics workspace	`law-sentinel-foundation-________`
Workspace region	`________________`
Approved signal resource group	`rg-sentinel-signal-________`
Activity-export method	Existing / Azure Policy / Diagnostic setting
Activity-export policy or setting name	`________________`
Detection rule name	`LAB-FOUNDATION-________-RG-WRITE`
Student’s incident owner/assigned analyst	`________________`

Naming: replace the underscores with a short unique, cloud-valid suffix. Use the same exact names in screenshots and queries. Do not type the placeholder values unchanged into production.

DAY 1 – Build and prove the telemetry path

Phase 1 – Verify the subscription and the lab scope

Goal: Know where you are and what you may change.

Sign in to https://portal.azure.com with the instructor-approved user.
Search for Subscriptions. Open the subscription authorized for this lab.
Copy the Subscription ID into the student sheet. Record its display name without exposing unnecessary organizational details.
Confirm the selected Directory + subscription filter shows the intended tenant/subscription. If multiple subscriptions are visible, switch to the approved one.
In Access control (IAM), ask the instructor to verify that your assignment permits the operations you will perform. Do not try random role changes to fix permission failures.
Agree on the approved region, the workspace RG, and a different resource group used to generate test activity.
In Cost Management + Billing or the instructor’s approved budget view, record the allowed lab spend and who will review it.

PASS checkpoint P01: Correct subscription/tenant, permissions, workspace location, and a cost/cleanup owner recorded. Save P01-subscription-scope.png (hide subscription IDs if materials will be shared externally).

Why it matters: A valid query against the wrong tenant or workspace can return nothing. A subscription-scope export configured against the wrong subscription cannot transport your test event.

Phase 2 – Create or verify a Log Analytics workspace

If the instructor supplied a workspace: Open it, confirm its subscription, resource group and region, and go to Phase 3. Do not create a duplicate.

Full-build route:

In Azure portal search for Log Analytics workspaces and select Create.
Select the approved subscription.
Select the designated workspace resource group, or Create new if authorized.
Enter your unique workspace name such as law-sentinel-foundation-s01.
Select the instructor-approved region; do not guess a region merely because it appears in a sample screenshot.
Review pricing, data residency and retention implications. Do not activate optional products or unapproved long-term retention.
Select Review + Create, wait for validation, then Create.
Open the workspace. Record Name, Resource group, Region, and Subscription from the Overview screen.
Check whether Sentinel was already enabled on it. If yes, record and continue; do not try to onboard the same workspace twice.

PASS P02: The exact intended Log Analytics workspace exists, is accessible, and its metadata is recorded. Save P02-workspace-overview.png.

Common problem: The workspace does not appear in the Sentinel onboarding picker. Check subscription filter, workspace eligibility and permissions; default Defender for Cloud workspaces have restrictions for Sentinel onboarding. [MS01]

Phase 3 – Enable Microsoft Sentinel and confirm Defender portal visibility

In Azure portal, search for Microsoft Sentinel.
Choose Create, select the intended Log Analytics workspace, and choose Add. If Sentinel is already enabled, do not repeat the action.
Open https://security.microsoft.com and let initial portal provisioning finish if prompted.
Expand Microsoft Sentinel in the navigation. Confirm the workspace is available under System / Settings > Microsoft Sentinel > Workspaces (exact menu grouping may vary).
If no workspace is connected, have the instructor/onboarding owner follow Settings > Microsoft Sentinel > Connect a workspace, select the appropriate workspace and primary workspace, review the connection effects, then Connect. This is not a task for a student lacking onboarding rights. [MS02]
Record whether this tenant uses a standard incident queue or incident-cases preview. Do not enable preview features just to match this manual.
Confirm you can access Microsoft Sentinel > Configuration > Data connectors, Configuration > Analytics, and the hunting/logs query interface, even if some operations are read-only.

PASS P03: You can point to the correct Sentinel-enabled workspace from the Defender portal, and your access level is known. Save P03-defender-workspace.png.

Know the distinction: Log Analytics is the data/query workspace; Sentinel adds SIEM capabilities; Defender portal is the current unified analyst experience. A workspace being created does not itself prove that it is receiving activity logs. [MS01] [MS02]

Phase 4 – Install the Azure Activity content and configure an export route

Step A – Content hub

In Defender portal expand Microsoft Sentinel and open Content hub (use portal search if your navigation differs).
Search for Azure Activity.
Open the solution, review its connectors/rule templates/workbooks and dependencies.
Select Install if not already installed. Wait for it to show as installed.
Open Microsoft Sentinel > Configuration > Data connectors.
Find Azure Activity, then Open connector page.
Read its prerequisites, data type (AzureActivity) and configuration status. Connected is useful information but not proof of a particular event reaching the table.

Step B – Choose exactly one approved export method

Method 1 – existing instructor-approved export (best for shared classrooms):

In Azure portal open the approved subscription > Activity log > Export Activity Logs, or have the admin show its relevant Azure Policy assignment.
Confirm Administrative events (at minimum) are sent to the correct Log Analytics workspace.
Record the existing setting/policy name, destination workspace and owner. Do not modify it.

Method 2 – Azure Activity connector’s Azure Policy wizard (Microsoft quickstart route):

From Azure Activity > Open connector page, select Launch Azure Policy Assignment Wizard.
Under Basics, choose only the instructor-approved subscription scope; do not select an entire management group or unrelated subscriptions.
Under Parameters, choose the Primary Log Analytics workspace that contains your Sentinel instance.
With the policy owner, review the policy effect, assigned identity (if presented), permissions/remediation requirements, and target subscription. Resolve permission failures with the owner, not elevated student privileges.
Select Review + create > Create after explicit approval.
Record the assignment identifier and review it under Azure Policy > Assignments. Allow time for the policy/diagnostic configuration to take effect. [MS01]

Method 3 – direct subscription diagnostic setting (only when approved):

In Azure portal open Monitor > Activity log > Export Activity Logs for your approved subscription.
Select Add diagnostic setting.
Name it clearly, for example diag-sentinel-foundation-s01.
Select the Administrative category. Add other categories only if they are approved for the lab.
Under Destination details, choose Send to Log Analytics workspace, then the approved subscription and workspace.
Verify all four before saving: source subscription, categories, destination workspace, setting name.
Select Save, record the name, and check that you have not introduced a duplicate route. [MS05] [MS06]

Do not configure Methods 2 and 3 in parallel for the same source/destination unless the instructor deliberately designed that topology.

PASS P04: Azure Activity solution present; documented export configuration targets the correct workspace; Administrative category is covered; owner and cleanup responsibility recorded. Save P04-activity-connector.png and, if authorized, an export configuration screenshot.

What you have and have not proved

You have verified the configuration of collection.
You have not yet proved that an actual event traveled through it. That happens in Phase 5.

Phase 5 – Produce a harmless, traceable event

Scenario: Aster Retail (fictional company) is validating whether SOC analysts can see Azure administrative changes. You are a platform engineer making an approved change to a sandbox resource group. The SOC should observe and explain it.

In Azure portal, go to Resource groups > Create.
Create a new, empty group named with your approved signal identifier, such as rg-sentinel-signal-s01, in the approved subscription and region. Keep it empty; do not deploy VMs, storage accounts or paid services.
After creation, open that resource group and select Tags.
Add a harmless tag: Name sentinelTraining; Value foundation-day1. Save. Do not modify access, networking, policies, secrets, or production resources.
In the approved subscription open Activity log. Filter by the test resource group, recent timeframe and Administrative operations if needed.
Find a successful resource-group create/update/write event. Record its operation name, time (UTC), actor and resource identifier. The portal’s text and case can vary.
If you do not see it immediately, widen the time filter and inspect a recent Activity log without the group filter. If it still does not exist at the source, do not proceed to the destination and falsely claim collection is working.

PASS P05: You have a real source-side activity record for a change you performed on the test resource group. Save P05-source-activity-log.png.

Why this is the right first signal: Azure Activity captures control-plane changes such as resource creation and update. A safe tag change demonstrates the flow without simulating a malicious compromise. [MS05] [MS13]

Phase 6 – Prove delivery to the destination workspace using KQL

Step A – Access the correct logs query surface

Open the Azure Activity connector in Defender and choose its Go to log analytics path if available; this opens the relevant hunting/query experience. Otherwise open Investigation & response > Hunting > Advanced hunting and select the correct workspace data scope.
The same raw workspace query can also be run from Azure portal > Log Analytics workspace > Logs. Use the latter when a query in Defender is not pointed at the intended workspace.
Set a time window broad enough for the exercise, such as last 24 hours. Note that the UI’s time selector and KQL’s ago() filter can both constrain results.

Step B – Confirm that records exist

AzureActivity
| where TimeGenerated >= ago(24h)
| summarize EventCount = count(), LatestEvent = max(TimeGenerated)

Expected: EventCount greater than zero if this workspace has received Azure Activity records. If zero, see the troubleshooting ladder. A count above zero could still be someone else’s event, so it does not complete the lab.

Step C – Inspect exact fields and the test group

Run this more permissive query first, replacing both quoted values:

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

Expected: A record containing the test group name that matches the actor, subscription, and approximate event time from Phase 5.

Important: Microsoft warns that Azure Activity fields can differ in casing. The query deliberately uses case-insensitive operations (=~ and contains). [MS05] [MS07]

Step D – Isolate the resource-group write operation

This is the detection candidate. Do not use it until Step C returns the expected row.

let labSubscription = "REPLACE_WITH_YOUR_SUBSCRIPTION_ID";
let labResourceGroup = "rg-sentinel-signal-s01";
AzureActivity
| where TimeGenerated >= ago(2h)
| where SubscriptionId =~ labSubscription
| where CategoryValue =~ "Administrative"
| where OperationNameValue contains "resourcegroups/write"
| where ResourceId contains labResourceGroup or ResourceGroup contains labResourceGroup
| project TimeGenerated, Caller, ResourceId, ResourceGroup,
          OperationNameValue, ActivityStatusValue, CorrelationId, SubscriptionId
| sort by TimeGenerated desc

If the source event’s actual OperationNameValue differs, use the value observed in Step C rather than assuming a generic operation name. Keep the resource-group and subscription filters so the query cannot match unrelated production activity.

Step E – Explain the result as a SOC analyst

For your best matching row, write down:

TimeGenerated (UTC): ________________
Caller: ________________
ResourceId: ________________
OperationNameValue: ________________
ActivityStatusValue: ________________
CorrelationId (if present): ________________
Is this your approved lab action? Why? ________________

PASS P06: AzureActivity contains the same authorized operation as the source Activity log; the detection candidate returns at least one appropriate record; student explains what each selected field means. Save P06-kql-proof.png and the exact successful query text.

Do not continue if your query returns no matching record: a detection that cannot match a signal cannot reliably prove the rule-to-incident workflow.

Optional offline KQL mini-exercise (does NOT count as real ingestion)

When access is blocked, this query helps learners practice a pipeline inside the query engine without ingesting anything:

datatable(TimeGenerated:datetime, Actor:string, Operation:string, Lab:string)
[
  datetime(2026-10-01T09:00:00Z), "student01", "resourcegroups/write", "foundation",
  datetime(2026-10-01T09:10:00Z), "student02", "resourcegroups/read",  "foundation",
  datetime(2026-10-01T09:20:00Z), "student01", "resourcegroups/write", "foundation"
]
| where Operation contains "write"
| summarize Changes=count() by Actor

Expected: student01 has 2 matching writes. This demonstrates where and summarize. It produces no ingested security telemetry, no scheduled alert and no actual incident. Never use this synthetic query as the sole proof of a live detection.

Day 1 sign-off

[ ] P01 subscription and scope verified.
[ ] P02 approved Log Analytics workspace verified.
[ ] P03 Sentinel enabled and Defender portal available.
[ ] P04 Azure Activity collection configuration verified.
[ ] P05 test change visible at the source.
[ ] P06 matching AzureActivity row visible in destination.

Day 1 stopping rule: Without P06, the learner does not proceed to the detection phase until the collection issue is fixed or the instructor supplies a prevalidated workspace.

DAY 2 – From real telemetry to an investigated incident

Phase 7 – Analyze the event like a first-line SOC analyst

Goal: Turn raw log evidence into an explainable finding before attempting an alert.

Run the Phase 6 query and sort descending by time.
Identify whether multiple records belong to the same logical operation (for example start and success states). Do not call two records two separate attacks.
Run this summary query:

let labResourceGroup = "rg-sentinel-signal-s01";
AzureActivity
| where TimeGenerated >= ago(24h)
| where ResourceId contains labResourceGroup or ResourceGroup contains labResourceGroup
| summarize Operations=count(), LatestEvent=max(TimeGenerated)
  by OperationNameValue, ActivityStatusValue
| sort by Operations desc

Answer these questions: Which event was expected? Who initiated it? Which resource was changed? Was it successful? What additional evidence would you seek before treating it as suspicious?
Record a short analyst narrative: “A resource group was modified by [actor] at [UTC time]. The change was [authorized/unverified]. Evidence: [Activity log + KQL rows]. Next action: [close as training / escalate for authorization check].”

PASS P07: A reproducible KQL summary, accurate reading of the source event, and no unsupported claim that the authorized action is an attack.

Phase 8 – Discover built-in detection content (and understand the limitation)

The Foundation syllabus includes rule templates. Explore them here, but use Phase 9’s controlled rule to prove the whole workflow.

In Defender portal open Microsoft Sentinel > Content hub and locate the installed Azure Activity solution.
Look for the documented Suspicious Resource deployment template (availability depends on installed solution/version).
Read its prerequisites, query/table dependencies, threshold and intended threat scenario.
If the instructor approved enabling it in a sandbox, choose Create rule from the template, confirm its data prerequisites, and review all settings. If not, perform a read-only walkthrough.
Compare that built-in rule with the training query: the built-in rule seeks a security-relevant pattern, whereas this lab’s custom rule intentionally detects one authorized group change.
Record whether it was only inspected, created but disabled, or enabled. Disable any temporary rule that is noisy or unrelated.

PASS P08: Student can differentiate installed solution, rule template, active rule, alert and incident. Merely enabling a built-in template does not guarantee an alert from your harmless test event. [MS01] [MS08]

Phase 9 – Create a temporary scheduled analytics rule from your proved query

Security notice: This short-lived rule is named TRAINING ONLY. It alerts on a known benign change. Do not assign a fictional ATT&CK technique, label it a real threat, route to production incident responders or attach a playbook.

Step A – Rule definition

In Defender portal select Microsoft Sentinel > Configuration > Analytics > + Create > Scheduled query rule.
Set a unique Name, for example LAB-FOUNDATION-s01-RG-WRITE.
Description: TRAINING ONLY. Detect approved writes to an isolated lab resource group. Disable and remove after exercise.
Set Severity to Informational or Low as approved; choose Enabled for the temporary controlled test.
Do not assert MITRE ATT&CK mapping for this benign administrative test.

Step B – Paste proven query and minimize noise

Copy the exact tested Phase 6 Step D query. Replace the subscription ID and group name with your actual lab values. Keep TimeGenerated in the projected results; Microsoft explicitly requires it for scheduled-rule lookback evaluation. [MS08]
In Set rule logic, paste the query and resolve any validation errors.
If supported in your portal, add custom details such as ResourceId and OperationNameValue for investigation. Entity mapping may be skipped for this first Foundation exercise; incorrect entity mappings can confuse the incident graph.
Run query every: 5 minutes.
Lookup data from the last: 2 hours (beginner demo only; widen if approved and needed for ingestion delay).
Generate alert when number of query results is greater than: 0.
Event grouping: Group all events into a single alert.
Stop running query after alert is generated: On, for 1 hour if the setting is offered. If your environment cannot use it, disable the rule promptly after the first alert to prevent repetitions.
Run Test with current data / Results simulation if available. Record the preview and remember: simulation is not an alert.

Step C – Create actual incidents without automated remediation

On Incident settings, ensure Create incidents from alerts triggered by this analytics rule = Enabled. When Sentinel is connected to Defender, Microsoft Defender’s incident engine handles creation/correlation and may group alerts differently from initial settings. [MS08]
On Automated responses, do not add automation rules or playbooks for this Foundation lab.
On Review and create, confirm query, workspace, enabled status, threshold, schedule, incident creation and intended scope.
Select Create only after validation passes and the instructor approves the settings.
Return to Active rules. Verify the rule exists and is Enabled.

PASS P09: An active, time-limited training rule exists; query and source scope match the KQL that already returned a real row; incident creation is on; no automated remediation is configured. Save P09-rule-settings.png.

Operational note

Since the lookback is two hours, a previously ingested event may cause the first alert shortly after rule activation. If none appears and all prerequisites are valid, create a new approved tag update after activation, for example changing sentinelTraining from foundation-day1 to foundation-alert-test, and then wait for that event to arrive. Do not repeat changes in a tight loop.

Phase 10 – Observe the real alert and incident

Step A – Check the event and alert

Verify the signal group’s most recent tag update in the Azure subscription Activity log.
Rerun the exact rule query against AzureActivity. A matching row must appear in the appropriate lookback window; capture its timestamp.
Open Defender portal > Investigation & response > Incidents & alerts > Alerts. Filter to the recent period and your unique training rule or source.
Record the actual Alert ID, name, severity, creation time, rule/source and matching resource. If none appears, inspect the rule state, simulation result, lookback/schedule, exact data filters and the queue’s filters; give the service time to process.
A query returning rows is proof of data, not proof of alert generation. Do not mark this phase passed until you have a real alert ID.

Step B – Find the incident containing the alert

Open Investigation & response > Incidents & alerts > Incidents.
Search by rule name/alert/period and check whether the alert is included in an existing incident rather than assuming every alert becomes a new separate row.
If your tenant is using the incident-cases preview, the comparable location is Cases > Incident. Follow the experience actually available; do not try to enable preview in a lab without approval. [MS10] [MS11]
Open the incident/case, verify it includes the matching alert, and record its ID, severity, status, created time, owner and evidence.
When you have the necessary alert/incident screenshots, disable the training analytics rule now. Leave the incident available for investigation, but stop further repeated alerts.

PASS P10: A real Azure source event, matching ingested AzureActivity row, scheduled rule, real alert ID, and real incident/case ID containing that alert. Save P10-alert.png and P10-incident.png.

If an alert is visible but an incident is not, this is a partially completed flow, not a pass. See Section 14.

Phase 11 – Conduct SOC L1 incident triage and write the incident report

Open the matching incident/case from P10.
Verify its title, priority/severity, alert details, timeline, resource references, actor and any mapped entities (if available).
Assign the incident to the instructor-approved training analyst if your permissions allow it. Read-only participants instead document the intended owner.
Use the Source Activity log and KQL query as independent evidence. Explain the difference between the time the action occurred and the time an alert/incident was created.
Evaluate whether the resource change was authorized, expected, harmful or unknown. For this exercise, the instructor knows it was authorized.
Write an investigation note in the incident/case if allowed. Do not include access tokens, secrets, personal contact details or confidential enterprise information.
Resolve/close it with the equivalent of Informational / expected activity or Benign positive when supported by the applicable UI; if classification labels differ, choose the closest accurate meaning and document the mapping. Do not classify a true benign test as a confirmed security compromise.
If the status/close action is not available, record the exact permission blocker and have an authorized instructor perform it.

Learner incident report – complete this template

INCIDENT REPORT - FOUNDATION TRAINING
Student / cohort:
Timestamp and timezone (UTC):
Subscription / workspace:
Signal resource group:
Source Activity log event time:
Event operation name and result:
Actor / initiating identity:
KQL query used (file or paste):
Matching AzureActivity evidence:
Analytics rule name:
Alert ID and alert creation time:
Incident / case ID and creation time:
Incident owner:
Was this authorized? What evidence proves it?:
Classification and rationale:
Immediate action taken (normally none / training closure):
Escalation needed? Why / why not?:
Rule disabled after exercise? Evidence:
Instructor review:

What a good analyst should conclude

An approved Azure configuration change is expected activity. It should produce a verifiable record and, because we intentionally configured a training detector, may produce an alert. An alert does not equal compromise. A strong analyst documents the approval and evidence, closes the training incident appropriately and recommends not using this simplistic alert rule for production. [MS10] [MS11]

PASS P11: Complete evidence-based report, defensible disposition, and safe closure or documented permissions blocker. Save P11-triage-report.md and an authorized screenshot of the close/classification state.

Phase 12 – Read a workbook and answer a real SOC question

Open Microsoft Sentinel > Threat management > Workbooks.
Search for an Azure Activity workbook/template included with the installed solution, if available.
Inspect its Required data types, select the appropriate workspace and open it.
If it must be saved before use, have a permitted instructor/learner select Save and the correct subscription/RG. Workbooks require distinct Reader/Contributor permissions. [MS09]
Adjust any time-range and subscription filters to cover your lab event. Refresh.
Locate a panel describing activity by operation, actor, status or time. Record one useful finding and one limitation.
If the template cannot be viewed due to permissions or visual feature availability, document the blocker and demonstrate a simple KQL summary instead; call it a fallback, not a saved workbook.

Student questions:

Which administrative operation did the test create?
How does the chart’s aggregation differ from the individual event row?
Why might the chart initially show nothing even though the event is in AzureActivity?
Which SOC question is answered well by this workbook, and which question would require querying raw logs?

PASS P12: Student identifies the relevant dataset, one actual visualization, and its limits. Save P12-workbook.png or mark the workbook as blocked with the specific reason.

13. End-to-end evidence chain: the student’s final walkthrough

The student must reconstruct this in order, pointing to an artifact for each arrow:

Boundary	Evidence artifact	Pass?
Approved subscription -> workspace	P01 + P02 screenshots and subscription/workspace notes	PASS / BLOCKED
Workspace -> Sentinel/Defender	P03 workspace view	PASS / BLOCKED
Activity-log export configured	P04 connector/diagnostic/policy record	PASS / BLOCKED
Approved change -> source event	P05 Activity log event with time and resource	PASS / BLOCKED
Source event -> destination KQL row	P06 matching `AzureActivity` row	PASS / BLOCKED
Log row -> explainable analyst summary	P07 source/query interpretation	PASS / BLOCKED
Built-in content understanding	P08 template vs active-rule explanation	PASS / BLOCKED
Tested query -> active scheduled rule	P09 rule validation and active state	PASS / BLOCKED
Rule -> real alert -> real incident	P10 Alert ID + incident/case ID	PASS / BLOCKED
Incident -> documented disposition	P11 case report and closure/ownership	PASS / BLOCKED
Logs -> visualization	P12 workbook result and interpretation	PASS / BLOCKED
Lab -> safe teardown	Section 15 cleanup record	PASS / BLOCKED

Never fill in an ID that the platform did not actually create. A screenshot of an instructor-provided example must be labeled instructor demo, not a student’s executed result.

14. Troubleshooting: locate the exact broken boundary

A single diagnostic ladder

NoYesNoYesNoYesNoYesNoYesNoYesNoYesDid approved Azure change succeed?Is change visible in source Activity log?Does approved export target the correct workspace?Does AzureActivity show test event?Does rule query match a row within its lookback?Did the scheduled rule generate a real alert?Does a Defender incident contain the alert?Complete investigation and close as expected training activityFix permissions / resource-group operationCorrect subscription / time / scope filtersFix policy or diagnostic settings with ownerVerify ingestion delay, scope, destination, query contextInspect actual fields; correct name, time, operatorCheck enabled state, schedule, threshold, suppression, executionCheck incident creation, filters, correlation and access

Symptom-to-action table

Symptom	Likely cause	Next safe validation
Can’t add Sentinel to workspace	Subscription Contributor permission missing, wrong subscription, unsupported existing workspace	Check subscription filter and onboarding prerequisites [MS01]
Workspace invisible in Defender	Not onboarded, wrong tenant/workspace, insufficient onboarding role	Settings > Microsoft Sentinel > Workspaces; involve admin [MS02]
Content hub Install unavailable	Missing Microsoft Sentinel Contributor or other content dependency	Review RG-scoped role assignments [MS03]
Azure Activity connector shows Not connected	No approved export, wrong workspace, delayed reporting	Review actual policy/diagnostic settings; do not rely solely on badge
Source Activity log has no test event	Change failed, incorrect subscription/time filter	Inspect resource group, source subscription and activity log directly
`AzureActivity` table missing / empty	No ingestion yet, wrong workspace, permissions, connector/export issue	Query correct Log Analytics workspace and review collection settings
Broad KQL returns rows but filtered KQL doesn’t	Wrong RG spelling, activity field casing, different operation name, too narrow time	Inspect broad query results and reconstruct filter from actual values
Scheduled rule fails validation	Missing `TimeGenerated`, invalid KQL, unsupported rule setting	Run query in Logs first; review wizard validation [MS08]
Rule enabled, no alert	Event not in lookback, threshold/suppression, not yet evaluated	Check actual data, results simulation, rule state and run timing
Alert visible, no new incident row	Incident creation off, Defender correlation put alert in another incident, filters/permissions	Search existing incident for matching alert; review rule settings [MS08]
Can’t assign/resolve incident	Missing Responder or Defender management permissions	Use read-only report; instructor handles changes [MS03] [MS11]
Workbook looks empty	Wrong data type, workspace, time range or workbook permission	Inspect Required data types and time/source filters [MS09]
Too many alerts	Wide lookback, short frequency, disabled suppression	Disable lab rule immediately; document cause and fix before rerun

Rule-of-thumb troubleshooting order

Source: Was the actual change made and logged?
Transport: Was the correct subscription exported to the correct workspace?
Schema and time: Does the destination record match expected columns and time?
Rule: Does the exact rule query return recent data and does its schedule run?
Alert and incident: Did the actual alert appear, and where did Defender group it?
Authorization: Do you have permission to see/manage the target artifact?

No stage should be marked PASS merely because a later screenshot seems plausible.

15. Clean up and prevent ongoing charges or noise

Cleanup is part of the graded lab. Do not delete an instructor-owned shared workspace or any organization-wide policy.

Disable the temporary scheduled rule as soon as you have the alert evidence (Phase 10). Confirm its status is disabled.
Complete incident evidence and resolution; verify the case and comments remain available for grading if required.
If the rule belongs only to your student sandbox and the instructor approves, delete it from Analytics > Active rules. Document the action.
Remove any temporary built-in test rule you explicitly created, but do not uninstall a Content hub solution used by other learners without approval.
For the test resource group (which must be empty other than approved tags), delete the group only if the instructor confirms it is solely yours and not used as a shared signal source. Copy its resource ID first for evidence.
For a newly created direct diagnostic setting, obtain the collection owner’s approval before removing it from the source subscription. For an Azure Policy assignment, coordinate removal/remediation with the policy owner; removing a policy assignment may not automatically clean up all deployed diagnostic settings.
Delete your new workspace/resource group only if it is not needed for later days and the environment owner explicitly approves. Check that no existing data collection or downstream teaching work depends on it.
Review the approved cost/budget view for usage accrued by the exercise. Note any extra services installed during class.
Save the cleanup record:

CLEANUP REPORT
Student ID:
Lab subscription and resource group:
Rule name and final state:
Incident ID and final classification/status:
Signal RG status (retained/deleted by owner):
Export diagnostic setting/policy (retained/removed by owner):
Workspace status (retained/deleted by owner):
Cost owner notified:
Open issues and next owner:
Timestamp:

PASS P13: Training alert noise has stopped and the ownership/status of every resource or collection route is documented. The goal is not “delete everything”; it is controlled, reversible, auditable cleanup.

16. Final Foundation skills assessment – 100 points

Competency	Points	Required evidence
Correct tenant, subscription, Azure scope and safety controls	10	P01, permission/cost decisions
Correct workspace + Sentinel + Defender access	10	P02-P03
Correct and approved Azure Activity export	10	P04
Harmless source event and matching ingested destination record	15	P05-P06 (both must be real)
Accurate KQL analysis and explainable SOC narrative	15	P06-P07
Content template understanding + correctly configured custom lab rule	10	P08-P09
Actual alert + incident evidence	15	P10: real IDs, source association
Incident triage, classification and report	10	P11
Workbook and limitations	3	P12
Safe disabling/cleanup documentation	2	P13
Total	100

Progression gate to Intermediate

Recommended passing score: 80/100.
Mandatory live competencies: P05, P06, P09, P10 and safe disabling/cleanup must be demonstrated or individually checked off by an instructor after successful remediation. A higher score cannot replace missing real evidence.
In Mode B, instructor-provisioned infrastructure is acceptable, but evidence must show that the student’s event reached the correct destination and produced the claimed alert and incident.
In Mode C, students may pass a KQL/concepts practice check, not the full end-to-end practical gate.

Instructor answer key / expected reasoning

What is an event? An Azure Activity entry describes a control-plane operation; the meaning depends on actor, subscription, scope, timestamp and result.
Why do we need export? The source Azure Activity log exists before Sentinel; a configured pipeline delivers relevant events to the Log Analytics table.
Does a Connected label prove an event arrived? No. The proof is a source event matched to the destination record.
What does KQL establish? The analyst can filter, summarize and inspect evidence in the connected table.
What makes this a scheduled rule? Sentinel reruns the tested query on a configured interval/lookback and creates an alert when the threshold is met.
Is Test with current data a real alert? No. It is a rule simulation.
Is the alert necessarily malicious? No. This alert deliberately indicates authorized lab activity; classify based on corroborated context.
Why might an alert not create a separate incident row? In Defender, incident correlation can put it into an existing incident; check incident creation and search for the alert ID.
What does a workbook add? Visual summaries for repeated SOC questions. The underlying source and filters must still be validated.
What is the final analyst action? Document expected activity, close appropriately, disable noisy demo detection and preserve graded evidence.

Oral demonstration: ask the student to trace the whole flow

“I changed this approved resource group; here is the corresponding Azure source event. This subscription export delivered it to my Sentinel workspace’s AzureActivity table. Here is the filtered KQL row, my rule’s configured threshold/lookback, the real alert, its incident, my authorized-activity classification and the disabled test rule. This workbook summarizes the underlying activity.”

If a learner can prove that narrative from their own artifacts and correctly explain its limitations, they understand the essential Foundations workflow.

17. Student submission checklist

Submit one folder (for example Sentinel-Foundations-s01) containing:

Sentinel-Foundations-s01/
  README.md                  # Student, selected Mode A/B/C, context, limitations
  P01-subscription-scope.png
  P02-workspace-overview.png
  P03-defender-workspace.png
  P04-activity-connector.png
  P05-source-activity-log.png
  P06-kql-proof.png
  P07-analysis.md
  P08-template-notes.md
  P09-rule-settings.png
  P10-alert.png
  P10-incident.png
  P11-triage-report.md
  P12-workbook.png
  P13-cleanup.md
  query.kql                  # Copy of final tested query with no secrets

If a screenshot is unavailable because of permissions or the mode used, submit BLOCKED-<checkpoint>.md documenting the exact obstacle and an authorized alternative. Do not invent screenshots, claim simulations were real alerts, or publish private subscription/user identifiers on a public training site.

18. Verified official references and change-check list

These references were reviewed for the November 1, 2026 edition. Exact button labels, permissions, licensing, and portal previews may change between cohorts. DOC-VERIFIED means the Microsoft article documents the workflow; LIVE-UNVERIFIED means this manual was not executed in your subscription. The instructor must complete P01-P13 once in the actual training tenant before delivery.

ID	Official Microsoft documentation	Used for
MS01	Onboard Microsoft Sentinel to a Log Analytics workspace	Workspace, Sentinel setup, Content hub, Azure Activity connector
MS02	Connect Microsoft Sentinel to the Defender portal	Workspace onboarding, Defender navigation and requirements
MS03	Roles and permissions in Microsoft Sentinel	Reader/Responder/Contributor responsibilities
MS04	Microsoft Sentinel in the Defender portal	Interface direction and support transition
MS05	Azure Monitor Activity log	Source operations, AzureActivity, case-insensitive fields, ingestion notes
MS06	Azure Monitor diagnostic settings	Direct subscription activity export and precautions
MS07	AzureActivity table reference	Query column names and types
MS08	Create scheduled analytics rules	`TimeGenerated`, schedules, lookback, thresholds, incident setting and suppression
MS09	Visualize data using Microsoft Sentinel workbooks	Workbooks and access requirements
MS10	Manage incidents in Defender portal (legacy experience)	Incident ownership, expected activity, notes and resolution
MS11	Manage incident cases in Defender portal (preview)	Case management differences and permissions
MS12	Create scheduled rule from a template	Built-in rule template discovery
MS13	Azure Activity log event schema	Administrative write-event interpretation

Before every course delivery, instructor recheck

[ ] Defender portal > workspace is connected and learners can see the intended scope.
[ ] The Azure Activity solution/connector remains installed and source export is authorized.
[ ] The live event query returns a correct row before an analytics rule is configured.
[ ] The scheduled-rule wizard supports the chosen lookback, interval and suppression in this environment.
[ ] A controlled test produces a real alert and Defender incident in the current incident UI.
[ ] Labels for closing expected activity are recorded for your tenant.
[ ] No lab rule or resource has a production blast radius; cleanup roles are assigned.
[ ] Entitlements, preview availability and pricing have been checked for the delivery date.

Validated offline for this publication: syllabus fit, Markdown structure, KQL composition against documented schema, field names, architecture coherence, evidence gates, and safety sequencing.

Not asserted: Live execution in your Microsoft tenant, guaranteed event delivery timing, guaranteed zero cost, identical portal menus in every tenant, or a generated incident where no real alert was observed.

End of Foundation End-to-End Student Lab Manual

rajeshkumar