You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Azure Monitor collects numerical values called metrics at regular intervals from your resources. These metrics describe the state of a system at a specific point in time. Key metrics you will work with include CPU usage, memory usage, disk I/O, and network traffic. High CPU usage signals a compute bottleneck, while elevated disk I/O may indicate storage contention. Understanding what each metric represents allows you to evaluate whether a resource is operating within expected limits and directly connects to setting up proactive alerts.
Aggregation combines multiple metric values into a single data point. Azure Monitor supports Sum (total of all values), Average (mean, often Sum divided by Count), Min and Max (smallest or largest values), and Count (number of measurements). The choice matters: Average smooths out spikes, while Max highlights worst-case behavior. Time Range sets how much data is shown, and Time Granularity (or time grain) sets the interval for each data point. Dimensions are metadata categories like server name or status code, which allow you to Filter to a subset of data or Split to create separate lines for each value. Combining filtering and splitting lets you compare the performance of different virtual machines or API endpoints side by side.
To diagnose health, you select relevant metrics like CPU percentage or Disk IOPS, then aggregate them using Average, Sum, Minimum, or Maximum to spot trends or spikes. Adjusting time granularity lets you zoom in on short-term anomalies or see long-term patterns. For deeper root-cause analysis, use Log Analytics with the Kusto Query Language (KQL) to correlate metric data with log data. This lets you trace a CPU spike to a specific code error. Azure Monitor's alerting system supports metric alerts, log alerts, and activity log alerts, each for different scenarios. You can set dynamic thresholds for anomaly detection so the system learns normal behavior and alerts only when metrics deviate significantly.
A Log Analytics Workspace is the central data store for telemetry from cloud and on-premises resources. You must choose a pricing model: Pay-as-you-go for flexibility or Commitment Tiers for discounts on at least 100 GB daily. Data flows into the workspace through Diagnostic Settings (for Azure platform logs) and the Azure Monitor Agent (AMA) (for guest OS data). Both use Data Collection Rules (DCRs) to define what data is gathered and where it goes. Access is controlled through Access Control Mode: workspace-context permissions grant access to the entire workspace, while resource-context RBAC lets users see logs only for resources they own. For sensitive data, Table-level RBAC restricts access to specific tables.
Log data begins in interactive retention, where you can query it immediately using KQL. You can set different retention periods or move older data to long-term retention reaching up to 12 years. Continuous export streams log data to Azure Event Hubs or Azure Storage Accounts as it arrives for integration with external SIEM systems. Export destinations must be in the same region as the workspace. The choice of Table Plans affects costs and capabilities: the Analytics plan supports full query and alerting, the Basic plan reduces ingestion costs for troubleshooting logs, and the Auxiliary plan is cost-effective for compliance with limited query needs. Compliance features include immutable storage and Customer-managed keys (CMK) for encryption.
Diagnostic settings determine which logs and metrics Azure Monitor collects from resources and where that data is sent. The primary destinations are a Log Analytics workspace for advanced querying, an Azure Storage Account for long-term archival, and an Azure Event Hub for real-time streaming to external systems. Enabling diagnostic logging requires navigating to the resource in the Azure portal and accessing its Diagnostic settings panel. Here you select the log categories needed—such as activity logs, resource logs, and metrics—and specify the destination. The workspace must be in a supported region, and destinations should remain within the same network security perimeter as the source resource.
A Log Analytics workspace collects and analyzes telemetry from diverse sources. To control costs, workspaces use specific table plans and retention policies. The Analytics plan supports full query capabilities, while the Basic plan offers a lower-cost option for high-volume logs with limited query features. Securing telemetry requires Azure Role-Based Access Control (RBAC) at various scopes. Administrators can use workspace-context permissions for wide access or resource-context permissions to restrict users to logs for specific resources. For tighter security, table-level RBAC restricts access to sensitive tables. Organizations can deploy Azure Policy to prevent unauthorized workspace creation and set a daily cap on data ingestion to avoid budget spikes.
Azure Monitor Logs gathers telemetry across multiple environments. To analyze complex systems, you can execute cross-resource queries to pull data from multiple workspaces and resources simultaneously. For massive datasets, summary rules aggregate raw logs as they are ingested, reducing raw data storage and improving query reliability. Data can be displayed using Azure Monitor Workbooks for interactive, shareable reports and Azure Dashboards for continuous, high-level system health overviews. Proactive operations rely on identifying issues before downtime, and you can use machine learning pipelines and anomaly detection to spot trends. These insights can trigger log search alerts for automated response workflows.
Kusto Query Language (KQL) is the primary tool for analyzing log data within Azure Monitor. It operates on schema entities structured as tables and columns and supports operators like project (to select columns), where (to filter rows), join (to combine tables), and summarize (to aggregate data). Basic queries can target resource diagnostics to identify performance bottlenecks, such as instances with average CPU utilization above 95%. For advanced analysis, KQL provides native machine learning operators for time series analysis, forecasting, and root cause analysis directly within the workspace. When external reporting is required, data can be exported via the REST API or through Workspace Data Export.
Alert rules define the conditions that trigger alerts. When an alert fires, the rule specifies one or more action groups and optionally links to alert processing rules. You can create rules manually or use Recommended Alerts for predefined rules. A scalable approach is Azure Monitor Baseline Alerts (AMBA), which provides tested alert definitions for compute, networking, and Service Health. Azure Policy can automatically apply alert rules to every current and future resource of a given type. Each alert rule must be associated with at least one action group.
Action groups are reusable collections of notification methods and automated actions that execute when an alert fires. They can include email, SMS, push notifications, webhooks, Azure Functions, Logic Apps, Automation Runbooks, and ITSM connectors. A single alert rule can reference up to five action groups, and all actions run concurrently. Email Azure Resource Manager Role sends alerts to everyone who holds a specific RBAC role. Action groups are combined with alert processing rules to suppress notifications during maintenance or route alerts based on severity.
Alert processing rules modify the behavior of alerts that have already fired. Their two primary actions are Suppression and Apply action groups. Suppression stops notifications during a defined window without disabling underlying alert rules. The Apply action groups action adds extra notification channels. The scope can be a single resource, resource group, or entire subscription, with filters to narrow the rule's effect based on criteria like severity or resource type. When an alert matches more than one processing rule, a Suppression action always takes priority over an Apply action group action.
Diagnostic settings route resource logs and platform metrics to a Log Analytics workspace, Azure Storage account, or Azure Event Hub. For virtual machines, Data Collection Rules (DCRs) define the telemetry gathered by the Azure Monitor Agent (AMA). A DCR acts as a blueprint specifying which performance counters and events to send to a workspace. VM Insights streamlines monitoring by automatically deploying the agent and configuring a default DCR. It provides performance views with predefined charts, a map feature visualizing processes and dependencies, and health monitoring.
Azure Monitor Insights provides dedicated tools: VM Insights, Storage Insights, and Network Insights. These tools visualize key metrics and logs like CPU, memory, disk, and network utilization. Data collection relies on platform metrics, activity logs, and resource logs. For deeper analysis, install the Azure Monitor Agent and configure DCRs to gather guest OS performance counters and application logs. Visualization tools include Metrics Explorer for charting trends, Workbooks for interactive dashboards, and Dependency Maps for process relationships. Configure alert rules using metric alerts, log alerts, and activity log alerts. Alerts can be set at scale using multi-resource rules and Azure Monitor Baseline Alerts (AMBA). Action groups automate responses.
To analyze performance, install the Azure Monitor Agent on session hosts and send data to a Log Analytics workspace. Performance counters are essential for collecting data from session hosts. Windows Event Logs collect errors and warnings. The Traffic tab in Azure Monitor Insights provides a detailed view of network security groups and NSG flow logs. The Diagnostic Toolkit offers tools like packet capture, VPN troubleshoot, connection troubleshoot, next hop, and IP flow verify for diagnosing network problems.
Connection Monitor is a tool within Azure Network Watcher for monitoring connectivity and performance across cloud and hybrid networks. You create a test by defining a Test Group linking source endpoints (like Azure VMs) to destination endpoints (IPs, URLs, or other VMs). Each test uses a Test Configuration specifying the protocol (TCP, ICMP, or HTTP) and frequency. Azure VMs need the Network Watcher extension, while on-premises machines need the Azure Arc agent and Azure Monitor Agent. After tests run, you can analyze results through a Unified Topology view showing every network hop between source and destination.
Azure Network Watcher is a regional service for monitoring and diagnosing network issues. Enable it in your desired region via the portal, PowerShell, Azure CLI, or an ARM template. Its name is automatically set to NetworkWatcher_region and it is placed in a resource group named NetworkWatcherRG. Network Watcher provides Packet Capture to record traffic to and from a VM, and Connection Monitor to track network performance. These tools can be integrated into automated workflows.
Network Watcher includes specialized troubleshooting tools. IP flow verify checks if traffic is allowed or denied to a VM and identifies the exact Network Security Group (NSG) rule causing the action. Next hop determines the routing path for traffic. Connection troubleshoot evaluates whether a source can reach a destination. Packet capture can be started remotely to collect network packets. VPN troubleshoot diagnoses problems with virtual network gateways. Flow logs (when enabled for NSGs) and Traffic analytics provide visibility into traffic patterns for identifying malicious activity and optimizing network capacity.
A Recovery Services vault is a central storage location for protecting workloads like virtual machines and databases. A key decision during creation is choosing a storage replication type. You choose between Locally-redundant storage (LRS) for low-cost protection within one data center, Zone-redundant storage (ZRS) for replication across availability zones in one region, or Geo-redundant storage (GRS), the default, which copies data to a secondary paired region. This setting locks permanently once backups are configured. Security is managed through Role-Based Access Control (RBAC). Soft Delete retains deleted backups for 14 days. For strict compliance, Immutable vaults can be enabled to prevent early deletion of recovery points. The vault integrates with Azure Site Recovery for disaster recovery and supports Cross Region Restore (CRR) if GRS is configured.
Before creating a vault, you must plan its location. The vault must be in the same region as the resources it protects and placed within a specific Subscription and Resource Group. To use customer-managed keys, prepare by enabling a Managed Identity for the vault and ensuring Azure Key Vault has soft delete and purge protection enabled. On-premises servers using the Microsoft Azure Recovery Services (MARS) agent need outbound internet access to Azure Backup endpoints.
You create a Recovery Services vault through the Azure portal's Business Continuity Center. After creation, configure protection by going to the Backup center, selecting a data source type like Azure Virtual machines, and linking it to your vault along with a backup policy. Ongoing management includes monitoring jobs and modifying settings. Before enabling backups, you can change the default storage replication from GRS to LRS. To defend against ransomware, enable immutable vault settings.
A backup policy is the rule governing your backups, defining the schedule (daily or weekly) and how long data is retained. Retention rules can follow a grandparent-parent-child structure and extend up to 10 years for compliance. You apply these policies through a Backup vault, which is the storage entity for backup data. A key security feature is immutable vaults, which lock recovery points to prevent deletion before their expiry date.
An Azure Recovery Services vault is a central management resource for backup and disaster recovery. Creation requires specifying a subscription, resource group, unique name, and the region, which must match the resources being protected. The foundational decision is selecting storage redundancy: Geo-redundant storage (GRS) replicates to a paired region, Locally redundant storage (LRS) keeps copies in a single data center, and Zone-redundant storage (ZRS) replicates across availability zones. This setting is locked after backups are configured. The vault supports advanced restore features like Cross Region Restore (CRR) for GRS vaults and Cross Subscription Restore within the same tenant.
Advanced security features include Soft delete, which retains deleted backup data for 14 days, and Immutable vaults, which prevent deletion of recovery points before scheduled expiration. The storage replication type chosen during vault creation is foundational for data durability and enables features like CRR. Security is also managed through Azure Role-Based Access Control (RBAC). Encryption at rest uses Microsoft-managed keys by default, but you can use customer-managed keys (CMK) for greater control.
An Azure Backup policy sets the schedule (daily or weekly) and retention rules (daily, weekly, monthly, yearly) for recovery points. Policies are scoped to a single recovery vault. You can modify policies later: extending retention applies to existing recovery points, while reducing it marks older points for deletion. You can run an on-demand backup with custom retention. When stopping protection, you choose between stop protection and retain backup data to keep existing recovery points, or stop protection and delete backup data to remove all recovery points. Security is enforced through encryption at rest and in transit and role-based access control (RBAC). Soft delete is enabled by default.
To protect against ransomware, you can enable immutability on a vault to lock recovery points until their expiration. Access is controlled through RBAC roles like Backup Contributor, Backup Operator, and Backup Reader. For governance at scale, use Azure Policy to automatically configure backups for new resources. For maximum security, multi-user authorization (MUA) can be implemented using a Resource Guard to require external approval for critical changes. Using customer-managed keys (CMK) provides direct control over encryption keys.
Backup parameters must match the criticality of each workload. Mission-critical systems may use enhanced policies with multiple daily backups to minimize data loss (a low RPO). Retention rules split between short-term needs for immediate recovery and long-term retention for regulatory compliance, with older points potentially moved to an archive tier. The protection scope defines which resources are governed by a policy. Best practices suggest using multiple recovery vaults to segregate workloads by region, department, or environment to isolate risk.
Azure Backup uses saved copies called recovery points to restore resources. Data is stored in a Snapshot Tier for Instant Restore and a Vault Tier for long-term retention. When restoring, you decide between Original Location Recovery (OLR) to replace the existing source or Alternate-Location Recovery (ALR) to create a new instance. Create New Virtual Machine rebuilds a complete VM, Restore Disks recovers virtual hard disks, and Item Level Restore (ILR) recovers specific files or folders. For workloads like SQL Server on Azure VMs, restore supports Point-in-Time Recovery using transaction logs. Cross-Region Restore (CRR) enables recovery in an Azure paired region. All restore operations are tracked in the Backup Center.
Azure Backup provides monitoring tools in the Recovery Services vault showing job statuses: Completed, In progress, Failed, Canceled, and Completed with warnings. When a job fails, Azure Backup generates alerts via Azure Monitor. Critical alerts are triggered for failures or deletion of backup data. Common causes include transient errors, permission issues, resource constraints, unhealthy workload extensions, and unsupported backup types. Remediation may involve retrying jobs, assigning correct permissions, or adjusting policies. Monitoring solutions like Backup Explorer and Backup Reports help analyze trends and forecast storage.
Azure Backup policies define protection through Scheduling (when backups run), Retention (how long data is kept), and Storage Options (LRS, GRS, ZRS). Security features include encryption, Soft Delete for 14 days, and Multi-User Authorization (MUA) requiring multiple users to authorize destructive operations. Monitoring is done via Backup Explorer and integration with Azure Monitor for custom alerts. Periodically performing Test Restores validates the backup configuration.
When preparing Azure VMs to fail over to a secondary region, you must define target resources like the subscription, resource group, and virtual network. Network planning involves mapping IP addresses and ensuring Network Security Groups in the target region allow outbound replication traffic on port 443. Load balancers and Azure Traffic Manager must be provisioned in the target region in advance. Recovery Plans combined with Azure Automation scripts can automate connecting these components. Compute sizing in the target region typically matches the source, and you must configure Availability Sets or Availability Zones for high availability.
Azure Site Recovery replicates workloads between Azure regions or from on-premises to Azure. Implementation starts by creating a Recovery Services vault. You define replication policies that set the recovery point retention history and app-consistent snapshot frequency. Enabling replication for Azure VMs involves selecting the source VMs, configuring the target location and network, and enabling replication. Automation is possible using the REST API, PowerShell, or the Azure SDK.
Azure Site Recovery uses Recovery Plans to organize how multiple virtual machines fail over together. The three main failover types are a Test Failover (drill with no impact on production), a Planned Failover (zero data loss for maintenance), and an Unplanned Failover (response to sudden disaster). When triggering a failover, you select a Recovery Point—Latest for lowest RPO, Latest Processed for lower RTO, or Latest App-consistent for database integrity. After a successful failover, you Commit the operation to finalize it. To return to the primary region, perform Reprotection to start reverse replication, then Failback.
Azure Site Recovery supports Planned Failovers and Unplanned Failovers. When executing a failover, selecting the correct recovery point is vital. The Latest point offers the lowest Recovery Point Objective (RPO). The Latest Processed point offers a lower Recovery Time Objective (RTO). The Latest App-consistent point captures memory-resident data for database integrity. You can select the option to Shut-down machine before beginning failover to synchronize final changes. After failover, the VM must be validated in the secondary region. If needed, use Change recovery point to select a different snapshot. Once satisfied, Commit the failover.
Configuring failover involves ensuring the VSS Provider service is installed and set to Automatic to create application-consistent snapshots. Performing Test Failovers is essential to validate your disaster recovery configuration without impacting production. If you encounter a no Mobility Service heartbeat error due to an expired tenant, update the TenantId and ClientId in the source machine's configuration file and restart services.
After a failover, the Commit process confirms the failover, making the secondary VM the permanent primary and deleting all other recovery points for that session. Once committed, the VM is in an unprotected state because replication has stopped. To re-establish protection, initiate reprotection, which sets up reverse replication from the secondary region back to the primary. Reprotection uses delta replication to copy only the changes made while the VM was in the secondary region. After reprotection, you can perform a failback, which is a planned failover to return the workload to the primary region.
Azure Backup provides reporting by sending diagnostic data from Recovery Services vaults to a Log Analytics workspace. Once configured, you view reports in the Azure portal through the Business Continuity Center. These reports give visibility into backup jobs, protected items, storage usage, and policy compliance. Reports integrate with Azure Monitor Logs for deep analysis with custom queries and with Azure Resource Graph for querying data across multiple subscriptions.
Reports help assess health and compliance by tracking metrics like success rates, failure trends, and job durations. You examine Backup Health Events and Restore Health Events to pinpoint issues. The Optimize tab identifies Inactive Resources (items without a recent successful backup) and highlights Retention Optimizations where items are kept longer than necessary.
Azure Backup alerts are categorized by severity: critical, warning, and informational. Critical alerts indicate serious problems like backup/restore failures or destructive operations. Warning alerts signal successful operations with minor issues. Alerting mechanisms include Built-in Azure Monitor Alerts (automatically created for critical scenarios), Metric Alerts (custom rules based on backup health metrics), and Log Analytics or Azure Resource Graph-based Alerts (for custom logic). Alerts are routed using Action Groups to channels like email or webhooks. Alert Processing Rules can suppress alerts during maintenance.
Azure Monitor collects and stores numerical values called metrics that describe aspects of a system at a particular point in time. These metrics are automatically gathered at regular intervals fro…
Azure Monitor collects and stores numerical values called metrics that describe aspects of a system at a particular point in time. These metrics are automatically gathered at regular intervals fro…
A Recovery Services vault is a central storage location in Azure for protecting workloads like virtual machines and databases. A key decision during creation is choosing a storage replication …
A Recovery Services vault is a central storage location in Azure for protecting workloads like virtual machines and databases. A key decision during creation is choosing a storage replication …
StudyCerts
StudyCerts