Monitoring, Backup & Resilience¶
Scope
Operations resilience notes and evidence paths for Release 2: security posture management, SIEM deployment, synthetic alert validation, and a backup protection model evolved through three design stages.
Operations visibility model¶
Release 2 uses a layered operations model rather than treating monitoring and backup as separate afterthoughts.
| Layer | Implemented capability | Evidence |
|---|---|---|
| Security posture | Defender for Servers Plan 1, secure score, and recommendations | docs/release2/evidence/P7/ |
| SIEM deployment | Microsoft Sentinel with Log Analytics integration, provider/schema checks, policy exemption handling, and post-apply validation | docs/release2/evidence/P8/ |
| Alert validation | Azure Monitor alert rules tested with synthetic CPU stress and action group notification evidence | docs/release2/evidence/P9a/ |
| Recovery protection | Recovery Services Vault with immutability, Multi-User Authorization / Resource Guard, and soft-delete validation | docs/release2/evidence/P9b/ |
| Backup architecture evolution | Three-stage redesign covering platform-shared vault configuration, governance policy exemption handling, backup-now trigger, and final recovery point validation | docs/release2/evidence/P9b-redesign/ |
Microsoft Sentinel and Defender visibility¶
Defender for Cloud provides the posture-management layer: Defender for Servers Plan 1 is activated, secure score is captured, and security recommendations are generated.
Microsoft Sentinel provides the SIEM deployment layer: the workspace is provisioned with Log Analytics integration, provider and schema checks are captured, policy exemption records are documented, and post-apply validation evidence confirms the deployment path.
The public evidence validates deployment and validation. Incident or analytic-rule claims are linked only where incident records or rule exports are present.
Azure Monitor alert validation¶
Operational alerting is tested, not only configured.
Azure Monitor alert rules are created for critical conditions. Synthetic CPU stress is triggered on a monitored VM, and the resulting alert is captured through action group notifications. This validates the alert pipeline end to end: metric threshold is breached, alert fires, and notification is sent.
Evidence: P9a folder - alert rule configuration, synthetic stress output, and notification evidence.
Recovery Services Vault protection model¶
The backup design is built around deletion protection and governed recovery readiness.
The evidenced controls include:
- Recovery Services Vault configuration.
- Immutability.
- Multi-User Authorization through Resource Guard.
- Soft-delete validation.
- Backup-now trigger output.
- Final recovery point validation.
These controls protect backups from accidental or malicious deletion, add an approval gate for destructive operations, and validate recoverability.
Evidence: P9b folder - vault properties, MUA configuration, soft-delete status, backup-now job logs, and recovery point screenshots.
P9b redesign: staged resilience engineering¶
The backup architecture did not follow a single linear path. It went through three design stages.
| Stage | Focus | Outcome |
|---|---|---|
| Stage 1 | Platform-shared vault configuration | Established vault, backup policy, and initial protected items. |
| Stage 2 | Governance and policy exemption handling | Documented how Azure Policy exemptions interact with backup and MUA requirements. |
| Stage 3 | Backup-now trigger and final recovery point validation | Validated on-demand backup and usable recovery points. |
This multi-stage evolution shows that the resilience design responded to real constraints: governance policy, shared platform architecture, and operational validation. It is not presented as a one-click deployment.
Evidence: P9b-redesign folder - design notes, stage-by-stage outputs, and final validation evidence.
Enterprise hardening pattern¶
The current implementation uses immutability, MUA/Resource Guard, and soft-delete. In a stricter enterprise environment, the same protection model can follow a stronger hardening path:
- Customer-managed keys for backup encryption.
- Private endpoints for the Recovery Services Vault.
- Role-based access control with just-in-time elevation for backup deletion.
- Separate vaults for production and non-production workloads.
- Automated restore testing with post-restore validation scripts.
These patterns document how the platform's resilience design maps to a fully hardened enterprise backup regime, even where not every control is activated in the evidence environment.
Engineering significance¶
- Shows that operational visibility is layered: posture management, SIEM, and synthetic alert validation each have distinct evidence.
- Shows that the backup design includes deletion protection through immutability, MUA, and soft-delete, with validation through on-demand backup and recovery point inspection.
- Shows that resilience engineering is iterative: the P9b redesign evidence records design evolution, not a static setup.
- Establishes that the platform can be monitored, alerted on, backed up, and recovered with controls aligned to enterprise expectations.
Evidence map¶
| Claim | Repository location | What to verify |
|---|---|---|
| Defender for Servers Plan 1 active, secure score captured | docs/release2/evidence/P7/ |
Secure score screenshots, recommendations list |
| Sentinel workspace deployed and validated | docs/release2/evidence/P8/ |
Provider/schema checks, policy exemption records, post-apply validation |
| Azure Monitor alerts fire on synthetic CPU stress | docs/release2/evidence/P9a/ |
Alert rule config, stress test output, notification evidence |
| Recovery Services Vault has immutability, MUA, soft-delete | docs/release2/evidence/P9b/ |
Vault properties, MUA configuration, soft-delete status |
| Backup-now trigger produces a validated recovery point | docs/release2/evidence/P9b/ and docs/release2/evidence/P9b-redesign/ |
Backup-now job logs, recovery point screenshots |
| Backup architecture evolved through three evidenced design stages | docs/release2/evidence/P9b-redesign/ |
Stage-by-stage design notes, final validation outputs |
Review takeaway¶
Monitoring, Backup and Resilience shows that Release 2 has an operational visibility and recovery plane, not just deployed infrastructure.
A reviewer can inspect Defender, Sentinel, alerting, Recovery Services Vault, MUA, soft-delete, and P9b redesign evidence to confirm that monitoring and resilience were implemented, validated, and documented as part of the platform operating model.