Section 9 of 14
This domain covers Azure Monitor, alerts, log analytics, Network Watcher, and backup/disaster recovery. It is the smallest domain but still meaningful - and the diagnostics tools are commonly tested in case studies.
Azure Monitor is the umbrella for all telemetry. It collects data from Azure AND on-premises resources. Everything else (Log Analytics, App Insights, Application Insights, alerts) lives under it.
| Data Type | What it captures | Retention | Notes |
|---|---|---|---|
| Metrics | Numerical time-series data (CPU, memory, requests) | 93 days default | Always on, free, real-time |
| Logs | Structured/unstructured event data | Up to 2 years (configurable) | Require Diagnostic Settings |
| Activity Log | Who did what (control plane actions) | 90 days | Always on for every subscription |
| Resource Logs | Operations inside resources | Configurable | MUST be enabled via Diagnostic Settings |
Diagnostic Settings must be ENABLED PER RESOURCE Resource logs do NOT collect by default. You must explicitly enable Diagnostic Settings on each resource and choose where to send them: Log Analytics Workspace, Storage Account, or Event Hub. Activity Log is the exception - it captures all ARM operations automatically. If the question is 'why are no resource logs in Log Analytics', the answer is 'Diagnostic Settings not configured'.
| Tool | Purpose |
|---|---|
| Azure Monitor | Collect, analyze, act on telemetry - alerts, metrics, logs, dashboards |
| Azure Advisor | Personalized recommendations across cost, security, reliability, performance, ops |
| Azure Monitor Metrics | Specific sub-feature - numerical time-series data with charts |
| Azure Activity Log | Control plane audit - who did what |
| Application Insights | Specific to applications - APM, synthetic transactions, code-level diagnostics |
| Customer Insights | NOT Azure infrastructure - part of Dynamics 365, customer data aggregation |
Customer Insights is a Dynamics 365 / business intelligence tool. It is NOT for monitoring Azure infrastructure. If a question lists it as an option for diagnosing Azure issues, it is wrong.
Log Analytics is where logs collected via Diagnostic Settings end up. You query the data with KQL (Kusto Query Language).
| Plan | Retention | KQL | Cost |
|---|---|---|---|
| Analytics Logs | 30-90 days interactive + up to 12yr archive | Full KQL + alerting | Pay per ingestion |
| Basic Logs | 8 days interactive + archive | Limited KQL, no alerting, pay per query | Cheaper ingestion |
Basic structure: TableName | where Condition | project Columns | summarize Aggregation
Operators: where (filter), project (select), summarize (aggregate), extend (add column), ago() (relative time)
You do NOT need to write complex KQL for AZ-104 - most questions are interpretation, not writing
Example queries to recognize:
AzureActivity | where OperationName == 'Delete' - find delete operations
Heartbeat | summarize LastCall=max(TimeGenerated) by Computer - find when computers last reported
Event | where EventLevelName == 'Error' - find error events from Windows Event Log
Common scenario: alert on Windows Event Log errors Question: 'create an alert when more than 2 errors are logged to System event log on a VM within an hour'. Right answer: (1) Create a Log Analytics workspace, (2) install Microsoft Monitoring Agent / Azure Monitor Agent on the VM, (3) create the alert in Azure Monitor specifying the LOG ANALYTICS WORKSPACE as the source - NOT the VM directly. Wrong answer: specifying the VM directly as the alert source. Azure Monitor cannot read Windows Event Log without a workspace + agent.
Metric alerts - based on numerical thresholds (CPU > 80% for 5 mins)
Log alerts - based on KQL queries against Log Analytics
Activity Log alerts - based on control plane events (deletion, deallocation)
Smart Detection alerts - ML-driven anomaly detection
When an alert fires, it triggers an Action Group. Action groups define what to do: email, SMS, voice call, webhook, Function, Logic App, Automation Runbook, ITSM connector.
| Channel | Rate limit |
|---|---|
| Max 100 per hour | |
| SMS | Max 1 every 5 minutes (max 12 per hour) |
| Voice call | Max 1 every 5 minutes |
If a question asks how many SMS messages an alert can send per hour, the answer is max 12 (one every 5 minutes). For email it is 60 (one per minute) up to 100/hour total. These rate limits are heavily tested.
Alert Processing Rules sit between alerts and action groups. They can either trigger an action group OR SUPPRESS alerts based on criteria (time of day, severity, target resource). Cleaner than configuring every alert to call the same action group.
To alert when a VM is deallocated, create an alert based on the ACTIVITY LOG for the VM resource. Activity Log captures state changes like start/stop/deallocate. Diagnostic logs and resource tags do not capture this directly.
The IT Service Management Connector (ITSMC) bridges Azure Monitor alerts to on-premises or cloud ITSM tools like System Center Service Manager, ServiceNow, BMC Remedy, Cherwell, Provance. You must deploy the ITSMC BEFORE alerts can flow to those systems.
If a question is 'when memory on VM1 is below 10%, alert in System Center Service Manager - what should you do first?', the answer is Deploy the ITSM Connector. You need that bridge before Azure can talk to on-prem Service Manager.
Network Watcher is the troubleshooting toolkit for Azure networking. Memorize which tool solves which problem.
| Tool | What it tells you | Use when |
|---|---|---|
| IP Flow Verify | Tests if a packet is allowed or denied by NSG rules | Troubleshooting NSG-blocked traffic |
| Next Hop | Shows the next hop for a packet from a VM | Routing or UDR issues |
| Connection Monitor | Continuous monitoring of end-to-end connectivity (latency, packet loss) | Ongoing connectivity health checks - measures RTT |
| Connection Troubleshoot | On-demand connection test between VMs/endpoints | Diagnose a specific connectivity failure right now |
| NSG Flow Logs | Logs all allowed/denied traffic through an NSG | Auditing, forensics, integrating with Sentinel |
| Traffic Analytics | Analyzes NSG flow logs for patterns and security threats | Detecting bot attacks, suspicious traffic |
| Packet Capture | Captures packets from a VM NIC | Deep protocol-level troubleshooting |
IP Flow Verify is for NSG troubleshooting. Next Hop is for routing/UDR troubleshooting. Connection Monitor is for ongoing latency/RTT. The exam loves to test which tool solves which problem. Memorize these mappings.
VM cannot reach an external host on a port - IP Flow Verify (test against NSG rules)
View average round trip time between two VMs - Connection Monitor
Detect bots and suspicious network patterns - Traffic Analytics
Verify traffic is going through the right firewall - Next Hop
| Service | Purpose |
|---|---|
| Recovery Services Vault | Logical container that stores backup data and configuration for Azure Backup and Site Recovery |
| Azure Backup | Granular recovery - files, folders, databases, entire VMs. Supports app-consistent snapshots. |
| Azure Site Recovery (ASR) | DR - continuously replicates VMs to a secondary region. RPO minutes, RTO hours. |
Recovery Services Vault MUST be created first Before you can create a backup policy, configure ASR, or back up any resource, you need the Recovery Services Vault. Nothing else works without it. Hierarchy: Vault → Backup Policy → Protected Items → Recovery Points.
The Recovery Services Vault MUST be in the SAME region as the VMs (or other resources) it backs up. If you have VMs in multiple regions, you need a separate vault in each region.
Resource Group deletion fails if it contains a vault with active backups. Order of operations:
Stop backup of all protected items in the vault
Delete the backup data (soft-deleted by default for 14 days)
Unregister any registered storage accounts
Then the vault can be deleted, then the RG
Azure VMs (Windows Server 2008+, Windows 10, most Linux distros)
Azure Files (file share backups)
Azure SQL Databases in VMs
On-premises Windows/Linux servers
SAP HANA, Azure Database for PostgreSQL
Azure Backup works on STOPPED VMs too. They do not need to be running to be backed up. Auto-shutdown schedules do not interfere with backup.
A single backup policy can protect a MAXIMUM of 100 VMs
If you have more than 100 VMs of the same type, you need multiple policies
Example: 120 VMs needs at least 2 policies, 200 VMs needs at least 2, 250 VMs needs at least 3
A VM can only be backed up to ONE vault at a time. To switch a VM's backup from RSV1 to RSV2:
Go to RSV1 → Backup Items → Stop the VM2 backup (and optionally delete backup data)
Then configure a new backup job in RSV2 to back up VM2
| Need | Service |
|---|---|
| Accidentally deleted a file, restore it | Azure Backup |
| Region failed, fail over apps to a different region | Azure Site Recovery |
| Need granular point-in-time recovery | Azure Backup |
| Need continuous replication and minutes-level RPO | Azure Site Recovery |
RPO (Recovery Point Objective) - how much data you can afford to lose
RTO (Recovery Time Objective) - how long the service can be down before recovery
ASR has much better RPO/RTO than Backup alone