"Security and monitoring are not final layers you add before go-live. In an AZ-305 architecture, they are woven into every design decision from the beginning. You cannot protect what you cannot see."
The Business Analogy
Azure Monitor — The Observability Foundation
Azure Monitor collects two types of telemetry from every Azure resource. Understanding the difference is essential for designing alert and diagnostic strategies.
AZURE MONITOR ARCHITECTURE
Resources (VMs, App Services, SQL, etc.)
|
+- METRICS ------------------------------------->
| Numerical time-series (CPU%, memory, requests/sec)
| Stored 93 days natively
| Near real-time -- 1 minute granularity
| Queried with Metrics Explorer
| Alerts: metric threshold (CPU > 80% for 5 min)
|
+- LOGS ---------------------------------------->
Structured text/JSON (events, errors, warnings)
Stored in Log Analytics Workspace (configurable retention)
Queried with KQL (Kusto Query Language)
Alerts: log query alert (find error 500 in last 5 min)
ALERT PIPELINE:
Condition met -> Alert fires ->
Action Group -> Email | SMS | Webhook | Logic App | Azure Function
APPLICATION INSIGHTS:
SDK embedded in application code
Tracks: request rates, response times, failures, dependencies
Distributed tracing across microservices
Live Metrics stream -- watch your app in real-time
Application Map -- visual dependency graph
Key Vault — The Zero-Secret Architecture
Every production architecture stores secrets somewhere — database connection strings, API keys, certificates. Where and how you store them is a security design decision. The correct pattern for AZ-305 is: Key Vault + Managed Identity + Key Vault Reference.
ZERO-SECRET ARCHITECTURE PATTERN
WRONG (common, dangerous):
App Service Environment Variables:
DB_CONNECTION_STRING = "Server=sql.database.windows.net;Password=MyP@ssw0rd"
-> Visible to anyone with Reader on the App Service
-> In Git history if ever committed
-> Cannot rotate without redeployment
CORRECT (Key Vault Reference pattern):
App Service Environment Variables:
DB_CONNECTION_STRING = @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/dbconn)
-> App Service fetches secret FROM Key Vault at startup
-> Secret never appears in portal, logs, or config files
-> Rotate secret in Key Vault -- App Service picks up new value on restart
-> Identity that fetches: Managed Identity of the App Service (no password)
HOW IT WORKS:
1. App Service has System-Assigned Managed Identity enabled
2. Key Vault Access Policy: App Service identity -> Get + List secrets
3. App Service env var: @Microsoft.KeyVault(SecretUri=...)
4. At startup: App Service authenticates as Managed Identity -> fetches secret
5. Secret available as regular env var in the application
ADDITIONAL KEY VAULT PROTECTIONS:
Soft-delete: deleted secrets recoverable for 7-90 days
Purge protection: even after soft-delete, purge requires waiting period
Diagnostic logs: every Get, Set, Delete logged with caller identity
Defender for Cloud — Security Posture Management
Microsoft Defender for Cloud is the unified security management platform for Azure. It has two modes: free (basic posture assessment) and Defender Plans (paid, enhanced threat detection per service).
Disaster Recovery — RPO, RTO, and the DR Architecture Decision
Every production system needs a disaster recovery strategy. AZ-305 expects you to translate business requirements into the correct DR architecture. Two measurements drive all DR decisions:
RPO and RTO -- The DR Requirements
RPO = Recovery Point Objective
"How much data can the business afford to lose?"
RPO of 1 hour -> you can restore to a backup taken 1 hour ago
RPO of 0 -> no data loss permitted -> requires synchronous replication
RTO = Recovery Time Objective
"How fast must the system be back online?"
RTO of 4 hours -> business can survive 4 hours of downtime
RTO of 5 minutes -> near-instant recovery required -> active-active
MAPPING REQUIREMENTS TO DR ARCHITECTURE:
RPO: 24 hours, RTO: 8 hours
-> Azure Backup (daily backup to Recovery Services Vault)
-> Restore VM from backup on regional failure
-> Lowest cost, highest recovery time
RPO: 15 minutes, RTO: 1 hour
-> Azure Site Recovery (ASR)
-> Replicate VMs to paired region continuously
-> Failover in ~30 minutes when region fails
-> Medium cost, moderate recovery time
RPO: near-zero, RTO: < 5 minutes
-> Active-Active architecture
-> Front Door routing to both regions simultaneously
-> Azure SQL Geo-Replication with auto-failover group
-> App Service Zone Redundant in both regions
-> Highest cost, fastest recovery
Architect Scenario — Insecure Connection String
A security audit of a production App Service finds that the database connection string — including the password — is stored as an App Service Application Setting (environment variable), visible to anyone with Reader access. The audit flags this as critical. What is the remediation design?
Show Answer + Reasoning
Key Vault + Managed Identity + Key Vault Reference pattern.
Step 1 — Enable Managed Identity on App Service: Portal → App Service → Settings → Identity → System assigned → Status: On. Azure generates an identity for this App Service in Entra ID. No credentials created — the identity is automatic.
Step 2 — Store the connection string in Key Vault: Create a Key Vault secret named "DbConnectionString" with the connection string as the value. Enable soft-delete and purge protection.
Step 3 — Grant App Service identity access: Key Vault → Access policies → Add policy → Select the App Service's Managed Identity → Grant: Get, List on Secrets.
Step 4 — Update App Service Application Setting: Change the DB_CONNECTION_STRING value to: @Microsoft.KeyVault(SecretUri=https://yourvault.vault.azure.net/secrets/DbConnectionString)
Result: The connection string no longer appears in the portal, Git, logs, or config files. The App Service fetches it from Key Vault at startup. To rotate: update the secret in Key Vault, restart the App Service. No redeployment of the application needed.
🎯 Quick Check — Module 5
Q1: What is the difference between Azure Monitor Metrics and Azure Monitor Logs?
Show Answer
Metrics are numerical time-series data points (CPU%, memory MB, requests per second). Stored natively in Azure Monitor for 93 days. Near-real-time (1-minute granularity). Used for: dashboards, real-time alerting, auto-scale rules.
Logs are structured text/JSON records (events, errors, warnings, audit entries). Stored in a Log Analytics Workspace with configurable retention. Queried with KQL. Used for: root cause analysis, security investigation, compliance reporting, complex multi-resource queries. Metric alerts fire faster; log alerts have inherent delay because logs must be ingested first.
Q2: A company requires RPO of 15 minutes and RTO of 1 hour for their Azure VM workload during a regional failure. What service and design meets this requirement?
Show Answer
Azure Site Recovery (ASR) with replication to a paired secondary region. ASR continuously replicates VM disk changes to the secondary region — typical replication frequency gives RPO of minutes to 15 minutes. Failover time in ASR is typically 15-45 minutes including: detect failure, trigger failover, spin up VMs in secondary region, reconfigure networking. This meets the 1-hour RTO. Azure Backup cannot meet 15-minute RPO — it takes daily or hourly snapshots depending on policy.
Q3: What is the Defender for Cloud Secure Score and how should architects use it in their design process?
Show Answer
The Secure Score is a percentage (0-100%) measuring how many security recommendations you have implemented. Each recommendation has a "max score" contribution. Architects should: (1) Check the Secure Score at the start of a project as the baseline, (2) Set a minimum Secure Score target as a go-live gate (e.g., 70%+), (3) Prioritise recommendations by severity — Critical first, then High, Medium, (4) Use the score trend over time to confirm posture is improving, (5) Export recommendations to Azure Policy to enforce them automatically across new deployments.
Key Takeaways — Module 5
- Metrics = numerical time-series, real-time, 93 days; Logs = structured text, KQL queryable, long retention — choose based on what question you need to answer
- Key Vault + Managed Identity + Key Vault Reference: the zero-secret pattern — no credentials in code, config, Git, or portal
- Defender for Cloud Secure Score: your posture benchmark — set a target, track improvement, address Critical recommendations first
- RPO drives backup/replication frequency; RTO drives recovery architecture — map business requirements to DR design before choosing services
- Azure Backup = data protection (file/VM recovery); Azure Site Recovery = disaster recovery (regional failover with defined RTO/RPO)
- Active-Active (Front Door + multi-region) = near-zero RPO/RTO, highest cost; Active-Passive (ASR failover) = moderate RPO/RTO, lower cost