Azure Monitor practice questions

Boot diagnostics

Why wrong: Boot diagnostics is a telemetry and troubleshooting feature that captures serial console output and screenshots to help diagnose why a VM failed to boot. It does not have any capacity to execute scripts or modify the virtual machine's configuration. While it uses the VM Agent to collect data, it is purely observational and cannot run a provisioning script.

Availability zone

Why wrong: An availability zone is a physically separate location within an Azure region that provides resiliency by isolating a VM from datacenter outages. Choosing a zone affects the VM's placement and availability, but it has no bearing on running initialization scripts or any post-deployment configuration logic. It is an infrastructure resilience setting, not a provisioning or scripting mechanism.

Ephemeral OS disk

Why wrong: An ephemeral OS disk places the virtual hard disk on the local node storage instead of Azure Storage, causing the disk to be deleted when the VM is deallocated. This affects persistence and IO performance but does not include any functionality to run scripts or automate setup. It is a storage deployment choice, unrelated to executing a bootstrap script during provisioning.

An availability zone

Why wrong: An availability zone is a set of physically isolated datacenters within an Azure region that protect applications from datacenter failures. It is an infrastructure resiliency feature, providing high availability for resources, but it has no ability to collect, store, or query operational logs. Therefore, availability zones cannot serve as a substrate for Kusto queries, which require a dedicated log analytics data store.

A NAT gateway

Why wrong: A NAT gateway is a fully managed networking service that enables outbound internet connectivity for subnets in a virtual network by performing source network address translation. Its functionality ends at IP address translation and routing; it does not retain telemetry logs or expose any querying interface. While NAT gateways can emit diagnostic metrics and logs to a Log Analytics workspace, they are not themselves a platform for running Kusto queries.

A standard public IP address

Why wrong: A standard public IP address is a standalone resource that assigns a public IPv4 or IPv6 address to an Azure VM, load balancer, or gateway for internet communication. It is purely an address allocation object, with no data plane for storing operational logs or a query engine to process Kusto queries. Diagnostic settings from resources using the IP can be streamed elsewhere, but the IP resource itself cannot be queried directly.

Install the Microsoft Monitoring Agent (MMA) on all servers and connect to a Log Analytics workspace.

Why wrong: The Microsoft Monitoring Agent (MMA) is the legacy Log Analytics agent that is being deprecated in August 2024 and lacks support for DCR-based configuration. It requires defining data sources at the workspace level and applies the same collection settings to all connected machines, making it inflexible for heterogeneous hybrid infrastructures. Choosing MMA over AMA would prevent you from using modern features like event transformation and per-DCR targeting, so it is not the correct deployment path.

Enable Network Watcher to monitor network traffic between on-premises and Azure.

Why wrong: Network Watcher provides network-level diagnostic tools such as traffic analytics, connection monitor, and VPN diagnostics, but it does not collect OS-level performance counters or application/event logs from servers. It operates within the Azure network control plane, so it cannot monitor on-premises servers unless they are behind a virtual network gateway, and even then it does not expose CPU/memory metrics. This makes it irrelevant to the requirement of gathering server telemetry from both Azure VMs and on-premises machines.

Create a VM Insights solution in the Azure portal to automatically collect data from all Azure VMs.

Why wrong: VM Insights is a monitoring solution designed specifically for Azure VMs (and Arc-enabled servers), but it is not a one-click "solution" that automatically onboards all VMs; you must explicitly enable it per machine or assign an Azure Policy to deploy it at scale. More importantly, it does not natively cover on-premises servers that are not connected through Azure Arc, leaving gaps in a hybrid infrastructure. Its data collection is also driven by predefined DCRs and may not be sufficient for custom performance counters and event logs, so it cannot replace a proper AMA + DCR deployment.

Create a log alert rule based on the VM's performance counters collected in Log Analytics.

Why wrong: Creating a log alert rule based on the VM's performance counters collected in Log Analytics is wrong for this scenario because log alerts depend on performance data being ingested into a Log Analytics workspace, which requires the Azure Monitor agent and diagnostic settings. This adds complexity and latency compared to a metric alert, which directly evaluates the VM's built-in platform metric. While log alerts are useful for complex cross-resource queries, they are not the optimal or most direct method for a single critical VM's CPU threshold alert.

Enable Azure Diagnostic Settings on the VM to send performance data to a storage account.

Why wrong: Enabling Azure Diagnostic Settings on the VM to send performance data to a storage account is wrong because diagnostic settings to a storage account are intended for archival, export, or compliance, not for real-time alerting. This action alone does not generate any alert; you would still need to create a log alert or external processing to analyze the stored data. For immediate CPU notification, a metric alert on the automatically available platform metric is the appropriate and efficient choice.

Configure an Application Insights availability test to monitor the VM's CPU.

Why wrong: Configuring an Application Insights availability test to monitor the VM's CPU is wrong because availability tests are designed to monitor the external reachability and response latency of HTTP/HTTPS endpoints, not server-side CPU utilization. They require a public URL and an agent to ping the endpoint from global locations, and they cannot read CPU metrics from an Azure VM. CPU monitoring belongs in Azure Monitor metrics, while availability tests belong to Application Insights web monitoring.

A managed disk snapshot created from one of the VMs

Why wrong: A managed disk snapshot is a point-in-time copy of a single VM's disk, often preserving machine-specific identifiers, drivers, and sysprep-unrelated state, which makes it an ungoverned and potentially ungeneralized artifact. It does not offer the same versioning, cross-region replication, or image definition management that an Azure Compute Gallery image version provides. Snapshots are primarily for backup and recovery, not for building a clean, repeatable golden image.

A custom script extension installed during VM provisioning

Why wrong: A custom script extension is executed on an existing VM during provisioning to install software or apply post-deployment settings, but it does not produce a reusable base image artifact. Every new VM must run the same script against whatever foundation image was chosen, which can lead to drift or failure if the underlying OS version or dependencies change. It is merely a configuration step—not a versioned, shareable image that captures the entire hardened state.

An availability set containing the VMs

Why wrong: An availability set is a logical construct that places VMs into different fault domains and update domains to maximize uptime during hardware failures or planned Azure maintenance. It contains no OS state, no image definition, and no configuration baseline, so it cannot be used to propagate a hardened Windows Server setting to new deployments. Its purpose is redundancy, not providing a reusable image artifact.

A Recovery Services vault

Why wrong: A Recovery Services vault is exclusively designed to hold backup data and replication artifacts for Azure Backup and Site Recovery, such as VM snapshots and recovery points. Although it is a storage-like container, it is not a valid diagnostic destination because platform log streaming requires a Log Analytics workspace, storage account, or Event Hub, and the vault lacks any log-consumption API.

An availability zone

Why wrong: An availability zone is a physically separated group of datacenters within an Azure region, engineered for fault isolation and redundancy of workloads; it is not a target for diagnostic exports. You cannot configure an availability zone in a diagnostic setting, because zones are about resource placement and high availability, not log ingestion or archival.

Azure Monitor Metrics: Collects and analyzes log data such as event logs and error traces.

Why wrong: This option reverses the core responsibilities of Azure Monitor Metrics and Azure Monitor Logs. Azure Monitor Metrics stores only numerical time-series values such as CPU and memory percentages; it has no schema for text payloads like event logs or error traces. Collecting and analyzing log data is exclusively the function of Azure Monitor Logs, which uses a Log Analytics workspace and KQL queries. Therefore, this statement is incorrect because it attributes log-handling capabilities to a metric-only platform.

Application Insights: Collects and analyzes numerical data such as CPU and memory usage.

Why wrong: While Application Insights can be configured with an SDK to send custom metrics or performance counters from within an application, it is not the service responsible for collecting host-level CPU and memory usage from Azure resources. That responsibility belongs to Azure Monitor Metrics, which gathers numerical performance data directly from the platform and guest OS agents. Application Insights focuses on application telemetry like requests, exceptions, and dependencies, so this definition misidentifies the tool. Hence it is an incorrect pairing of service and function.

1. Update DNS to point to Traffic Manager, 2. Create Traffic Manager profile, 3. Add endpoints with geographic mapping, 4. Set geographic routing method, 5. Configure monitoring settings.

Why wrong: This order is incorrect because DNS should be updated last, not first. Updating DNS before creating the profile or configuring routing would lead to traffic being routed to an unconfigured or misconfigured Traffic Manager, potentially causing errors. The profile and routing must be fully set up before DNS changes.

1. Create Traffic Manager profile, 2. Add endpoints with geographic mapping, 3. Set geographic routing method, 4. Configure monitoring settings, 5. Update DNS to point to Traffic Manager.

Why wrong: This order is incorrect because the geographic routing method should be set before adding endpoints. Adding endpoints first may cause them to be assigned default routing behavior, and the geographic mapping might not be applied correctly. The routing method defines how endpoints are evaluated, so it should be configured first.

1. Create Traffic Manager profile, 2. Set geographic routing method, 3. Configure monitoring settings, 4. Add endpoints with geographic mapping, 5. Update DNS to point to Traffic Manager.

Why wrong: This order is incorrect because monitoring should be configured after endpoints are added. Without endpoints, monitoring settings have nothing to apply to, and the monitoring configuration cannot be validated. Endpoints must exist before monitoring can be properly configured to check their health.

A Recovery Services vault policy

Why wrong: A Recovery Services vault policy governs backup and restore operations, not compute capacity. It defines retention ranges, backup frequency, and point-in-time recovery settings for Azure VMs or other protected workloads. While it might indirectly help recover a failed instance, it has no relationship to the VM Scale Set's instance count or scaling logic. Therefore, configuring a Recovery Services vault policy would never cause instances to be added automatically in response to load.

Boot diagnostics

Why wrong: Boot diagnostics captures serial console output and screenshots of a VM's startup process to assist with troubleshooting boot failures. It stores those logs in a managed storage account and can be viewed via the Azure portal or Azure CLI. Although boot diagnostics are often enabled on VM Scale Set instances for operational visibility, they are a telemetry and debugging tool only. They contain no logic to evaluate metrics, trigger scale events, or alter the number of running instances, so they cannot satisfy the requirement to add instances automatically.

Azure Advisor only

Why wrong: Azure Advisor is a recommendation service that analyzes resource configurations and usage patterns to suggest best practices for cost, performance, reliability, and security. For example, it might recommend enabling autoscale on a VM Scale Set or changing instance sizes, but it does not perform any actions on your behalf unless you manually accept and implement the recommendation. Advisory recommendations, even if followed, only lead to the creation or modification of an actual autoscale rule; Advisor alone never adds or removes instances. Thus, Azure Advisor cannot directly provide automatic instance scaling without the underlying Azure Monitor autoscale configuration.

Enable boot diagnostics and review the serial console output.

Why wrong: Boot diagnostics captures the VM's serial console output and screenshots, which is invaluable when a VM fails to start or the script errors during early boot. However, it is purely a diagnostic tool—it does not execute scripts, install agents, or modify the VM's state. Reviewing serial output can help you debug why the bootstrap failed, but it cannot perform the bootstrap itself.

Attach a read-only managed disk to store the configuration file.

Why wrong: Attaching a read-only managed disk provides persistent block storage that the VM can mount to access files, but it does not run any code or establish any authentication context. While you could store a bootstrap script on it, the disk alone cannot execute the script or trigger deployment-time actions; a separate mechanism like Custom Script Extension is required. Moreover, read-only disks are not a security boundary for secrets because the VM still needs a way to access them.

Use an availability set to keep the bootstrap script highly available.

Why wrong: An availability set is a logical grouping of VMs that ensures their physical placement across fault and update domains to preserve service availability during hardware failures or maintenance. It has no bearing on software installation, script execution, or identity management. While high availability is important for hosted services, it does not assist with bootstrapping a single VM; the bootstrap must be run individually regardless of placement.

Activity log

Why wrong: The Azure Activity log is a subscription-level control-plane log that records operations such as creating a vault, modifying backup policy, or enabling backup, but it does not contain the data-plane outcome of backup job execution like a successful copy of the VM's disks. While enabling or configuring a backup may produce Activity log entries, the job's completion status, throughput, and error details are not stored there. Thus Activity log cannot confirm whether yesterday's VM backup job succeeded.

Azure Advisor

Why wrong: Azure Advisor is a personalized recommendation engine that evaluates Azure resources for reliability, security, performance, and cost optimization. It can generate recommendations about backup configuration, such as enabling backup on unprotected VMs or reviewing backup health best practices, but it does not surface the status of individual backup jobs or a history of failed versus successful runs. Therefore, checking Advisor will not show whether yesterday's VM backup completed successfully.

Resource Graph

Why wrong: Azure Resource Graph is a query engine designed for resource inventory and metadata exploration, allowing Azure Resource Manager queries across subscriptions for resource properties. It can enumerate VMs, Recovery Services vaults, and their configuration (for example, whether backup is enabled), but it does not expose transient operational state such as the outcome of a specific backup job. A Resource Graph query cannot yield the backup job status for yesterday, making it unsuitable for this monitoring use case.

A metric alert on storage capacity with an action group.

Why wrong: Metric alerts on storage capacity monitor usage metrics like BlobCapacity, FileCapacity, or QueueCapacity, which are designed for capacity planning and cost management, not for detecting platform availability. During an actual outage, metric samples may stop being emitted rather than exceeding a threshold, so an action group tied to a capacity threshold would not fire. Even if capacity metrics spike, that is orthogonal to a service incident that leaves the storage account unreachable, making this option ineffective for the stated goal.

A log alert on storage diagnostic logs that watches for 503 responses.

Why wrong: A log alert watching diagnostic logs for 503 responses depends on continuous export of StorageRead/StorageWrite logs to a Log Analytics workspace, which introduces ingestion latency and operational cost. If the storage account or the Azure platform is degraded, those diagnostic logs may be incomplete or missing entirely, so the alert can silently fail during the exact incident it is meant to detect. Additionally, 503 responses can result from client-side throttling or retries rather than a regional service outage, leading to noisy or misleading notifications instead of a reliable health signal.

An Azure Policy assignment that audits the storage account state.

Why wrong: An Azure Policy assignment evaluates or enforces configuration such as allowed storage SKUs, public network access, or TLS versions, but it does not inspect the runtime health of a storage account. The audit effect only records compliance states in the Activity Log; it has no built-in alerting mechanism to notify operators about live platform incidents or regional outages. It is a governance tool, not an availability monitoring or incident-notification solution.

A diagnostic setting

Why wrong: A diagnostic setting funnels collected platform metrics and logs to storage accounts, event hubs, or Log Analytics workspaces for centralization and archival. It is a data export mechanism, not a notification delivery path, and it cannot send emails, SMS, or webhook calls when an alert fires. Diagnostic settings are complementary to alert rules—they don't replace the action group that receives actionable alert notifications.

A Log Analytics workspace

Why wrong: A Log Analytics workspace is a centralized storage and querying repository for logs and some metrics; you can run KQL queries and build log alert rules on the data, but the workspace itself is not a destination for metric alert notifications. Metric alert rules evaluate resource metrics and then activate separate action groups; the workspace is simply one possible consumer of diagnostic export data. Thus a Log Analytics workspace might be where you analyze alert history, but it is not the target that receives or transmits the alert's notification.

An Azure Policy initiative

Why wrong: An Azure Policy initiative is a logical container of multiple policy definitions used to enforce lifecycle and compliance rules across resources, such as requiring specific Azure signatures or tag conventions. Initiatives are evaluated continuously and can take remediation actions, but they have no concept of an alert condition, firing notification, or webhook payload. Because an alert rule must call an action group to execute its notification logic, choosing an initiative describes governance, not alerting.

A snapshot of the reference VM's OS disk

Why wrong: A snapshot captures a read-only copy of the reference VM's OS disk at a specific point in time, and you could create a new disk or VM from it, but snapshots lack the versioning, cross-region replication, and role-based sharing control of Azure Compute Gallery. Snapshots are point-in-time recovery tools, not optimized for repeatedly provisioning dozens of identical VMs, nor do they support multi-version lifecycle management. Using a snapshot would also require manual steps to generalize or update the OS, making it impractical for uniform fleet deployment.

An availability set for the reference VM

Why wrong: Placing the reference VM in an availability set improves resilience by spreading replicas across fault and update domains, but it does not capture the VM's software state or make that build reusable. An availability set is a placement construct for high availability, not an image management or versioning mechanism. To standardize 30 VMs, you need a captured, versioned image—not a logical grouping—so this option fails to address the core requirement.

A custom script extension on each new VM

Why wrong: Custom script extensions execute post-boot scripts on each new VM, which can install applications or apply settings, but this approach is fragile because it depends on script maintenance, network access to dependencies, and repeatable execution without drift. It also does not produce a golden image or a versioned catalog, making deployments less consistent and slower than pre-configured images. For a hardened reference build, capturing an image in Azure Compute Gallery is far more reliable than scripting every deployment.

Enable diagnostic settings on each VM and send all guest logs to a storage account.

Why wrong: Enabling diagnostic settings and sending all guest logs to a storage account will stream every event from the system, application, and security logs into an unstructured blob container, creating unnecessary egress and storage costs. This approach does not support real-time alerting or querying against those logs, and it lacks the targeted collection of only CPU and disk free space counters. A data collection rule with Azure Monitor Agent is far more precise and cost-effective.

Install Application Insights on each VM and enable request tracing.

Why wrong: Application Insights is designed for application performance monitoring, such as request rates, dependency call durations, and exceptions from instrumented code, not for guest OS counters like CPU utilization or free disk space. The Application Insights agent on a VM also targets .NET web apps and requires application-level instrumentation, so it would not deliver the required performance counters to Log Analytics. Selecting it would add unnecessary overhead and fail the original monitoring requirement.

Create a resource lock on each VM to preserve the current state.

Why wrong: A resource lock is a governance control that prevents accidental deletion or modification of a VM, which is unrelated to collecting performance telemetry. Locking a VM would not generate CPU or disk utilization metrics, nor would it send any data to Log Analytics for alerting and reporting. Thus, while a lock can protect a resource, it cannot satisfy the requirement to monitor host performance counters.

A metric alert with the same threshold applied to every resource that needs notification.

Why wrong: A metric alert with the same threshold applied to multiple resources creates detection rules that evaluate specific metric conditions, but the alert rule itself is not a notification container. To notify users, a metric alert must reference an action group; the rule only defines the condition that triggers the action. Additionally, metric alerts are scoped to specific resources or a resource scope, so you would still need to link the same action group to each alert rule to achieve consistent delivery — the threshold does not, by itself, define who gets alerted. This approach also fails to cover other alert types like log alerts or activity log alerts, which require the same shared action group configuration.

A diagnostic setting on each resource so the contact list is stored with the logs.

Why wrong: A diagnostic setting on each resource configures the export of platform logs and metrics to destinations such as a Log Analytics workspace, storage account, or Event Hub for retention and analysis. It neither defines nor stores notification recipients — diagnostic settings are a telemetry pipeline, not an alert delivery mechanism. Even if every resource had a diagnostic setting configured, no email, SMS, or webhook would be triggered because Azure Monitor requires an action group to execute those actions, and diagnostic settings have no concept of a contact list. Storing contact data alongside logs would also be ineffective since alert rules are evaluated independently of diagnostic destination configuration.

A Log Analytics workbook used as the shared notification destination.

Why wrong: A Log Analytics workbook is an interactive canvas for building reports and visualizations from query data, often used for dashboards and post-incident analysis. Workbooks are not an endpoint that can receive or process alert notifications; Azure Monitor action groups support delivery channels such as email, SMS, push notifications, webhooks, ITSM connections, and Automation runbooks. Even if a workbook were linked somewhere, it cannot execute an email or webhook when an alert fires, so it is fundamentally unsuitable as a shared notification destination. Workbooks complement alerts by visualizing their results, but they do not replace the action group mechanism.

A snapshot of the OS disk

Why wrong: A snapshot is a point-in-time, dependent copy of an OS or data disk that preserves the exact state of the disk at capture time, including machine-specific identifiers. You can create a new VM from a snapshot, but it is not generalized or intended to serve as a versioned, reusable baseline for deploying multiple standardized VMs. Snapshots also do not support the image-based life cycle of patching, capturing, and replicating an approved software build.

An availability set

Why wrong: An availability set is a logical placement construct in Azure that distributes VMs across separate fault domains and update domains to protect against hardware failures and planned maintenance downtime. It defines how VMs are physically arranged in the datacenter, but it captures no operating system, installed patches, applications, or configuration settings. Therefore, it cannot be used as a template or source artifact for creating new, already-patched VMs.

A larger VM size

Why wrong: Selecting a larger VM size simply increases the compute resources (vCPUs, memory, and temporary storage) assigned to an existing virtual machine. This change does not read or modify the contents of the OS disk, so it cannot preserve the installed patches or any other software configuration. Resizing is a capacity scaling operation, not a mechanism for creating reusable deployment artifacts, and thus it fails to address the need for a standardized VM build.

Create a log search alert on the VM performance data and attach a resource lock.

Why wrong: A log search alert on VM performance data would require sending diagnostics to a Log Analytics workspace, adding cost and ingestion latency compared to a platform metric alert. A resource lock is designed to protect Azure resources from accidental deletion or modification; it cannot evaluate CPU thresholds or trigger notifications. Even if the log alert fired, without an action group attached there is no channel to actually contact the team, and the resource lock is entirely irrelevant to monitoring.

Assign an Azure Policy definition to the VM to stop it when CPU exceeds the threshold.

Why wrong: Azure Policy performs compliance evaluation and remediation of configurations on resources, such as tagging or allowed SKUs; it does not inspect runtime performance metrics like Percentage CPU. No built-in policy defines 'stop VM if CPU exceeds threshold,' and even a custom initiative cannot react dynamically to metric spikes because policy evaluation is not an event-driven alerting engine. Stopping a VM would also require an automation runbook or a conditional deployment, not a policy assignment, and it would not send a notification.

Enable diagnostic settings on the VM and send the data only to a storage account.

Why wrong: Diagnostic settings only stream performance counters and logs to a destination; a storage account is simply an archive sink. Without an alert rule that queries that data and without an action group, no email/SMS is ever generated, so the operations team remains unaware of CPU spikes. This approach enables post-incident analysis but fails the real-time notification requirement.

A role assignment at the subscription scope

Why wrong: A role assignment at the subscription scope controls access permissions through Azure RBAC, determining who can read, write, or manage resources within the subscription. It has no data-plane capability to capture, route, or export telemetry from a VM to a Log Analytics workspace—that is a functional role of diagnostic settings and agents. Even assigning the Log Analytics Contributor role enables managing workspace resources, but it does not by itself cause any log data to flow from a VM into the workspace.

A private endpoint

Why wrong: A private endpoint is a network construct that assigns a private IP address to an Azure service from your virtual network, enabling private connectivity to that service. In the context of a Log Analytics workspace, a private endpoint would affect how the VM reaches the workspace's ingestion endpoint, but it does not initiate or perform log collection on its own. Without a diagnostic setting and a properly configured agent, the VM guest logs will not be sent to a workspace regardless of network connectivity.

A lock on the VM resource group

Why wrong: A lock placed on the VM resource group (or the VM itself) provides a safeguard against accidental deletion or modification by enforcing a 'CanNotDelete' or 'ReadOnly' state. It is a governance and protection tool that prevents administrative changes, but it has zero involvement in log collection, telemetry streaming, or workspace integration. Locks operate on the management plane of Azure and do not influence the data plane or guest OS activity.

In the VM's network security group

Why wrong: An NSG (network security group) is a filtering component that controls inbound and outbound network traffic to a VM or subnet using allow/deny rules. It does not interact with the Azure Backup service and therefore has no concept of backup job status, nor does it expose backup success or failure data. Checking an NSG can only verify network access, not backup operations.

In the VM's availability set

Why wrong: An availability set is a logical grouping of VMs that distributes instances across fault domains and update domains to protect against hardware failures and planned maintenance. Its function is to improve resiliency and uptime, not to report on backup operations. The availability set contains no monitoring or job-history capabilities relevant to Azure Backup.

In the subscription activity log only

Why wrong: The subscription activity log records control-plane (Azure Resource Manager) operations such as creating a vault, enabling backup, or assigning permissions, but it does not capture the data-plane status of each backup job execution. While you might see a read of a backup configuration, backup job outputs (success/failure, duration, errors) are maintained inside the Recovery Services vault. Relying only on the activity log would miss the detailed and current backup job status that the vault provides.