Module 3: Advanced | Day 5 only | Enterprise Architecture, Data Lake, DevSecOps and SOC Governance

Edition: 1 November 2026
Training path: Day 5 of the five-day progressive Microsoft Sentinel program
This manual: Day 5 only; syllabus competencies A15–A27
Prerequisite: Days 1–4 operational/evidence gates completed
Primary UI: Microsoft Defender portal for Sentinel; Azure portal for resource governance
Output: Design decision records, data-tier plan, cost model, validated source-control workflow, health evidence and enterprise capstone
Format: Step-by-step and day-wise; no hourly schedule
Safety: Lab-only data, no unapproved production billing, retention or security-policy changes

---

READ FIRST — scope, accuracy, real-environment caveats

This is a standalone Day 5 instructor-and-learner manual. It assumes students already know workspace setup, query fundamentals, non-Microsoft collection, correlation, watchlists, rule tuning, ASIM, threat hunting and guarded playbooks. Those skills are inputs, not re-taught topics.

Validation status: The steps and product behavior were researched against Microsoft Learn information available 1 November 2026. This file can be structurally validated, and its offline scenarios can be calculated deterministically, but no actions have been executed against your live Azure/Microsoft 365 tenant. Every paid, privileged, tenant-wide, preview or destructive operation has a read-only alternative and a measurable operational PASS condition. Do not claim that a feature is enabled because this guide describes it.

2026-specific issues you must teach correctly:

• Defender portal is the primary Sentinel UI; Microsoft states Azure-portal Sentinel support ends after 31 March 2027 [R01]. Azure portal remains essential to administer Azure services.
• The Analytics tier supports real-time detections and normal interactive SOC operations; the Data Lake tier emphasizes cheaper long-term retention and job-based/historical analytics. Moving a table to lake-only can break real-time queries and detections [R02–R03]. Never modify a real table before mapping downstream dependencies.
• Data-lake onboarding is a tenant-level one-time setup tied to billing subscription/resource group and the Primary SIEM workspace in Defender. It can introduce charges; do not run onboarding unless explicitly approved. Onboarded resources should not be casually deleted [R04].
• Sentinel repository connections deploy supported ARM or Bicep custom content from GitHub or Azure DevOps. They can overwrite portal edits, and deleting a file from Git does not automatically delete the deployed Sentinel resource [R05–R06].
• Enable SentinelHealth/SentinelAudit in settings before expecting rows. Microsoft’s _SentinelHealth() and _SentinelAudit() functions are preferred for compatibility. SentinelHealth alone does not show internal Logic Apps execution; inspect Logic Apps diagnostics/run history [R07–R08].
• Workspace and tenant count should follow residency, access boundaries, ownership, connector tenancy and actual operating requirements, not a reflexive “workspace per subscription” rule [R09].
• Costs vary by region, data type, commitment, retention, workflows and billing agreement; example dollar figures are illustrative only. Never apply a pricing-tier change to make a lab pass [R10–R11].

Day 5 learning outcome and 5W1H

Lens	Enterprise outcome
What?	Workspace topology, Defender/data-lake retention, historical jobs, telemetry unit economics, repository deployment, health/audit, SOC SLOs and recovery
Why?	Preserve detection coverage and evidence while meeting residency, performance, change, reliability and budget constraints
Who?	Global/local SOC, cloud/platform team, Detection Engineering, compliance, FinOps, release approver and incident commander
When?	Split workspaces only for concrete requirements; change retention after dependency review; deploy via gated release; practice failures before incidents
Where?	Microsoft Entra tenant boundaries, Log Analytics workspaces, Defender portal, data lake, GitHub/Azure DevOps, Azure billing and monitoring
How?	Define requirements → choose a topology → classify/tier data → cost-model sources → govern Git deployment → verify health → defend capstone

Aster Retail enterprise case — fictional inputs, not a production template

Aster Retail operates in two business geographies (Region A and Region B), with regional data-residency obligations. It has a cloud operations team, central SOC, regulated HR and finance logs, network security telemetry and application audit streams. A single trained detection engineer previously built a correlated detection and a safe approval-gated playbook (Days 3–4). Now leadership asks for a production-operating model with change control, searchable history, cost guardrails and measurable SOC outcomes.

Assumptions for the exercises: Both regional units have a documented legal boundary; logs containing employee identifiers may require local storage; central analysts must be able to view permitted incidents; only approved metadata is shared across borders; learner examples use fake identities and reserved documentation IP addresses. Do not assume these requirements match actual laws in any particular jurisdiction—consult legal/privacy owners in a real design.

Region A sources / legal entitySentinel Workspace ARegion B sources / legal entitySentinel Workspace BAnalytics tier: detection-ready dataAnalytics tier: detection-ready dataCentral SOC: authorized multi-workspace viewLonger-term lake retention, if approvedLonger-term lake retention, if approvedGit: PR / validation / releaseApproved workspace deploymentsHealth + audit / Cost ManagementHistorical lake jobs: governed access

Diagram caveat: These arrows describe responsibilities, not guaranteed cross-border replication or automatic cross-tenant incident merging. The exact topology, data residence and query limits must be validated in your tenant.

Instructor preflight and safe lab tracks

Preflight requirements

• [ ] Existing non-production Sentinel-enabled workspace and Day 4 detection/playbook artifacts; keep the latter disabled by default.
• [ ] Approval to view Azure Cost Management, Sentinel configuration and data-table settings; no write permission to production pricing or retention for learners.
• [ ] One approved GitHub or Azure DevOps test repository with a designated branch, signed-off security access, GitHub Actions/Pipelines permitted where appropriate, and no secrets committed.
• [ ] If repository connection will be exercised: an instructor with Owner on the workspace resource group; collaborator access to GitHub or project-admin access to Azure DevOps; repository authorization policies and a home-tenant account, not unsupported external guest [R05].
• [ ] If data lake will be exercised: verify supported region, Primary SIEM workspace, required roles, written approval from billing owner, cost control and safe resource group. Do not delete the data-lake billing resource group to clean up a lab [R04].
• [ ] Azure CLI installed only if optional CLI checks are used (az version); auth to approved sandbox only. Any az deployment ... command targets a test resource group, never production.
• [ ] Sentinel Health/Audit enablement approved for test workspace and an owner assigned to review extra billed audit data [R07–R08].
• [ ] Named SOC/service owners, retention counsel, cost owner, change approver and final capstone reviewer.
• [ ] Evidence storage and cleanup process defined; no screenshots of real customer data, personal UPNs, tokens or production billing details.

Operational versus conceptual tracks

Track	Available capabilities	Can claim as PASS
A — Full non-prod deployment	Approved multiworkspace visibility, data lake access, test repo connection, health/audit events, billing visibility	Live component pass only with portal/CLI evidence; capstone pass if rubric met
B — Instructor-run/shared	Learner authors ADRs/KQL/templates while instructor operates tenant-wide steps	Competency pass, with actor attribution to instructor
C — Restricted/synthetic	No admin actions; read-only table samples, cost worksheet, mock PR and health fixtures	Design/reasoning pass only; no claim of live data lake/CI-CD deployment

Control rule: Tenant-level onboarding, paid retention, commitment-tier change and repository authorization require separate recorded approval from the right owner. Course attendance alone is not authorization.

Evidence contract and naming

Create D5/<learner-id>/ with folders 01-architecture, 02-data, 03-economics, 04-delivery, 05-observability, 06-capstone and a validation-ledger.md file. For each real lab record: UTC timestamp, workspace/subscription scope, exact query or file version, expected result, observed result, operator, PASS/BLOCKED/SUBSTITUTED and redacted proof. If a live action did not execute, mark not tested.

---

DAY 5 — STEP-BY-STEP LABS

D5-L00 — Enterprise preflight and artifact handoff from Days 1–4

Mapped: prerequisites, A15/A22/A26. Purpose: Make the new enterprise exercises traceable to tested baseline artifacts.

1. Open Defender and select the correct Sentinel workspace and organization tenant. Record both names and subscription/region in the private evidence ledger.
2. Inspect the Day 4 detection design, query and regression matrix. Preserve its query as a reviewed input; avoid inventing a new rule simply for repository exercises.
3. Inspect the Day 4 approval-gated Logic App. Confirm lab-only automation is disabled and there are no pending test approvals that could act unexpectedly.
4. Verify the source field contract, synthetic/real evidence labels and incident ownership. Record which dependencies need real-time Analytics-tier data (detection, hunting, workbook, playbook lookup) and which are historical/compliance needs.
5. Review the Git test repository branch and Azure resource group permission. Block any automatic production deployment until the branch, credentials and connection scopes have been reviewed.
6. Agree with the instructor which tasks are read-only and which are allowed to provision. Obtain billing-owner signoff for any optional data-lake setup.
7. Complete a short preflight evidence sheet with signature fields for platform owner, security owner, FinOps reviewer and instructor.

PASS: A verified Day 4 input artifact, scoped resources/roles, cost-approved lab track and no unexpected active automation.
Evidence: D5-L00-preflight.md; source IDs and signoff. Read: [R01], [R05], [R09].

D5-L01 — Choose single versus multiple workspaces on defensible requirements

Mapped: A15. Outcome: A documented workspace/tenant strategy, not an arbitrary workspace count.

1. Read the enterprise scenario and classify each requirement: must, should, or nice to have. Include residency, independent admin ownership, data access restrictions, cost allocation, tenant-specific Microsoft connectors, SOC visibility, incident handling and query limitations.
2. Draw two candidate topologies: Option S — a single centralized workspace and Option M — separate regional workspaces with authorized cross-workspace SOC operations.
3. Use this decision matrix; do not fill in “supports” by intuition:

Criterion	Option S: one workspace	Option M: regional workspaces	Test / owner
Data residency	Might conflict with region-specific obligations	Regional isolation possible	Legal/privacy approval
SOC operations	Simpler central analysis	Requires multiworkspace permissions/workflows	SOC lead
Access boundary	Workspace/table RBAC may be sufficient	Separate workspace administrative boundary	IAM owner
Tenant-local SaaS connectors	Some require same tenant as destination	Usually need local tenant workspace	Connector engineer
Cost allocation	Shared billing	Per workspace/entity accounting	FinOps
Operational overhead	Lower baseline	More connectors, rules and change coordination	Platform lead
Query/incident reach	Simple single workspace	Must test multiworkspace access/limits	SOC engineer

4. Determine whether multiple Entra tenants are involved. Microsoft notes tenant-local Microsoft/Azure SaaS connectors generally need a workspace in each corresponding tenant [R09]. Do not promise direct cross-tenant collection through a native connector without checking.
5. In Defender, inspect any supported SIEM workspaces and multitenant management capabilities without adding a new tenant. If connecting a secondary workspace is shown as preview, record it as preview and require supported feature/permission checks [R12].
6. If instructor approved, demonstrate a read-only cross-workspace query against two accessible workspaces; replace the placeholders with exact approved workspace IDs. If the tables are not in both workspaces, use a shared common table available in both or mark as unavailable.

// D5-L01 optional: Log Analytics cross-workspace example.
// Replace values only with approved, accessible workspace GUIDs.
union withsource=WorkspaceSource
  workspace('00000000-0000-0000-0000-000000000001').AzureActivity,
  workspace('00000000-0000-0000-0000-000000000002').AzureActivity
| where TimeGenerated >= ago(1d)
| summarize EventCount=count() by WorkspaceSource

7. State clearly: the GUIDs above are fake and the query will not run unchanged. The workspace() form applies to supported Log Analytics cross-workspace queries; Defender unified advanced hunting can have different scoping controls. Document actual syntax used and granted access.
8. Produce an Architecture Decision Record (ADR) with decision, rationale, rejected options, consequences, required validation, owner and revisit triggers.

PASS: ADR justified by at least three genuine constraints, not preference; cross-workspace capabilities honestly described; tenant-bound connector limits acknowledged.
Evidence: D5-L01-workspace-architecture-ADR.md, two topology diagrams. Read: [R09], [R12].

D5-L02 — Design production reference architecture and trust boundaries

Mapped: A16. Outcome: Turn the workspace decision into security-operable architecture.

1. Extend the selected architecture with sources → ingestion path → workspace/tier → detection → incident/case → approved response → audit. Include separate control-plane and data-plane responsibilities.
2. Define a RACI for every component: data-source owner, connector operator, detection engineer, incident responder, platform IAM administrator, compliance owner and FinOps.
3. Identify all cross-boundary flows (region, tenant, team, provider, service principal) and write the specific allowed data elements. If residency requires local storage, centralize only permitted summaries or investigations, not unreviewed full raw logs.
4. For each workspace document region, subscription, resource group, source list, owner, Microsoft Entra access, rule deployment branch, incident routing, retention classification, budget allocation and escalation contact.
5. Perform a threat-model walk-through: excessive access, poisoned data, missing source, unauthorized rule deployment, stale TI, missing audit, cross-region exposure and failed connector token.
6. List explicit operational dependencies: Defender portal access, connector API, AMAs/DCRs (if deployed earlier), Log Analytics, Git authorization, approval provider, Logic Apps and cost-monitoring service.
7. Define a no-single-point-of-knowledge handoff: repository documents, backup operator, runbooks and escalation chain.
8. Review the design with the instructor using these acceptance questions:
   • Can a regional owner restrict raw security evidence without blocking authorized central triage?
   • Can the SOC detect a stopped critical connector?
   • Can a new rule be blocked or rolled back?
   • Can incidents be investigated when the approval system is unavailable?
   • Are data residency and privacy assertions reviewed by the proper authority?

PASS: Architecture diagram, RACI, trust-boundary inventory and at least five design risks with mitigations.
Evidence: D5-L02-reference-architecture.md, D5-L02-boundaries.csv. Read: [R09], [R12].

D5-L03 — Audit Analytics versus Data Lake tier and retention policies

Mapped: A17. Outcome: Protect active detections while selecting retention based on security and governance needs.

1. In Defender > Microsoft Sentinel, navigate to the supported Data management / Tables or connector table management experience. Observe, but do not change, each source table’s analytics retention, total retention, billing plan and last-seen events.
2. Identify which sources feed a real-time analytics rule, workbook, watchlist-based correlation or live investigation. Those inputs require the appropriate interactive Analytics-tier availability. A lake-only change is not a harmless cost toggle.
3. Classify at least five sources using the template:

Source example	Detection critical?	Proposed tier	Analytics retention	Total/lake retention	Legal owner	Why
Privileged identity sign-ins	Yes	Analytics + optional mirrored lake	Policy-defined	Policy-defined	IAM/SOC	Real-time account misuse detection
Security firewall alerts	Yes	Analytics + lake when justified	Policy-defined	Policy-defined	Network SOC	Network correlation
High-volume debug traces	Maybe	Conditional lake-only	Not applicable if lake-only	Policy-defined	App owner	Little real-time detection value
Access evidence / audit	Depends	Analytics for critical subset	Policy-defined	Longer-term per legal need	Compliance	Forensic and legal record
Container platform audit	Yes where used by active rules	Analytics + lake	Policy-defined	Policy-defined	Platform SOC	Change/identity investigation

4. Compare expected availability: Analytics = interactive real-time security features; Data Lake = historical KQL jobs/notebooks and cheaper extended storage, with noninteractive limitations [R02–R03].
5. Check the actual defaults in the current tenant. Microsoft documents 30 days default Analytics retention in certain Defender/Sentinel table contexts, plus 90-day no-extra-charge extension for qualifying Sentinel solution tables; defaults and charges are not identical for every table [R02]. Record what your table settings actually show.
6. Calculate proposed effective detection lookback against retained analytics days. For every rule, its query’s needed data must remain in a suitable tier for scheduled evaluation. Identify at least one rule that would break if a table went lake-only.
7. Conduct a change impact review: data inventory, data-owner signoff, affected queries/rules, historical lookback, billing estimates, rollback behavior and legal hold. Shortening retention could have delayed deletion semantics; do not assume an immediate or instant reversible switch.
8. Optional, only with written approval and an isolated throwaway test table: change a low-value test table’s retention/tier, verify it, then revert through the approved procedure. Never apply the step to live security tables used by Day 4.

PASS: Table-to-detection dependency matrix, selected tiers with defensible rationale, and a list of impacts of lake-only conversion. Live tier change is optional and not required for the conceptual PASS.
Evidence: D5-L03-tier-retention-matrix.csv, D5-L03-dependency-review.md. Read: [R02–R03].

D5-L04 — Assess and optionally onboard the Microsoft Sentinel data lake

Mapped: A17, A18. Outcome: Know exactly what requires tenant-level authorization and prove the lake is actually available before claiming a deployment.

Track 1 — default read-only assessment (safe in any tenant)

1. In Defender, navigate to System > Settings > Microsoft Sentinel > Data lake. Record whether the tenant is already onboarded, the setup button is available, or the panel reports a permission/feature limitation [R04].
2. Confirm the intended Primary SIEM workspace and its region. Do not infer that every additional workspace is automatically included: Microsoft documents extra steps for some workspaces created after lake onboarding.
3. Check the official supported-region list, data-lake role requirements and available billing subscription/resource group. If any is unclear, stop at this read-only checkpoint.
4. Prepare a risk/approval sheet with: billing owner, one-time setup owner, chargeback, resource group, data residency, retention, permissions, cleanup restrictions and operational support contact.
5. Record the expected proof of successful setup: setup status is complete, supported lake exploration appears, access to at least one allowed table is verified and related cost-governance owners know about it. Merely having a menu entry is not enough.

Track 2 — optional approved onboarding (not to be done by ordinary students)

6. Obtain explicit written approval for tenant-level data-lake onboarding and its billing arrangement. The subscription/resource group selection is significant and is not casually movable after setup.
7. Ensure the workspace is connected to the Defender portal and set as Primary SIEM, following the official onboarding prerequisites. Do not proceed using an arbitrary non-primary workspace.
8. In System > Settings > Microsoft Sentinel > Data lake, select Start setup if the tenant is not already onboarded. Choose the approved subscription and resource group and select the documented Set up data lake action.
9. Revisit the settings page to confirm completion. Microsoft notes the operation can take time. Do not repeatedly recreate provisioning resources because the UI has not immediately updated.
10. Open Microsoft Sentinel > Query data lake or the current Data lake exploration entry in Defender. Inspect an allowed table and save a read-only query/result.
11. Record the exact tenant, billing resource group, setup status, table availability and UTC query evidence. If onboarding fails, save the error and stop; do not delete the data lake’s billing subscription/resource group to reset it.

PASS (read-only): Feature eligibility, roles, cost ownership and safe decision documented. Operational PASS: authorized setup shows complete status and a real lake query against approved data succeeds.
Evidence: D5-L04-lake-preflight.md, redacted setup-status screenshot and observed query result if executed.
Troubleshooting: No Start setup → already onboarded, missing roles, unsupported configuration or integration prerequisites; no new table → inclusion/mirroring configuration or propagation delay; query denied → lake role/workspace permissions; region mismatch → review supported geographies.
Read: [R04], [R13].

D5-L05 — Investigate historical telemetry with KQL jobs

Mapped: A18. Outcome: Distinguish interactive exploration from a persisted historical job, and control where results are written.

1. If the lake is already available, open Microsoft Sentinel > Data lake exploration > Query data lake and inspect the table selector. Select a table that contains approved test or non-sensitive data. Do not expect arbitrary Log Analytics custom tables to be present without lake inclusion.
2. Run a read-only KQL aggregation against an available lake table. The following is an example only if AzureActivity is visible; otherwise replace table and fields after confirming actual schema:

// D5-L05: example retrospective query on available lake data.
AzureActivity
| where TimeGenerated >= ago(7d)
| summarize Events=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by OperationNameValue
| top 20 by Events desc

3. Record the query time, source workspace selection, UTC range, number of returned records and which table/columns are present. If zero records, distinguish no matching events from a source not mirrored/ingested or a denied query.
4. Explain the business use case for a KQL job: repeat a historical investigation, summarize high-volume low-fidelity records, scan retrospective indicators or promote only selected results to Analytics-tier tables for further investigation [R14].
5. Before creating any job, check cost, permissions, result destination, table naming, privacy classification and whether the job could reprocess large historical volumes. Running a query and creating a job are separate actions.
6. If approved, open Microsoft Sentinel > Data lake exploration > Jobs > Create job, or Create job from the query editor. Give the job a unique name and description. The documentation states job names may not contain # or -, so use a name such as D5LakeReview<initials> [R14].
7. Choose one-time for the exercise. Select the approved destination workspace and new result table. Confirm that the destination is not a shared existing table and that the columns/time scope are minimized. Some destination types require additional roles; follow the wizard’s exact permission feedback.
8. In the wizard select the intended source workspaces; review the query, destination table schema, UTC window, cost estimate/approval and result classification. Only an instructor with write authorization selects Submit.
9. After execution, open the job status and its destination table. Validate a Succeeded state and the expected records in the destination. New Analytics-tier job tables can use a _KQL_CL suffix, depending on job type [R14].
10. If the organization will not authorize a job, complete a design-only alternative: take a screenshot of the query result, fill in the job specification and state Job not submitted; historical query demonstrated only.
11. Document how to avoid unnecessary large outputs (time bounds, project only needed columns, aggregated results, destination retention). State the handoff plan if historical data must be used to create a new detection in Analytics tier.

PASS: Historical query with explicit time/range and table; job lifecycle described. Operational job PASS: real job status plus output-table records and cost owner documented.
Evidence: D5-L05-kql-job-design.md, query text, optional job ID/output record count.
Troubleshooting: Missing lake table → tier/onboarding; permission denied on destination → role or lake managed identity; job succeeded with zero rows → source/time filter; schema mismatch → adjust output columns; large unexpected cost → stop before resubmission.
Read: [R04], [R14].

D5-L06 — Measure security-data ingestion and form a cost baseline

Mapped: A19. Outcome: Convert telemetry volumes into cost drivers while separating measured usage from estimated price.

1. In Azure Cost Management + Billing > Cost analysis, choose the approved test subscription/resource-group scope. Inspect recent daily costs for Sentinel, Azure Monitor/Log Analytics, Logic Apps, storage and data-lake resources where present.
2. Record the currency, billing account, pricing plan, region, commitment tier, credit/grant and whether the cost line is actual or amortized. Different scopes and contracts can change the numbers; never quote the worked example as an actual Microsoft price.
3. In Defender Table management, use Table insights to inspect ingestion patterns and unusual volumes. Microsoft notes Table insights is not a billing-grade surface; reconcile with Cost Management for monetary conclusions [R02].
4. If the workspace exposes the Log Analytics Usage table, run the following read-only query from the appropriate workspace query context. Validate whether Quantity is in MB for the returned table before converting to GiB:

// D5-L06A: approximate data-volume profile, if Usage exists.
Usage
| where TimeGenerated >= ago(7d)
| summarize UsageMB=sum(Quantity) by DataType
| extend ApproxGiB=round(UsageMB / 1024.0, 2)
| top 20 by ApproxGiB desc

5. If Usage is absent or insufficient, use Table insights and Azure Cost Management exports instead; do not claim zero ingestion from a missing table. Data ingestion estimates from _BilledSize in eligible tables are approximate and not a substitute for the invoice.
6. For a bounded raw-data comparison where the table exposes billing fields, use a schema-confirmed query such as:

// D5-L06B: illustrative table-level size (use only if _BilledSize exists).
AzureActivity
| where TimeGenerated >= ago(1d)
| summarize Events=count(), ApproxGiB=round(sum(_BilledSize)/1024.0/1024.0/1024.0, 4)

7. Reconcile table volume with free/charged data-source distinctions and your actual contract. Some alert and Azure Activity sources have special pricing; raw event types can still be billable [R10]. Do not multiply all ingest by a single rate without checking.
8. Assemble a baseline with these fields: source/table, ingest GiB/day, committed/variable rate, chargeability, analytics retention, lake retention, queries/jobs, Logic Apps executions, business owner and estimated monthly total.
9. List at least three cost risks not captured by raw ingestion alone: lake KQL job compute, longer retention, downstream workflow/API calls, duplicate connectors, cross-region transfer or separate storage/service charges.

PASS: Source volumes, cost scope/currency and estimating assumptions documented; at least one actual observation or explicitly labeled instructor-supplied fixture.
Evidence: D5-L06-cost-baseline.csv, sanitized Azure cost dashboard extract.
Troubleshooting: Usage table empty → use billing or table insights; unexpected fees → separate the Sentinel and Monitor pricing modes; charge discrepancy → currency, daily allocation, free sources and invoice delays. Read: [R02], [R10–R11].

D5-L07 — Build and independently verify a telemetry economics model

Mapped: A19, A20. Outcome: Make cost tradeoffs explainable without relying on fabricated current price lists.

Model inputs (illustrative teaching rates only; NOT Microsoft quotations):

Source	GiB/day total	GiB/day Analytics	GiB/day lake-only	Driver
Identity / high-value access	5	5	0	Active detections
Network activity	40	10	30	Selective alerting, full history
Application diagnostics	25	5	20	Low-priority historical review
Total	70	20	50

Assume for arithmetic teaching only: Analytics ingest $4.00/GiB, lake-only ingest $0.60/GiB, 30-day month, and $0.03/GiB-month incremental historical storage across 90 days of lake-only data. These invented unit rates are not current pricing, and the model intentionally ignores commitment discounts, special source exclusions, mirrored storage inclusion, execution/compute and support costs. They must be replaced with the organization’s approved rate sheet.

# D5-L07 - arithmetic-only model. No cloud access; replace with approved rates.
sources = [("Identity", 5, 0), ("Network", 10, 30), ("Application", 5, 20)]
analytics_gib = sum(a for _, a, _ in sources)
lake_only_gib = sum(l for _, _, l in sources)
month_days = 30
analytics_rate = 4.00  # Illustrative only
lake_ingest_rate = 0.60  # Illustrative only
lake_storage_rate = 0.03  # Illustrative only
lake_retention_days = 90
monthly_analytics = analytics_gib * month_days * analytics_rate
monthly_lake_ingest = lake_only_gib * month_days * lake_ingest_rate
stored_lake_gib = lake_only_gib * lake_retention_days
monthly_storage = stored_lake_gib * lake_storage_rate
print({"analytics": monthly_analytics, "lake_ingest": monthly_lake_ingest,
       "storage": monthly_storage,
       "illustrative_total": monthly_analytics + monthly_lake_ingest + monthly_storage})

Expected illustrative output: Analytics $2,400 + lake ingestion $900 + incremental lake storage $135 = $3,435/month. This is a model only. The storage calculation represents a steady-state approximation and should not be treated as an invoice line.

1. Run the Python snippet locally (or verify with a calculator). Save the inputs and output.
2. Create three scenarios using approved actual rates: current all-Analytics, selected retention/lake split, and risk-averse high-fidelity coverage. Do not assume a lower unit price makes a security-important data source safe to move to lake-only.
3. Perform sensitivity analysis: (a) 2x network data, (b) 30% reduction in app diagnostics through approved filtering, (c) longer regulatory retention. Show costs and detection implications.
4. Include pipeline/test costs such as KQL jobs, connector/API operations and Logic Apps, clearly as separate assumptions.
5. Add governance guardrails: daily ingest anomaly alert, forecast threshold, per-source owner, quarterly retention review, rate-plan approval and exception records.

PASS: Reproducible spreadsheet/arithmetic, three scenarios, at least one documented security-coverage tradeoff and a financial disclaimer.
Evidence: D5-L07-telemetry-model.md or .csv generated by learners (the manual itself remains one MD). Read: [R10–R11].

D5-L08 — Prioritize telemetry by detection value; prevent accidental blind spots

Mapped: A20. Outcome: Save cost only when observable security coverage and policy remain acceptable.

1. List sources by threat scenarios they actually support (privileged access, persistence, lateral movement, business-application fraud, exfiltration and infrastructure change), not merely by GiB/day.
2. For each candidate reduction, identify the exact analytic rule, hunting query, workbook or compliance control that depends on the table or field.
3. Classify three cost actions: (a) eliminate confirmed duplicate collection, (b) filter unnecessary low-value messages at the approved ingestion transform/source, (c) change retention/tier only after a dependency and legal review.
4. Explicitly reject changes that would remove necessary event IDs, timestamps, actor/target distinction or privileged event records from an active detection. A lower log bill is not a win if it creates unmonitored high-risk access.
5. Propose before/after verification: same synthetic attack fixture, expected source event counts, row parsing fidelity, rule outputs, workbook observations, missed-event check and cost change.
6. Record a control owner’s written decision and rollback condition for each proposed filter. Do not deploy these changes to production during training.

Candidate change	Benefit	Potential security loss	Approval / test
Eliminate proven duplicate connector	Reduced noise and billing	May lose independent backup feed	Validate source lineage
Filter verbose debug info	Lower low-value volume	May remove forensic context	App/SOC signoff and regression
Move high-volume firewall traffic lake-only	Cheaper retention	Could break active detection	Reject unless active subset remains
Shorten regulatory audit retention	Storage savings	Legal/compliance violation	Legal authority required

PASS: An explicit coverage-cost matrix, one rejected unsafe optimization and a rollback plan.
Evidence: D5-L08-coverage-cost-ADR.md. Read: [R02], [R10–R11].

D5-L09 — Package a proven analytics rule as supported content-as-code

Mapped: A21. Outcome: Store a working Day 4 rule in an auditable ARM/Bicep source-controlled form without introducing a made-up deployment specification.

1. Select the validated lab analytics rule preserved from Day 4. Verify its name starts with D4-LAB- (or your approved equivalent), source tables are permitted and the query has a bounded lookback. Capture current rule ID, severity, enabled state, owner, workspace and known-good test cases.
2. In Defender Microsoft Sentinel > Configuration > Analytics, select the test rule. Select Export if offered. Microsoft documents export of analytics rules to ARM JSON, but the export/import feature is described as Preview; if it is absent, do not claim it works in your tenant [R15].
3. Place the downloaded Azure_Sentinel_analytic_rule.json (or actual exported filename) into a private, authorized test repository, for example sentinel/analytics/aster-lab-rule.json. Do not commit confidential production queries or incident identifiers.
4. On your local computer, check that the exported file is valid JSON using standard Python, which needs no Azure login:

# Replace with the exact exported filename. This does not deploy anything.
python3 -m json.tool sentinel/analytics/aster-lab-rule.json >/dev/null

5. Run this structural inspection, changing only the filename. It checks JSON structure, not whether Azure accepts the API model:

import json
from pathlib import Path
path = Path("sentinel/analytics/aster-lab-rule.json")
obj = json.loads(path.read_text(encoding="utf-8"))
assert isinstance(obj, dict), "Expected ARM template object"
assert isinstance(obj.get("resources"), list), "Missing ARM resources array"
assert obj["resources"], "No resources to deploy"
print("Schema:", obj.get("$schema", "MISSING"))
for r in obj["resources"]:
    print("Type:", r.get("type"), "Name:", r.get("name"),
          "API version:", r.get("apiVersion"))

6. Inspect the file for actual workspace name, location, IDs, analytic query, entity mappings, ATT&CK tags, incident grouping, schedule, alert threshold and enabled flag. Some exports contain generated IDs and parameters that require environment-specific adaptation. Prefer disabled status for the initial sandbox deployment where supported; never copy a production-enabled rule into a second environment without review.
7. Create a README.md in the repository explaining what the rule detects, required source tables, tenant/workspace assumptions, scope, owner, severity, safe test fixture, known false positives and rollback.
8. Use the officially documented Sentinel repository sample content to compare file format and folder content. The repository supports ARM JSON and Bicep, but their structure depends on content type [R05–R06]. Do not rename a raw KQL file to .bicep or assume arbitrary YAML is deployable.
9. Optional Bicep conversion: Microsoft warns that Bicep does not support exported id properties in the same way, and recommends compatible ARM schema adjustment before decompilation. If using az bicep decompile, inspect and correct the generated template against the official resource reference; compilation success alone is not deployment validity [R06].
10. Commit the test template and report to a feature branch, not directly to a production-synchronized deployment branch. Require reviewer approval and security/owner signoff.

PASS: The exact tested rule has a valid JSON export or appropriately attributed official sample, a source-control commit, documented source prerequisites and a safety-reviewed deployment plan. Operational deployment PASS requires the later repository integration lab.
Evidence: D5-L09-content-package.md, Git commit hash, JSON validation output, PR.
Troubleshooting: No Export → preview/permission/portal limitation; missing parameters → inspect exported schema; portal-only edits not in Git → reconcile before release; Bicep id errors → consult Microsoft conversion rules.
Read: [R05–R06], [R15].

D5-L10 — Create a governed GitHub/Azure DevOps repository deployment path

Mapped: A21, A22. Outcome: Verify promotion, approval, drift and rollback using one nonproduction Sentinel workspace.

Part A — Source-control workflow

1. Choose a supported GitHub or Azure DevOps test repository. Require a protected default/production branch; reviewers should not be the sole author of their own production changes.
2. Use a simple structure, adapted to the organization’s selected supported content model:

sentinel-content/
  README.md
  analytics/
    aster-lab-identity-rule.json
  tests/
    detection-test-matrix.md
  governance/
    owners.md
    change-record-template.md
    rollback.md

3. Add validation to the pull request, not just a post-deployment check: JSON syntax; schema/resource-type review; KQL source validation in approved test workspace; fixture results; no secrets; expected rule name; enabled/disabled plan; reviewer approval.
4. For a basic local precommit check, run:

# Example only after creating the above directory and exported JSON.
python3 -m json.tool analytics/aster-lab-identity-rule.json >/dev/null
# If Azure CLI is installed, inspect it before any authenticated deployment:
az version

5. Optional ARM deployment validation in authorized sandbox only: inspect the exported template for its actual parameter names; construct an appropriately matching parameters.sandbox.json file and verify the resource group. The following shell is a template and will not run correctly until all placeholders and parameters match your exported resource:

# DO NOT RUN until RG, TEMPLATE and PARAMETERS are reviewed and approved.
RG="<approved-nonproduction-resource-group>"
TEMPLATE="analytics/aster-lab-identity-rule.json"
PARAMETERS="parameters.sandbox.json"
az account show --output table
az deployment group validate --resource-group "$RG" \
  --template-file "$TEMPLATE" --parameters @"$PARAMETERS"
az deployment group what-if --resource-group "$RG" \
  --template-file "$TEMPLATE" --parameters @"$PARAMETERS"

6. Save the what-if changes as review evidence. If an unexpected workspace/rule/RBAC or potentially destructive change appears, stop. Do not let automatic merge/deployment bypass this gate.

Part B — Sentinel Repositories integration (instructor-operated, permission-dependent)

7. Verify the instructor has Owner on the Sentinel workspace resource group and appropriate repository authorization; GitHub collaborator or Azure DevOps project administration. Microsoft requires connections from a supported home-tenant account rather than an unsupported B2B external identity [R05].
8. In Defender, navigate Microsoft Sentinel > Content management > Repositories > Add new. Give the connection a lab-specific name and select GitHub or Azure DevOps.
9. Select Authorize, choose the explicitly approved repository and sandbox branch, and limit Content Types to the intended Analytics rules. For GitHub, review the app installation scope; do not grant organization-wide access if only the test repo is required.
10. Create the connection. Microsoft states a workflow/pipeline is generated in the repository to deploy supported content. In GitHub check Actions, or in Azure DevOps check Pipelines; capture the workflow name, job status, commit and deployment logs [R05].
11. Check the Sentinel Analytics page for the created/updated test rule and inspect its enabled state, ID, query and owner. No rule or a failed pipeline = not deployed, even if the repository connection exists.
12. Commit a safe, reviewed change (for example the description or a documented lab-only detail), merge via PR and observe the deployment job and new rule value. Record commit-to-deployment traceability.
13. Never edit the same managed rule directly in the portal without reconciling the Git version: repository synchronization can overwrite portal edits. Demonstrate this as a design discussion unless the instructor explicitly authorizes a controlled drift test.
14. Demonstrate rollback via reverting the change in Git, review/merge again and verify the expected previous rule state. Note: deleting the file from Git does not delete the deployed Sentinel content; removing a managed resource requires a separate, controlled deletion in Sentinel [R05].
15. At the end, disconnect the lab repository only if the owner authorizes it. The previously deployed content remains in Sentinel and must be managed explicitly. Remove the generated GitHub workflow / repository app grant only after checking dependencies.

Troubleshooting and release gate

Failure	Check first	Safe response
Connection not offered	Owner/home tenant/repository auth	Request correctly scoped admin assistance
Pipeline failure	GitHub Actions/Azure DevOps logs	Fix schema/permissions; do not retry production blindly
Export decompile fails	Unsupported id, schema, API version	Follow official Bicep conversion guidance
Rule created with unexpected state	Template and branch/environment parameters	Disable and revert; stop promotion
Code changed but rule unchanged	Workflow trigger, branch or content-type selection	Trace commit → pipeline → deployment
Portal edit disappears	Repository is source of truth	Reinstate via reviewed Git change
Git file removed, rule remains	Documented retention of deployed resources	Separate authorized Sentinel cleanup

PASS (local): Validated source artifact, branch/PR/review and rollback plan. Operational PASS: repository connection, workflow/pipeline success, actual rule state, safe change and verified rollback.
Evidence: D5-L10-ci-cd-release-record.md, commit IDs, run links and redacted rule state.
Read: [R05–R06], [R15].

D5-L11 — Implement production release governance and separation of duties

Mapped: A22. Outcome: Translate Git operations into auditable security change control.

1. Create a release checklist that cannot be satisfied by commit count alone. It must verify: source/table availability, KQL performance, expected cases, false-positive tests, entity mappings, MITRE technique claims, owner, cost impact, workspace scope and a safe off switch.
2. Design a four-stage flow: Author branch → PR validation → approved test deployment → separate production approval. Avoid production auto-deploy from feature branches.
3. Assign roles for each approval: detection maintainer, security engineering reviewer, data owner where schema changes, release approver, FinOps if collection/retention changes, SOC on-call if alert volume changes.
4. Write a sample change record:

Change ID: CHG-D5-LAB-001
Business driver: Reduce false alerts for legitimate scheduled role grants
Rule ID and commit:
Affected workspace(s): LAB ONLY
Required tables and expected latency:
Threat detection / ATT&CK statement:
Positive and negative regression test IDs:
Risk and customer impact:
Expected alerts/day and cost impact:
Required reviewers and approvals:
Deployment/rollback owner:
Rollback to commit:
Validation window and evidence URL:

5. Conduct a mock review with the instructor acting as change authority. Present one deliberately flawed PR (for example no test fixture, broad workspace targeting or enabled containment action). The reviewer should reject it and document why.
6. Prepare a rollback plan that states who can revert the commit, how the previous deployed rule ID/state is validated, how duplicate alert generation will be detected and when SOC analysts are informed.
7. Test a nonproduction revert only if approved. Record evidence; a Git revert button clicked without observing downstream rule state does not prove recovery.
8. Discuss change evidence retention and access restrictions according to the organization’s real policies. Do not invent universal regulatory periods.

PASS: A signed example change record, negative PR review, incident-aware rollback and independent production release approval gate.
Evidence: D5-L11-change-record.md, D5-L11-release-checklist.md. Read: [R05–R06].

D5-L12 — Enable and interpret SentinelHealth and SentinelAudit

Mapped: A23. Outcome: Detect actual operational failures and control drift rather than treating UI availability as health.

Part A — Enable monitoring with permission

1. In Defender choose System > Settings > Microsoft Sentinel, then select Auditing and health monitoring. Review whether it is already enabled and whether you can view its configured diagnostic settings [R07].
2. If not enabled, the instructor first confirms the lab workspace and approval for any billable audit logs. Select Enable only in the approved environment. The product configures diagnostic settings for supported resources; otherwise use the documented Configure diagnostic settings path with explicit categories/destinations.
3. Record the enabled resource types: analytics rules, selected supported data connectors, automation rules and playbook launch health where supported. Not every connector has a SentinelHealth integration. Microsoft currently documents analytics-rule resource type for auditing; do not claim arbitrary changes to every Sentinel object are audited there [R07].
4. Explain the distinction: SentinelHealth tracks relevant Sentinel resource health and whether workflow launch succeeded; SentinelAudit records supported administrative changes; Logic Apps internal action details require Logic Apps run history/diagnostic logs [R08].

Part B — Query real events; absence is not immediate failure

5. Go to Investigation & response > Hunting > Advanced hunting using a Sentinel workspace-aware query context. Run the Microsoft-recommended compatibility wrappers:

// D5-L12A: supported Sentinel health function
_SentinelHealth()
| take 20

// D5-L12B: supported Sentinel audit function
_SentinelAudit()
| take 20

6. Check schema and event types in actual results; then adapt a bounded summary using fields confirmed in your environment, rather than asserting table columns that are not present.
7. If tables/functions are empty, perform a safe, approved lab rule metadata change or a controlled automation test and allow normal ingestion time; recheck. The tables may be created only after the first supported event. A zero-row result alone is not proof monitoring failed.
8. For a data-connector issue, compare health evidence with the last successful real source event. Source-health telemetry does not replace source-level event integrity checks.
9. For an analytics-rule failure, compare health records with rule execution/alert results. For a playbook failure, match automation-launch records with Logic Apps > Run history; if diagnostic export is configured, inspect the appropriate Logic Apps diagnostic table.
10. Define a production monitoring rule/runbook: if a critical source has not reported for an agreed interval, or a critical analytic rule fails, alert the owner and triage a ticket. Pick thresholds from measured normal behavior, not arbitrary alert counts.

Part C — Simulated outage worksheet

Simulated symptom	Evidence to collect	Likely owner	Action / PASS condition
Collector silent	Last raw log, connector health, DCR/AMA where relevant	Platform	Document ingestion break and restore proof
Analytics execution failure	Rule execution health and query dependencies	Detection engineering	Restore query; verify next successful run
Playbook launch succeeds, action fails	SentinelHealth + Logic Apps run history	SOAR engineer	Repair failed action; do not claim healthy merely from launch
Unauthorized rule edit	SentinelAudit change record and repository drift	Release owner	Reconcile Git, tighten RBAC
Monitoring functions empty	Settings, diagnostic categories, event existence	Sentinel admin	Generate safe event; confirm telemetry

PASS: Monitoring enabled or a documented read-only alternative; actual health/audit query outputs if the tenant supports them; an outage triage explanation grounded in two separate evidence sources.
Evidence: D5-L12-health-audit-report.md, sanitized query results, runbook.
Read: [R07–R08].

D5-L13 — Define SOC KPIs and investigate service-level performance

Mapped: A24. Outcome: Build a useful scorecard while distinguishing observed facts from estimated security outcomes.

1. Define the scope of the SOC service: monitored environments, critical sources, response teams, case severity policy and reporting period. A KPI without a stable denominator or accountable owner invites misleading comparisons.
2. Agree on these definitions and data sources before computing values:

Measure	Operational definition	Required proof / limitation
Ingestion availability	% of required source/table intervals with delivered expected events	Connector health and source freshness; not UI green alone
Detection execution reliability	Successful scheduled evaluations / expected evaluations	Rule/health execution evidence
Detection coverage	Threat scenarios with an observed detection and tested source	ATT&CK label does not equal effective coverage
Alert precision proxy	Known confirmed true positives / all reviewed positive alerts	Labeling quality; misses and uninvestigated alerts bias
MTTD	Time from confirmed malicious activity onset to valid detection	Ground-truth starting event is often unknown
MTTA	Time from alert/incident available to acknowledged ownership	Requires reliable assignment/acknowledgment event
MTTR	Time from qualified incident open to approved closure/recovery	Define clock start/stop and exclusion rules
Escalation SLA	% of cases escalated within severity-specific policy	Audit timestamps and severity classification
Automation success	Completed correct workflow actions / attempted relevant runs	Must use Logic Apps run history for internal actions
Data cost per relevant detection	Governed telemetry/service spend / actionable outcomes	Never optimize by suppressing incidents artificially

3. In the appropriate Sentinel Log Analytics query context, verify that the workspace exposes the SecurityIncident table and schema. It may have multiple snapshots per incident; naïve counting over rows inflates volume.
4. Run a bounded latest-snapshot count only where SecurityIncident is available:

// D5-L13A: latest incident state, not raw row count.
SecurityIncident
| where TimeGenerated >= ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| summarize Incidents=count() by Status, Severity
| order by Incidents desc

5. Validate the CreatedTime and ClosedTime fields in your schema before estimating closed-incident duration. This is elapsed case duration, not necessarily true remediation time or time to eradicate an attack:

// D5-L13B: optional approximation only when CreatedTime/ClosedTime exist.
SecurityIncident
| where TimeGenerated >= ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| extend Created=todatetime(column_ifexists('CreatedTime','')),
         Closed=todatetime(column_ifexists('ClosedTime',''))
| where isnotnull(Created) and isnotnull(Closed) and Closed >= Created
| extend CaseDurationHours=datetime_diff('minute', Closed, Created) / 60.0
| summarize ClosedCases=count(), MeanCaseHours=round(avg(CaseDurationHours),2),
            MedianCaseHours=round(percentile(CaseDurationHours,50),2)

6. Compare the above metrics to three fictional historical monthly periods supplied by the instructor. Decide whether the SOC is improving and identify confounders: severity mix, source onboarding, policy changes, case grouping, staff shifts and improved detection (which can temporarily increase alert counts).
7. Build a small scorecard covering: source freshness, high-risk rule execution, critical incident escalation, approval-workflow failures, ingestion cost trend and improvement backlog. Assign owner, target, observation interval and action threshold to each.
8. In Defender, read-only, inspect any available SOC optimization recommendations. Compare the recommended coverage/data-value improvements with your actual source and rule inventory; a recommendation or coverage tag does not prove detection effectiveness. Record the limitations of this signal [R16].
9. Produce a sample monthly SOC operating review: three verified findings, two suspected drivers, one measurable corrective action and a date/owner to validate success.
10. Do not use a synthetic D4 event as evidence of real MTTD/MTTR. Make confidence and missing data explicit.

PASS: A metric dictionary with owners/denominators, latest-snapshot incident KQL if available, at least one caution about biased KPIs, and an actionable review.
Evidence: D5-L13-soc-kpi-dictionary.md, D5-L13-review.md. Read: [R07–R08], [R16].

D5-L14 — Prepare the Sentinel-to-Defender portal modernization plan

Mapped: A25. Outcome: Inventory actual features, role gaps and workflows ahead of the Azure-portal cutoff.

1. Record the official target: Microsoft says the Sentinel Azure portal experience stops being supported after March 31, 2027; use Defender as the standard training portal [R01]. Do not interpret this as Azure portal being retired for Azure resources generally.
2. Inventory the existing SOC functions: incident queue, hunting, workbooks, content hub, analytics, automation, connectors, data management, entity pages, TI, repository connections and integrations with ticketing.
3. Verify where each feature is available in the actual tenant. Microsoft publishes a portal navigation mapping; do not invent new UI paths for features not shown or not licensed.
4. Record permissions separately: Azure RBAC, Defender unified RBAC and roles used by a connector or playbook. A user may be able to query logs without being allowed to manage a detection or run a workflow.
5. Create a migration/modernization acceptance matrix:

Workflow	Current path	Defender path tested?	Permission impact	Gap/owner
Incident triage	Prior team practice	Yes/No	Sentinel/Defender response roles
Hunting queries	Old query surface	Yes/No	Workspace scope / license
ASIM parser queries	Workspace Log Analytics	Yes/No	Query context and function visibility
Automation/playbooks	Portal and Logic Apps	Yes/No	Trigger, case vs incident, service account
Workbooks	Azure resource	Yes/No	Workbook reader/contributor
Content-as-code	Repository connection	Yes/No	Home-tenant and repo scopes
Data lake	No old equivalent / current support	Yes/No	Onboarding/roles/region

6. Test one saved hunt and one lab incident end-to-end in the Defender portal. If a legacy feature is not available in Defender, record the supported alternative and its transition plan; for example, creation of traditional hunting bookmarks is not supported there [R01].
7. Write a change-control plan: owner; named pilot users; training; preserved dashboards/query links; ticket system; access review; communications; rollback/contingency; cutover acceptance checklist.
8. Have a SOC analyst other than the author reproduce a workflow without instructor prompting. Capture navigation differences and update standard operating procedures.

PASS: Complete feature/permission inventory, one pilot user test, at least one explicitly documented gap and signed rollout criteria.
Evidence: D5-L14-portal-modernization-plan.md. Read: [R01], [R12].

D5-L15 — Run an operational resilience and governance game day

Mapped: A26. Outcome: Keep the SOC functioning during dependency failures without making unsafe changes.

1. Identify five critical dependencies: source telemetry, Sentinel workspace/query availability, repository deployment system, incident/ticket system, approval provider / Logic Apps execution.
2. Choose one tabletop fault and one read-only evidence exercise. Suggested tabletop: a high-severity identity signal appears while the Git deployment pipeline is failing and the approval connector is unavailable.
3. Declare a fictional severity and preserve the incident commander and approver roles. Decide whether analysis continues manually, whether additional containment is authorized, and what evidence must be saved.
4. Review the runbooks to locate: backup SOC contacts, permission break-glass process, safe manual-only response, evidence custody, query/access audit, last validated detection version and ticket recovery procedures.
5. Run a read-only health or incident query if access is available. Do not disable real connectors, deny network traffic, corrupt logs or break service availability to manufacture the failure.
6. Write a chronology with UTC checkpoints: simulated outage start, first detection, escalation, manual workaround, dependency restored and after-action owner. Label timestamps as exercise values.
7. Define preservation rules: query text and scope, event IDs, redacted incident evidence, chain-of-custody owner and applicable retention/legal hold. Retention periods are organization-specific; get legal signoff before stating numeric periods.
8. Inspect a sample IAM access-review sheet: identify a departed engineer with retained write rights and an automation connection tied to a personal account. Design least-privilege remediation and approval; do not modify real access in this exercise.
9. Conduct an after-action review and capture three concrete improvements with owner, validation evidence and target date. One must improve recovery from a missing telemetry source, and one must improve change/approval resiliency.

Inject	Expected safe behavior	Evidence
Connector stops	Mark visibility gap, notify source owner, use retained evidence	Last log timestamp + owner ticket
Repository pipeline fails	Freeze promotion, use last known good, review PR/log	Git run and rule version
Approval provider unavailable	No automated disruptive action; manual authorization policy	Stop/timeout run record
Region/tenant access restricted	Follow legal + operations boundaries	Access matrix / escalation
Cost spike	Investigate volume and source before dropping data	Usage and business impact

PASS: Tabletop incident log, safe decision record, access-review worksheet, three action items and an owner for each.
Evidence: D5-L15-resilience-exercise.md, D5-L15-improvement-backlog.md. Read: [R07–R09], [R16].

D5-L16 — Present and defend the integrated enterprise capstone

Mapped: A27; uses A15–A26 decisions and Day 4 validated detection/playbook as prerequisites. No reteaching of earlier modules.

Capstone problem

Aster Retail has a central SOC, regional subsidiaries, long-term evidence requirements and limited logging budgets. A fictional high-privilege identity incident has already been investigated in prior labs. Leadership wants a proposal that provides reasonable source visibility, defensible residency boundaries, controlled detections, approved response, auditable releases, historical investigation, meaningful SOC KPIs and a tested fallback when a dependency is unavailable.

Required final deliverables

ID	Deliverable	Must explicitly answer
C01	Architecture decision record and diagram	Why this many workspaces/tenants; who owns each boundary?
C02	Telemetry classification and tier matrix	Which sources need real-time analytics; how long and why?
C03	Historical-investigation plan	Which lake job, permission, cost and destination?
C04	Telemetry cost model	Rates/assumptions, alternative scenarios, detection impact and guardrails
C05	Detection-as-code PR and test evidence	Source format, validated rule, commit, review, test deploy or disclosure of no deploy
C06	Change and rollback record	Who may approve, who deploys, how to observe/undo?
C07	Health and incident-quality evidence	Source/rule/automation health and responsible KPIs
C08	Portal and resilience action plan	Feature gaps, 2027 transition, dependency failures and runbooks
C09	Day 4 artifact handoff	Validated hunt/detection and guarded playbook—reference, do not reproduce course
C10	Executive-style conclusion	Tradeoffs, remaining risks, owner, next verification

Capstone presentation and challenge questions

1. Explain why the design does not unnecessarily multiply workspaces; cite residency, tenure, ownership and query constraints.
2. Defend which security-sensitive event table must not be lake-only because an active detection needs it.
3. Explain how a lake job’s result is consumed and what role/charge applies; do not claim lake-only data powers NRT rules.
4. Demonstrate a Git commit, PR checks and deployment/audit trail—or label the demonstration design-only and state the missing gate.
5. Explain how to roll back a noisy detection without deleting an entire workspace, suppressing evidence or silently losing source logs.
6. Compare the predicted cost change with the measured source usage, and disclose uncertainty in pricing assumptions.
7. Walk through the simulated failure of the approval system: who can act manually and which actions must stop?
8. Present one KPI that improves actual detection quality and one KPI that can be misleading if reported alone.
9. Identify the three highest unresolved risks and a named validation owner for each.

Scoring rubric (100 points)

Competency	Points	Minimum acceptable evidence
Workspace, tenant and trust-boundary architecture (A15–A16)	15	Regional/data/identity constraints and owned decision record
Data tiers, historical jobs and retention (A17–A18)	15	Live-detection dependency protected; historical method/cost specified
Economics and optimization (A19–A20)	15	Reproducible model; actual vs illustrative rates distinguished; no coverage loss
Detection-as-code / release governance (A21–A22)	20	Reviewed artifact, test deployment evidence or truthful blocked status, rollback
Health, audit and SOC operating metrics (A23–A24)	15	Health and workflow-run distinction; metrics with definitions/owners
Portal modernization and resilience (A25–A26)	10	Defender readiness plan and non-destructive failure exercise
Integrated capstone defense and evidence integrity (A27)	10	Traceable decisions, open risks and transparent limitations
Total	100

Suggested program completion: At least 80/100, with mandatory safety PASS for scope control, no unapproved tenant-wide/production changes, no retention changes that break active detections, documented repo rollback and truthful deployment status. This is a course-defined assessment, not a Microsoft-issued credential. Allow a supervised remedial attempt and document the re-test.

---

Day 5 operator checklists and templates

Final 5W1H oral assessment

Ask each learner to answer the following with reference to their own artifacts:

1. What production services and data tiers actually exist in the chosen architecture?
2. Why is the workspace split justified, and what cost/complexity does it add?
3. Who owns source collection, detection changes, cost, incident triage and governance?
4. When may a table become lake-only, and when must it remain detection-ready?
5. Where do billing decisions, code changes, incidents, logs and approvals live?
6. How would you validate a new rule, recover from a failed deployment and investigate a missing high-priority log source?

Syllabus coverage audit — Day 5 only

Each capability below is new instruction on Day 5. Previously validated detections and playbooks are reused as inputs, not retaught.

Syllabus ID	New advanced competency	Primary hands-on evidence
A15	Multiworkspace and tenant choices	D5-L01 workspace ADR
A16	Production reference architecture	D5-L02 topology, RACI and boundaries
A17	Analytics/data lake tier tradeoffs	D5-L03–L04 retention/onboarding evidence
A18	Historical analytics and KQL jobs	D5-L05 job specification or observed run
A19	Security-data economics	D5-L06–L07 baseline and rate model
A20	Optimization versus security coverage	D5-L07–L08 alternatives
A21	Detections/content as code	D5-L09–L10 exported rule and Git evidence
A22	Change/promotion governance	D5-L10–L11 PR and approval record
A23	Health and audit	D5-L12 SentinelHealth/SentinelAudit checks
A24	SOC metrics and SLAs	D5-L13 KPI review
A25	Defender portal modernization	D5-L14 inventory and pilot
A26	Governance and resilience	D5-L15 game-day and runbooks
A27	Final enterprise capstone	D5-L16 final presentation and rubric

Instructor oral-check answer guide

• Analytics vs lake-only: Keep active-detection dependencies in a supported interactive tier. Lake-only historical storage alone does not supply the same NRT/interactive features.
• Workspace design: Split for defensible residency, ownership, tenancy or RBAC needs; minimize fragmentation otherwise.
• Repository truth: A successful Git commit is not a successful deployed rule. Verify the pipeline and actual workspace rule; Git deletion does not automatically delete deployed content.
• Costs: Use a current region/contract rate card, identify free sources, commitment, retention and workflow costs, and distinguish forecast from invoice.
• Monitoring: SentinelHealth launch success does not prove every Logic Apps action succeeded. Query a supported health event and inspect actual run history.
• MTTD: Cannot reliably compute true attacker onset without independent ground-truth data. Incident creation is not automatically the same as first malicious action.
• Resilience: If approval or telemetry dependency fails, stop unsafe automatic actions and use documented escalation/incident commander authorization.

Final evidence checklist

• [ ] D5-L00 preflight, authorized tenant/workspace and disabled unsafe automation
• [ ] D5-L01 workspace/tenant ADR
• [ ] D5-L02 production reference architecture, RACI and boundaries
• [ ] D5-L03 retention/tier dependency matrix
• [ ] D5-L04 lake eligibility + approved setup status or read-only alternative
• [ ] D5-L05 historical query + job output or honest no-submit substitute
• [ ] D5-L06 source usage and billing-scope baseline
• [ ] D5-L07 reproducible cost scenarios with illustrative-rate disclaimer
• [ ] D5-L08 detection-quality-preserving optimization recommendations
• [ ] D5-L09 exported rule / valid source artifact + test specification
• [ ] D5-L10 Git PR, test pipeline/rollback evidence or explicitly blocked status
• [ ] D5-L11 change-control record and release/rollback plan
• [ ] D5-L12 _SentinelHealth() / _SentinelAudit() evidence or documented missing data
• [ ] D5-L13 metric definitions, owners, and a bounded operational review
• [ ] D5-L14 Defender portal transition and permission inventory
• [ ] D5-L15 resilience tabletop and after-action backlog
• [ ] D5-L16 enterprise capstone score and safety signoff

Cleanup (do not delete shared workspace, lake billing resources or Git history)

1. Confirm all automatic lab responses remain disabled and no scheduled test playbooks or KQL jobs will continue incurring costs unexpectedly.
2. Disable or remove only owned, temporary analytics rules in the dedicated training workspace; preserve intentionally reused rule versions for instructor review.
3. Disconnect a sandbox repository connection only if the workspace/repository owner authorizes it. Content already deployed is not automatically removed when you disconnect or delete a repo file.
4. Disable temporary test KQL jobs or schedules, then remove temporary output tables only with the data owner and retention approval. Deleting a historical table may destroy evidence.
5. Preserve the tenant’s data lake and billing resource group unless a separate supported decommission plan exists. Do not delete a data-lake resource group as a classroom cleanup shortcut.
6. Remove temporary principal role assignments via the actual IAM owner. Do not remove inherited access or break shared alerting.
7. Reconcile Azure Cost Management, table ingestion trends, Logic Apps run costs, repository workflow consumption and any new storage/job charges once they become billable/visible.
8. Save sanitized final artifacts in an approved repository or training evidence store; respect confidentiality and organization-specific retention/hold requirements.
9. Write a signed final state record with every retained resource, disabled feature, outstanding cost/permission risk, owner and next review date.

Common failure patterns — triage without guessing

Symptom	What it means may be wrong	Required investigation	Safe alternate
Secondary workspace absent in Defender	Workspace/feature integration or permissions	Primary/secondary workspace support, tenant and RBAC	Architecture worksheet
Lake onboarding unavailable	Wrong primary workspace, role, region or already onboarded	Data lake settings and official prerequisites	Read-only tier study
Lake query returns 0	Data absent, not mirrored, time filter or lake availability	Source table, tier configuration and time window	Instructor-supplied fixture
KQL job won’t write table	Data lake identity/workspace contributor or schema mismatch	Destination and job error details	Job design spec
Costs differ from estimate	Incorrect rates, dates, currency or data chargeability	Billing export, commitment, free sources	Show assumptions, no fabricated invoice
Analytics rule disabled after deployment	Template parameters, mismatch or deliberate safety state	Git/ARM file, release record, rule status	Do not force-enable
Git commit doesn’t deploy	Branch, content type, workflow or authorization	Actions/Pipelines logs → deployment details	Review-only PR
Repo file deletion leaves rule	Intended repository behavior	Controlled Sentinel rule removal	Document the limitation
Health table empty	No event, monitoring disabled or wrong scope	Settings and safe event generation	Monitoring runbook design
SOC metric counts too high	Multiple SecurityIncident snapshots	arg_max() latest state per incident	Offline fixture with proper denominator
Playbook launch says success but action failed	SentinelHealth ≠ full Logic Apps execution	Inspect Logic Apps run history	Fault-analysis case study
Unauthorized cross-tenant view	Insufficient or overly broad delegation	Review actual role/trust boundary with IAM	RACI / legal review

Explicit verification ledger — no invented cloud PASS claims

Review area	Checked for this manual	Requires live tenant test
Source agenda scope A15–A27	Mapped all competencies to labs	Instructor confirms delivery focus
Current documentation	Cross-checked official Microsoft Learn in November 2026	Refresh before class as docs evolve
Markdown structure and static examples	Validated locally	Learner reproduces environment-specific commands
Illustration/cost arithmetic	Deterministic example; not actual pricing	Replace with contract/region rates
Enterprise workspace selection	Design exercises grounded in documented constraints	Actual tenant/region/RBAC verification
Data-lake onboarding	Documented procedural path only	Not executed — requires approval
KQL jobs and output table	Documented steps and sample query	Not executed — requires data and roles
Repository-based deployment	Documented workflow, JSON syntax check example	Not executed — requires approved repo and auth
Health/audit KQL	Uses Microsoft-supported compatibility functions	Not executed — enable and generate real event
PowerPoint/course integration	Prior training artifacts are stated prerequisites	Verify continuity from instructors’ actual Day 4 outputs

Source register — official Microsoft documentation

Source labels correspond to references cited in individual labs. Accessed for research on 1 November 2026. Feature status, licensing, menu labels, costs, regions and APIs must be rechecked before a live class.

• [R01] Microsoft Sentinel in the Microsoft Defender portal and 2027 transition
• [R02] Manage Analytics/Data Lake tiers and retention
• [R03] Microsoft Sentinel data lake overview
• [R04] Onboard to the Microsoft Sentinel data lake from Defender
• [R05] Deploy content as code from a Sentinel repository
• [R06] Manage source-controlled custom content; ARM/Bicep formats
• [R07] Enable Sentinel auditing and health monitoring
• [R08] SentinelHealth/SentinelAudit interpretation
• [R09] Plan multiple workspaces and tenants
• [R10] Sentinel pricing and billing
• [R11] Reduce Microsoft Sentinel costs
• [R12] Set up multiple workspaces and tenants
• [R13] Data lake geographical availability and residency
• [R14] Create KQL jobs in Microsoft Sentinel data lake
• [R15] Import and export Sentinel analytics rules
• [R16] Optimize security operations (SOC optimization dashboard and recommendations)

End of standalone Day 5 manual. The program’s advanced completion gate is an evidence-backed enterprise capstone, not attendance or unverified portal screenshots.