Day 4 Wrap-up — Runtime Monitoring and Threat Detection
Day 4 Wrap-up — Runtime Monitoring and Threat Detection
Today we built a runtime monitoring stack on top of the infrastructure we deployed in previous days. The pipeline now sees not just how code is deployed, but what happens after deployment.
What We Covered
The three pillars of Day 4 are monitoring (collecting data), detection (finding threats in the data), and response (acting on what you find).
| Pillar | Tools | Purpose |
|---|---|---|
| Monitoring | Diagnostic Settings, App Insights SDK | Collect data from application, platform, and management planes |
| Detection | Sentinel analytics rules, hunting queries | Find threats in the collected data |
| Response | Incidents, workbooks, playbooks (SOAR) | Investigate and act on detected threats |
Defender for Cloud complements Sentinel by checking whether your infrastructure is configured securely before attacks happen.
The Observability Gap
Day 3 taught you how to prevent bad code from reaching production. Day 4 taught you how to detect what happens after deployment.
The gap: Pipelines only see code before deployment. Runtime monitoring sees what happens after. Both are essential.
The Data Model
Two paths, one store, three perspectives: Application (SDK), Platform (diagnostic settings), and Management (Azure Activity Log) — all flowing into Log Analytics, all analysed by Sentinel.
Monitoring Architecture (simplified)
For the full data flow (SDK + diagnostic settings), see Lab 4.2 — Logs, Metrics, Traces, and Diagnostic Settings.
What Each Layer Captures
| Layer | Captured By | Examples | Latency |
|---|---|---|---|
| Application | App Insights SDK | HTTP requests, dependency calls, custom events | 5–30 seconds |
| Platform | Diagnostic Settings | HTTP logs, console output, audit events | 30–120 seconds |
| Management | Azure Activity Log | Resource changes, RBAC, policy | 1–5 minutes |
Day 4 Additions to Defense in Depth
Today we added three new layers:
| Layer | Control | Protects Against |
|---|---|---|
| Monitoring (Day 4) | Log Analytics, Sentinel | Unnoticed incidents, delayed detection |
| Detection (Day 4) | Analytics rules, hunting queries | Known threat patterns |
| Response (Day 4) | Incidents, workbooks | Unstructured response |
For the full defense-in-depth picture including Day 1–3 layers, see Course Overview.
What We Built
Pipeline Changes
Three new stages were added to the Day 3 pipeline:
- EnableMonitoring — Terraform applies diagnostic settings
- GenerateTelemetry — Simulated attack traffic exercises the monitoring stack
- MonitoringValidation — KQL queries confirm data is flowing
Key Queries Used
The most useful queries in this lab:
| Query | Purpose | Table |
|---|---|---|
AppRequests | where ResultCode >= 400 | Find failed requests | AppRequests |
AzureDiagnostics | where Category == "AuditEvent" | Find Key Vault access | AzureDiagnostics |
summarize count() by ClientIP | Top offending IPs | AppRequests |
union AppRequests, AzureDiagnostics | Cross-table search | Both |
For the full query reference and investigation workflow, see Lab 4.6 — From Query to Detection.
Correlation ID Flow
End-of-Day Checklist
[ ] Monitoring infrastructure is enabled (diagnostic settings, Sentinel, daily cap)
[ ] Logs flow from resources to Log Analytics (SDK + diagnostic settings)
[ ] Correlation IDs are passed through the full request chain
[ ] Microsoft Sentinel is enabled on the Log Analytics workspace
[ ] Azure Activity Log connector is enabled in Sentinel
[ ] KQL queries can find failed requests, error patterns, and suspicious IPs
[ ] Analytics rules detect known attack patterns and create incidents
[ ] Workbooks provide dashboards for security operations
[ ] Monitoring coverage review identifies any data source gaps
[ ] Daily cap is set on Log Analytics to prevent runaway costs
[ ] Defender for Cloud recommendations are reviewed (check Secure Score)The Challenge
The final challenge asks you to build your own monitoring dashboard, review coverage across all nine data sources, and design an analytics rule based on something you observed during Day 4. See the Day 4 Challenge.
Key Principles We Applied
1. Two Paths, One Store
Application telemetry (SDK) and platform logs (diagnostic settings) are different views of the same event — one shows what your code did, the other shows what Azure did with your request. For the full comparison, see Application Insights Fundamentals.
2. Correlation Over Timing
Do not correlate by time and IP address alone. Use correlation IDs that are passed through every layer of the request chain. Every log entry for the same request carries the same ID — query by ID, get the full chain.
3. Query Before Automate
Test queries manually before making them automated rules. An unvalidated analytics rule can create hundreds of false positive incidents per day. Always run your KQL query against real data first and validate results over a longer time period.
4. Operational Readiness
Monitoring is only useful if it is operational: data flowing, rules active, connectors enabled, dashboards built, team trained. Missing any of these means blind spots.
5. Automate the Response
Detection without response is incomplete. Start with automation rules for simple tasks (tagging, notifications), graduate to playbooks (SOAR) for complex responses (block IP, disable user). Defender for Cloud complements Sentinel by checking your infrastructure's security posture before attacks happen.
6. Monitor Both Posture and Runtime
| Defender for Cloud | Sentinel | |
|---|---|---|
| Focus | Prevention (posture) | Detection (runtime) |
| Question | "Are we configured securely?" | "Is something happening that we should investigate?" |
Together they create defence in depth.
Cost and Capacity Management
| Factor | Impact | Mitigation |
|---|---|---|
| Daily cap | Prevents runaway costs | Always set a daily cap in shared environments |
| Data volume | More logs = higher cost | Use structured logging, reduce verbosity |
| Query volume | More queries = higher cost | Use summarize early, filter by time |
| Retention period | Longer retention = higher cost | Use shorter retention for dev (30 days) |
| Analytics rules | Each rule runs on a schedule | Start with a few high-value rules |
Critical: Always set a daily cap on the Log Analytics workspace. Without a cap, a misconfigured app that logs heavily could generate hundreds of gigabytes per day.
What Changed From Day 3
| Component | Day 3 | Day 4 |
|---|---|---|
| Telemetry | None | SDK + diagnostic settings + Activity Log |
| Monitoring | Not configured | Log Analytics + Sentinel |
| Detection | Not configured | Analytics rules, Fusion (ML-based), hunting queries |
| Investigation | Not available | KQL-based cross-table searching |
| Response | Not available | Incidents, playbooks (SOAR) |
| Posture | Not available | Defender for Cloud |
Portal Note: Sentinel Moving to Defender
Microsoft Sentinel is transitioning from the Azure portal to the Microsoft Defender portal by March 2027. All concepts covered today (analytics rules, incidents, workbooks, hunting queries) work the same way in the Defender portal. Students using the Defender portal will see AI-powered tools like Entity Analyzer and Security Copilot agents that supplement the manual investigation steps taught here.
Note: Sentinel also includes a data lake tier for long-term storage (up to 12 years). KQL jobs can promote selected data from the lake back into the analytics tier when you need it for detection or hunting.
Bridge to Future Days
Today we established runtime monitoring as the third pillar of the security lifecycle:
Day 3: Secure the pipeline and prevent vulnerabilities.
Day 4: Monitor the system and detect threats.The loop back to Day 3 is critical: incidents from runtime monitoring should feed back into your pipeline to prevent recurrence.
Example: An incident reveals that the internal backend was accessible from the internet. The fix involves:
- Day 4 (detect): Analytics rule detects the external access
- Day 3 (prevent): Pipeline check validates network configuration before deployment
- Day 2 (protect): Network control prevents external access to the internal backend
This is the security feedback loop: detect → respond → prevent.
Next steps: Once you have analytics rules firing, learn about playbooks (SOAR) to automate incident response. Explore Defender for Cloud to understand how posture management complements runtime detection.
Day 4 Challenge
If time allows, we have a challenge: Day 4 Challenge Exercises