Monitor and Maintain Azure Resources practice questions

A Recovery Services vault

Why it fails: A Recovery Services vault handles backup and recovery rather than centralized log analytics.

Azure Network Watcher

Why it fails: Network Watcher focuses on network diagnostics and is not the main platform for general VM log analytics.

A load balancer

Why it fails: A load balancer distributes traffic and does not store monitoring data.

Yes. Azure Backup alone provides continuous service during a regional outage.

Why it fails: Azure Backup is fundamentally a data-protection service that captures recoverable snapshots of disks and databases; it is not designed to maintain a live, continuously available workload in another region. During a regional outage, the primary resources are unavailable, and Azure Backup would require you to manually initiate a restore before any service can resume, incurring significant downtime. Unlike Azure Site Recovery, it does not provide continuous replication, health monitoring, or automated failover to a secondary region, so it cannot deliver the required regional resilience.

Yes. Increasing the backup retention period will keep the application online.

Why it fails: Increasing the backup retention period only extends how far back you can restore data, but it does not create a secondary, running instance of the workload. Retaining more backup snapshots still requires a manual restore process to a new or recovered resource, which can take minutes to hours and cannot guarantee continuous availability. Because backups are point-in-time copies rather than synchronized replicas, they fail to meet the requirement of keeping the application online through a regional outage.

No. Configure an action group so operators receive faster notifications during outages.

Why it fails: Configuring an action group only controls who receives alert notifications and optionally triggers a webhook or automation runbook; it does not alter the infrastructure to keep the workload running. Alerts can tell operators that a regional outage has occurred, but the actual remediation—such as starting replica VMs or redirecting traffic—still requires a disaster recovery mechanism that action groups lack. The requirement is continuous availability, not merely faster awareness of an outage, so a notification-only solution does not satisfy the stated business need.

Create new VM: Overwrite the original VM with backup data

Why it fails: Create new VM provisions a brand-new Azure VM from the chosen restore point, complete with a new NIC, public IP (if selected), and storage resources, while leaving the original VM completely untouched. Because it does not modify the original VM's disks or configuration, it cannot overwrite the original VM with backup data; that in-place overwrite behavior is exclusively handled by the 'Replace existing VM' restore option.

Replace existing VM: Deploy a new virtual machine from a recovery point

Why it fails: Replace existing VM does not deploy a new VM instance; it performs an in-place disk swap by writing the restored OS disk (and optionally data disks) onto the existing VM's storage, preserving the VM's name, location, and resource identity. The option is only available when the original VM still exists, and it overrides the current disk contents with the recovery point data. If you need a brand-new deployment from a recovery point, you must use 'Create new VM' instead.

Log Analytics workspace

Why it fails: A Log Analytics workspace is used for collecting and analyzing diagnostic logs and monitoring data from Azure resources, including some Azure Backup reporting. It does not control backup timing or how long recovery points are retained; its role is purely observational. You could configure backup reports in Log Analytics, but the workspace itself is not a component of the backup policy that defines schedule or retention. Therefore, it is unrelated to the 'daily backups with 30-day retention' requirement.

Private endpoint

Why it fails: A private endpoint for Azure VM backups provides a private IP address in your virtual network to access the Recovery Services vault, eliminating exposure to the public internet. It changes network connectivity and security for backup traffic, but it has no effect on the backup schedule or retention duration. The policy that defines 'daily' and '30 days' remains completely separate from how the backup data is transmitted or accessed. Thus, it is not relevant to the backup frequency or retention requirement.

Metric alert threshold

Why it fails: A metric alert threshold is a condition used in Azure Monitor to trigger alerts when a metric crosses a specific value, such as CPU utilization or backup job failure count. It is a monitoring mechanism that notifies you of issues, not a configuration item that defines how frequently backups run or how long recovery points are kept. Setting an alert threshold would never change the backup schedule or retention policy. Hence, it is not a component of the backup policy design.

Metric alert rule

Why it fails: A metric alert rule continuously evaluates performance metrics like CPU, memory, or latency emitted by your own application resources. It cannot detect an Azure platform incident because it does not ingest Service Health data; during a regional outage, resource metrics may even become unavailable or show anomalies, but the alert only reflects symptoms, not the underlying platform event. Therefore, it is an incorrect choice when the requirement is to be notified about regional Azure service operations.

Log Analytics query

Why it fails: A Log Analytics query is a KQL expression that retrieves and analyzes logs collected in a Log Analytics workspace, but it has no built-in capability to raise alerts or watch live service events. To act as an alert, you would need to create a scheduled query rule that runs the query and triggers on specific results, yet even that would not inherently capture Azure Service Health updates unless you explicitly ingest them into the workspace. So standing alone, it does not meet the need for real-time alerts on regional service operations.

Resource lock

Why it fails: A resource lock (CanNotDelete or ReadOnly) is an access control mechanism that prevents accidental deletion or modification of a resource or resource group. It has nothing to do with monitoring service availability or receiving notifications about Azure platform incidents. Therefore, while it helps protect operational resources, it cannot be used to alert the team about regional Azure service issues.

A policy with daily backups retained for 7 days.

Why it fails: Although this policy applies the same daily cadence, its 7-day retention window falls far below the required 30-day retention period. After one week, the earliest recovery points expire, creating a blind spot where a restore from, say, day 10 or day 20 is no longer possible, which violates the explicit data retention requirement.

A policy with weekly backups retained for 30 days.

Why it fails: Here the retention period is sufficient at 30 days, but the backup frequency is only once per week, which means a single weekly recovery point protects at most the prior 7 days of changes. If a daily cadence is mandatory, a weekly schedule can lose up to a week of data, breaking the recovery point objective implicitly set by the requirement for daily backups.

A policy with daily backups retained for 365 days.

Why it fails: This policy does create daily recovery points and retains them for 365 days, but it over-retains data by a factor of more than 12 compared to the stated 30-day need. The extra 335 retention days add storage cost, long-term retention complexity, and potential compliance exposure without benefiting the requirement, so it is not the best match.

Provide the storage account access key

Why it fails: Storage account keys are unrelated to Azure VM backup file recovery workflows.

Assign a public IP address to the VM

Why it fails: File recovery mounts backup data through the portal workflow, not through public VM connectivity.

Create an Microsoft Entra ID application secret

Why it fails: Application secrets are not part of the standard Azure Backup file-level recovery process.

Azure Bastion

Why it fails: Azure Bastion is a fully managed Platform-as-a-Service offering that provides secure, browser-based RDP and SSH connectivity to virtual machines inside a VNet, eliminating public IP exposure. It operates at the network layer and has no access to metric evaluation pipelines or email notification services, so it cannot alert on average performance thresholds.

A Recovery Services vault

Why it fails: A Recovery Services vault is a management container for backing up Azure VMs, capturing snapshots and recovery points to support restore operations. Its role is limited to data protection and site recovery workflows; it does not subscribe to metric streams, analyze average utilization, nor initiate emails when a performance threshold is breached.

A resource lock

Why it fails: A resource lock is an Azure management control that restricts users from deleting or modifying a resource by setting CanNotDelete or ReadOnly protection. It enforces governance and compliance policies but is completely separate from Azure Monitor, and therefore cannot evaluate CPU averages or trigger outbound email notifications.

A virtual network peering connection

Why it fails: Virtual network peering is a non-transitive networking connection that enables private IP traffic exchange between two Azure virtual networks over the Microsoft backbone. It is a declarative configuration object, not an executable service, so an action group cannot invoke peering as a response to an alert. Even if a metric alert indicates a traffic issue, enabling peering would not be an automated remediation action; instead, you would need a runbook or function to call the Azure Networking API to create or modify peering if that were the desired recovery step.

A resource lock

Why it fails: A resource lock is an Azure governance control that applies a ReadOnly or CanNotDelete restriction at a subscription, resource group, or resource scope, and it is enforced by Azure Resource Manager to prevent accidental modification. Locking is not an event-driven action; it must be assigned ahead of time and is not in the list of supported action group actions (email, SMS, webhook, runbook, function, etc.). Consequently, you cannot configure a metric alert to apply a lock as a response, and conceptually a lock is about prohibiting changes rather than taking an action when a threshold is crossed.

A storage account access tier

Why it fails: Blob storage access tiers (hot, cool, and archive) are properties that control storage cost and latency based on access frequency, and they are set manually or via lifecycle management policies. Access tiers are operational settings, not triggerable endpoints, so they cannot be specified as an action type within an Azure Monitor action group. To automatically change a blob's access tier in response to a metric alert, you would pair the alert with an Azure Automation runbook or a function that calls the Set Blob Tier REST API—the action group itself cannot alter the tier directly.

Increase the recovery point retention in the backup policy.

Why it fails: Retention determines how long snapshots/recovery points are stored, not whether the backup job can start or complete; an immediate failure occurs during the pre-check/extension phase, long before any snapshot is taken. Increasing retention could actually increase storage costs and does nothing to fix agent unreadiness or blocked HTTPS endpoints.

Recreate the Recovery Services vault in another region.

Why it fails: Recovery Services vaults are regional resources, and the vault's location does not affect the VM agent's connectivity or extension provisioning; backups can be configured for VMs in other regions, and the agent's health is unrelated to vault placement. Recreating the vault would require you to reconfigure all backup policies and on-premises registration, wasting time while the same agent/network issue persists.

Disable the backup policy until the VM is rebooted several times.

Why it fails: Rebooting a VM does not reinstall a missing VM agent or restore broken outbound connectivity; the agent service typically starts automatically on boot, but if the agent is uninstalled or corrupted, a reboot won't repair it. Disabling the policy merely stops scheduling and doesn't address the root cause—it also delays protection and can increase the risk of data loss if the VM changes.

Configure diagnostic settings on the storage account and export the subscription Activity log to the same workspace.

Why it fails: Resource logs from the storage account are collected through diagnostic settings, while control-plane events at subscription scope come from the Activity log. Sending both to the same Log Analytics workspace makes the data available for a single KQL investigation workflow, which is what the requirement asks for.

Install the Azure Monitor Agent on the storage account so it can send its own logs.

Why it fails: Azure Monitor Agent is a guest agent that runs on a VM or server operating system; a storage account is a PaaS service with no OS to install an agent on. Storage account telemetry is generated as platform resource logs and routed through diagnostic settings to a Log Analytics workspace, not collected by an in-guest collector. Therefore, this approach cannot capture the security data required.

Create separate workspaces for each resource and query them independently.

Why it fails: Creating separate Log Analytics workspaces for the storage account and the subscription Activity log fragments the evidence across multiple query contexts, forcing the security team to run cross-workspace queries or jump between blades. The core requirement is a single place to investigate, and a unified workspace is essential for efficient KQL correlation. While cross-workspace queries are technically possible, they add overhead and do not satisfy the explicit request for one query environment.

Enable a diagnostic setting on the VM without creating an alert rule.

Why it fails: A diagnostic setting merely configures streaming and archiving of the VM's platform metrics and logs to a destination such as Log Analytics, Event Hubs, or Storage. Its purpose is telemetry collection, not signal evaluation: it contains no threshold, no evaluation frequency, no alert state, and no ability to call an action group. Without an alert rule that consumes that data or uses platform metrics directly, no notification or Function invocation will ever occur.

Create a Log Analytics workspace and rely on manual queries only.

Why it fails: Storing metrics and logs in a Log Analytics workspace makes them searchable via KQL, but manual queries are executed on demand by a user and do not run on a schedule. To get automatic detection and to start the Azure Function, you would need a separate log alert rule that periodically runs the query, compares results to a criterion, and triggers an action group. Relying on manual queries only means you must be actively watching the workspace, which does not satisfy the 'immediate' notification and automation requirement.

Apply a resource lock so CPU usage changes are blocked.

Why it fails: Resource locks are management-plane controls that prevent accidental deletion or modification of a resource, with lock types CanNotDelete and ReadOnly; they have no effect on guest OS or workload behavior. A compute-bound process inside the VM will still drive the CPU usage metric upward regardless of any lock, and locks cannot emit alerts or invoke Azure Functions. Hence, applying a lock addresses the impossible requirement of 'blocking CPU usage changes' and ignores the actual alerting pipeline needed.

Create an Activity Log alert for every blob write.

Why it fails: An Activity Log alert for every blob write watches for data-plane write operations, which are events about user activity, not about the health of the service. Because write operations are logged as audit events and are not correlated with platform availability, alerting on them would generate noise from normal traffic and fail to detect a storage outage or latency issue. Additionally, data-plane write logs are typically not sent to the Activity Log at all without diagnostic settings, making this option ineffective for health monitoring.

Send a workbook link in an action group instead of an alert.

Why it fails: Sending a workbook link in an action group is just a convenience for analysts to open a visual dashboard when an alert has already fired; it cannot evaluate conditions or initiate notifications by itself. A workbook is a data visualization tool that consolidates metrics and logs, but it does not compare thresholds or detect that Azure has marked the resource unhealthy. Therefore, attaching a workbook link does not create any alert rule and cannot proactively notify the team of a storage health issue.

Turn on Azure Policy compliance scanning for the storage account.

Why it fails: Azure Policy compliance scanning checks whether the storage account satisfies governance rules, such as allowed network access, encryption, or tag requirements. It does not read the runtime health or performance of the storage service, so it has no insight into availability, latency, or whether Azure has flagged the resource as unhealthy. This option addresses configuration compliance, not operational incidents, so it cannot fulfill the request to detect when Azure marks the storage account as degraded.

Enable guest-level Windows event collection on a random virtual machine.

Why it fails: Guest-level Windows event collection on a single VM uses the Azure Monitor Agent or diagnostics extension to gather OS-level logs such as System, Application, and Security events from that machine's own operation. It does not capture any telemetry from the Azure Storage service itself, so storage write failures due to account-level throttling, network issues, or SAS token problems remain invisible. Additionally, selecting a random VM likely unrelated to the incident yields no useful signal, and guest events are irrelevant to subscription-wide control-plane changes like role assignments.

Turn on NSG flow logs for every subnet in the subscription.

Why it fails: NSG flow logs capture IP traffic flowing through a network security group, recording five-tuple information (source/destination IP, port, protocol), and allow/deny decisions at the network layer. They might show whether a VM could reach the storage service, but they contain no information about the storage account's internal handling of a write operation—such as authentication, authorization, or service-side throttling. Turning on flow logs for every subnet generates significant cost and noise, and still leaves the control-plane role-change trail completely absent.

Use Azure Advisor recommendations as the source of telemetry.

Why it fails: Azure Advisor recommendations are precomputed, curated insights based on periodic assessment of resource configuration and usage—they surface actionable guidance like performance suggestions or security best practices. As a consumer of telemetry rather than a source of raw logs, Advisor does not emit streamable events that can be queried for the exact timestamp, operation, and error details of a storage write failure. It also cannot provide an audit trail of role assignments or key changes, so it is unsuitable for an incident investigation where traceable raw data is required.

A backup policy in Recovery Services vault to copy logs into the workspace.

Why it fails: A backup policy in a Recovery Services vault is designed to create snapshots and recovery points of Azure VMs or workloads for business continuity and disaster recovery, not to collect or stream Azure Activity Log or resource logs. Even if a backup policy were configured, it would not integrate with a Log Analytics workspace to make the data queryable via KQL. Logs that are not exported through diagnostic settings remain inaccessible to centralized monitoring; backup policies simply protect the underlying resource data.

A private endpoint for each storage account so the logs remain internal to Azure.

Why it fails: A private endpoint assigns a private IP address to a storage account from a virtual network, ensuring that traffic to the storage account stays within the Azure backbone and is not exposed to the public internet. This only affects network connectivity; it does not configure the storage account or subscription to send platform logs to a Log Analytics workspace. To centralize logs, you still need diagnostic settings that export Activity Log and resource logs to the workspace, regardless of whether the storage account is publicly reachable or only privately accessible.

A management group lock to prevent log deletion.

Why it fails: A management group lock applies an Azure Resource Manager-level restriction that prevents resources from being deleted or modified, but it has no ability to capture, export, or route logging data. Locking a subscription or resource does not send Activity Log events to a Log Analytics workspace; it only secures the resource's control plane. Centralized log collection requires a diagnostic setting configured at the subscription or resource level, not a lock. Thus, a lock addresses accidental deletion of the resource, not the aggregation of its logs.

Using Azure Backup Center to perform an on-demand restore of a deleted virtual machine to its original state.

Why it fails: Using Azure Backup Center to perform an on-demand restore of a deleted VM to its original state is a recovery operation, not a monitoring or maintenance routine. While Backup Center offers a centralized view of backup inventory and restore actions, the task itself is a reactive response after a failure, not ongoing observability or optimization. Moreover, restoring to the 'original state' may require the original resource group to exist, and the restored VM can be placed in a new or alternate location if the original is gone.

Deploying Azure Traffic Manager with a failover routing method to reroute traffic away from a healthy endpoint.

Why it fails: Deploying Azure Traffic Manager with failover routing method is a traffic-routing and high-availability solution, not a monitoring or maintenance task. Traffic Manager monitors endpoint health and directs traffic away from unhealthy endpoints, but the action described is about managing network routing, not observing or maintaining the resources themselves. This is a load-balancing configuration, which falls under networking architecture rather than the monitoring and maintenance scope.

Configure a lifecycle management policy on storage1 to move blobs to cool tier after 30 days and delete after 90 days.

Why it fails: This fails because lifecycle management policies manage blob data, not access logs. They do not capture read and write operations. The requirement is to log operations, not manage the blobs themselves. Lifecycle management is for data tiering and deletion, not auditing.

Enable Azure Defender for Storage and configure a security policy to export logs to storage2 for 90 days.

Why it fails: This fails because Azure Defender for Storage provides threat detection and security alerts, not detailed access logs for all read and write operations. It does not export logs to a storage account for retention. The requirement is for auditing all operations, which is done via storage logging, not Defender.

Enable diagnostic settings for storage1, select the blob service, and send the logs to storage2 with a retention of 90 days.

Why it fails: This fails because diagnostic settings for storage accounts send logs to Log Analytics, Event Hubs, or a storage account, but the retention for storage account destination is not configurable in diagnostic settings; you must use lifecycle management on the destination storage account. Also, the question specifies logs must be stored in storage2, which diagnostic settings can do, but retention is not set there. However, this option is plausible but technically incorrect for retention configuration.

Create an Azure Advisor recommendation alert.

Why it fails: Azure Advisor is a continuous assessment service that reviews resource configuration and emits recommendations for high availability, security, performance, and cost efficiency. It does not monitor a VM's CPU utilization in real time, and its alerts are triggered when a recommendation is generated or updated, not when a numeric metric crosses a threshold. Even a performance-oriented Advisor recommendation, like resizing an underutilized VM, is based on periodic telemetry analysis and is not a substitute for a metric alert on CPU usage.

Create an activity log alert for the virtual machine.

Why it fails: Activity log alerts inspect the subscription's activity log for control-plane (management plane) events, such as VM create, delete, restart, or scale operations. CPU usage percentage is a telemetry value collected as a resource metric, not an entry in the activity log, so an activity log alert cannot evaluate threshold conditions against it. You could alert on an administrator restarting the VM, but not on utilization crossing a performance threshold.

Create a subscription budget alert.

Why it fails: Subscription budget alerts are part of Azure Cost Management and track actual or forecasted spending against a monetary budget amount defined per subscription, resource group, or service. They trigger when cost aggregates exceed a percentage or absolute amount, not when performance metrics like average CPU usage reach a threshold. A VM CPU spike creates no cost event by itself, so a budget alert would never fire in response to that condition.

Azure Advisor.

Why it fails: Azure Advisor is a personalized recommendation engine that analyzes resource configurations and usage to suggest best practices for cost, security, reliability, and performance. It does not ingest raw telemetry, store logs, or provide a KQL query environment, so it is in no way a log analytics platform for querying performance and event data.

Azure Network Watcher only.

Why it fails: Azure Network Watcher is a network-specific diagnostic tool, not a general log analytics platform. While it provides packet captures, connection monitors, and NSG flow logs, it cannot aggregate OS-level performance counters, application event logs, or other guest telemetry, nor does it offer a KQL-based query interface for cross-resource log analysis.

A network security group.

Why it fails: A network security group (NSG) is a filtering mechanism that controls allowed or denied traffic at the subnet or NIC level. Although NSG flow logs can be sent to a Log Analytics workspace, the NSG itself does not store or query performance and event data—it simply evaluates traffic rules and has no built-in logging or analytics capability for VM guest metrics.

A resource lock

Why it fails: A resource lock is an Azure management control that prevents accidental deletion or modification of a critical subscription, resource group, or resource by setting a CanNotDelete or ReadOnly scope. This lock enforces governance and audit policy but never interacts with telemetry or log pipelines. While it might protect the firewall's configuration, it does not affect where the firewall's logs are sent or how they are retained for long-term analysis.

An availability set

Why it fails: An availability set is an Azure construct that groups virtual machines into fault domains and update domains to guarantee that a subset of VMs remains online during planned maintenance or hardware failures. It is purely a resiliency feature for VM placement and has no responsibility for capturing, exporting, or analyzing log data. In the context of Azure Firewall, it is irrelevant and cannot perform any retention or export role.

A VNet peering connection

Why it fails: VNet peering is a networking feature that connects two Azure virtual networks, enabling traffic to route between them with low latency over Microsoft's backbone. It is used exclusively for network connectivity and routing, not for data collection or monitoring. Peering has no bearing on Azure Firewall logs, and enabling or removing peering will not produce or store any log analytics data.