Azure Monitor: Metrics, Logs and Log Analytics
Azure Monitor collects two fundamentally different kinds of telemetry and confusing them is the fastest way to answer a monitoring question wrongly. Metrics are numeric values sampled at regular intervals, stored in a time series database, available almost immediately, and retained for 93 days. They are what metric alerts and autoscale rules read, and they are cheap to query. Logs are records with structure and varying shape, stored in a Log Analytics workspace, queried with Kusto Query Language, and retained for as long as you configure and pay for. Nothing arrives in a workspace by accident: platform resources send data only once a diagnostic setting routes their platform logs and metrics there, and virtual machines send guest-level data such as performance counters and event logs only once the Azure Monitor Agent is installed and a data collection rule tells it what to gather and where to send it. Application Insights is the application-facing part of the same system, giving request rates, dependencies, failures and end-to-end transaction views for web applications. VM insights and Container insights are packaged experiences built on the same workspace data. The practical consequence for the exam is that a scenario asking why data is missing is usually answered by a missing diagnostic setting, a missing agent, or a missing data collection rule.
Exam tip. If a question says data is not appearing for a platform resource, the answer is a diagnostic setting. If it is a virtual machine's guest performance counters or event logs, the answer is the Azure Monitor Agent plus a data collection rule.
Alert Rules, Action Groups and Network Diagnostics
An alert in Azure is built from three separable parts, and knowing which part to change is what the exam tests. The alert rule defines the scope and the condition: a metric alert evaluates a numeric signal against a threshold, a log alert runs a KQL query on a schedule and alerts on the results, and an activity log alert fires on control plane events such as a resource being deleted or a service health notification. The alert rule also carries a severity from 0, critical, to 4, verbose. The action group defines what happens next and is reusable across rules, supporting email, SMS, push, voice, webhooks, Logic Apps, Azure Functions, Automation runbooks and ITSM connectors. The alert processing rule sits on top and can suppress notifications during a maintenance window without disabling the rules themselves. Because action groups are reusable, adding a new recipient to twenty alerts is a change to one action group rather than twenty rules. For connectivity problems, Network Watcher provides the diagnostic set: IP flow verify says whether a packet would be allowed and names the rule that decides it, next hop shows where a packet would be sent and catches wrong user-defined routes, effective security rules flattens the NSGs applied to a NIC, connection troubleshoot tests a path end to end, and NSG flow logs record what actually happened for later analysis.
Exam tip. When a question asks how to notify a new on-call team across many existing alerts with the least administrative effort, the answer is to update or add an action group, never to edit each alert rule.
Azure Backup, Recovery Services Vaults and Site Recovery
Backup and disaster recovery are different problems and Azure solves them with different services, which is exactly what the exam wants you to separate. Azure Backup protects data so it can be restored later, and its store is a Recovery Services vault for Azure VMs, on-premises workloads through the MARS agent or MABS, SQL and SAP HANA running in VMs, and Azure file shares, while a newer Backup vault covers blobs, managed disks and open source databases. A backup policy sets the schedule and retention, and instant restore keeps local snapshots for one to five days so recent restores do not have to read from the vault. Vault-level features matter: soft delete keeps deleted backup data recoverable for 14 days by default, and the vault's own redundancy, locally or geo redundant, is chosen when the vault is created and cannot be changed once items are protected. Azure Site Recovery is the disaster recovery service: it continuously replicates whole machines to another region, lets you build recovery plans that order the startup of tiers, and supports test failover into an isolated network so the plan can be rehearsed without disrupting anything. A test failover is the answer whenever a scenario asks to validate disaster recovery without affecting production. Restoring a single deleted file is Backup; standing the application up in another region is Site Recovery.
Exam tip. Watch for the recovery point objective in the wording. Backup restores to the last scheduled recovery point, which is usually hours old, while Site Recovery replicates continuously, so a requirement measured in minutes rules backup out.