Domain 5: Practice Q&A — Monitor and Maintain

Answer each question before expanding the solution. Aim for under 2 minutes per question.

Q1

A VM's CPU percentage data is available in Azure Monitor's Metrics Explorer and shows data for the last 60 days. A security engineer wants to query this same metric data using KQL alongside log data. What must be done first?

  • A. Nothing — CPU metric data is automatically available in Log Analytics
  • B. Enable Diagnostic Settings on the VM to route platform metrics to a Log Analytics workspace
  • C. Install the Azure Monitor Agent on the VM
  • D. Create a custom metric namespace in Azure Monitor
Answer + Explanation

Correct: B — Enable Diagnostic Settings to route metrics to a Log Analytics workspace

Why B: Platform metrics (like CPU %) are automatically stored in the Azure Monitor Metrics Store for 93 days. However, to query them with KQL in Log Analytics, you must explicitly configure Diagnostic Settings on the resource to route metrics to a Log Analytics workspace. Once routed, they appear in the AzureMetrics table.

Why not A: Platform metrics are NOT automatically sent to Log Analytics — only to the Metrics Store.

Why not C: The Azure Monitor Agent collects OS-level metrics (memory, disk free space, custom app counters). It doesn't route platform metrics (which come from the Azure hypervisor, not inside the VM).

Why not D: Custom metric namespaces are for custom metrics emitted by applications — not for platform metrics.

Q2

Your team needs to receive an email when any resource in a specific resource group is deleted. Which alert type should you create?

  • A. Metric alert scoped to the resource group
  • B. Log query alert on the AzureMetrics table
  • C. Activity log alert scoped to the resource group
  • D. Resource health alert for the resource group
Answer + Explanation

Correct: C — Activity log alert

Why C: Deletion of a resource is an Azure management operation — it appears in the Activity Log (control-plane events). An activity log alert fires when a specific operation (e.g., write or delete) occurs within the scope. This is exactly what activity log alerts are designed for.

Why not A: Metric alerts monitor numeric thresholds (CPU, memory, bytes) — they don't fire on management operations.

Why not B: AzureMetrics contains resource metric data, not management operations. Deletion events appear in AzureActivity in Log Analytics.

Why not D: Resource health alerts fire when Azure detects the resource is degraded/unavailable from the platform side — not when a user deletes a resource.

Q3

You configure an Azure Backup policy for a VM with:

  • Daily backups retained for 7 days
  • Weekly backups retained for 4 weeks

A junior admin accidentally runs az backup protection disable --delete-backup-data true on the protected VM. What happens to the existing backup data?

  • A. All backup data is immediately and permanently deleted
  • B. Backup data is moved to soft-delete state and retained for 14 days before permanent deletion
  • C. The backup policy prevents deletion — admin must have Backup Contributor role
  • D. The vault retains the data according to the original retention policy (7 days daily, 4 weeks weekly)
Answer + Explanation

Correct: B — Soft delete retains data for 14 additional days

Why B: Azure Backup's soft delete feature (enabled by default on Recovery Services vaults) retains deleted backup data for 14 additional days after deletion. During this window, the data can be undeleted (restored back to active protection). After 14 days, it is permanently purged.

Why not A: Immediate permanent deletion only occurs if soft delete is explicitly disabled on the vault (and --delete-backup-data true is specified).

Why not C: The Backup Contributor role can disable protection. Soft delete is a vault-level safety net, not an RBAC restriction.

Why not D: The retention policy applies to scheduled backup points during active protection — it doesn't extend to backup data after protection is disabled.

Exam tip: Soft delete is a safeguard against ransomware and accidental deletion. Know that it's 14 days by default and that you can still undelete within that window.

Q4

You deploy a Standard Load Balancer with a backend pool of VMs. You want to alert your team if the Load Balancer's data path availability drops below 90% for more than 10 minutes. Which alert type is appropriate?

  • A. Activity log alert
  • B. Metric alert
  • C. Log query alert
  • D. Service health alert
Answer + Explanation

Correct: B — Metric alert

Why B: Data path availability is a numeric metric emitted by the Load Balancer to Azure Monitor. You create a metric alert with:

  • Metric: Data Path Availability
  • Condition: < 90
  • Window size: 10m
  • Aggregation: average

Why not A: Activity log alerts fire on Azure management operations — not on runtime performance metrics.

Why not C: A log query alert is possible (route metrics to Log Analytics, then write a KQL query), but it's more complex and higher latency than a direct metric alert. For real-time threshold-based alerts on known metrics, metric alerts are the correct and simpler choice.

Why not D: Service health alerts notify you of Azure platform incidents and maintenance — not resource-specific metric thresholds.

Q5

You use Azure Site Recovery to replicate a VM from East US to West US. During a DR drill, you perform a test failover. What is true about the test failover?

  • A. The production VM in East US is shut down and traffic shifts to West US
  • B. Replication is paused during the test failover
  • C. A new VM is started in West US in an isolated virtual network — production is not affected
  • D. The test failover permanently fails over the VM — you must fail back manually to restore production
Answer + Explanation

Correct: C — Test failover starts a VM in an isolated VNet; production is unaffected

Why C: Test failover spins up the replicated VM in the target region using an isolated virtual network (no production network connectivity). This lets you validate that the replicated VM boots, applications start, and recovery is successful — without touching production. After the test, you "clean up test failover" to remove the test VM. Replication continues throughout.

Why not A: That describes an actual failover (planned or unplanned), not a test failover.

Why not B: Replication continues normally during a test failover — that's the point.

Why not D: Test failover is always temporary and isolated. Replication continues and you can run another test failover later.

Exam tip: Understand the four ASR operations: Test Failover (isolated, no production impact) → Planned Failover (graceful, coordinated) → Unplanned Failover (emergency) → Failback (return to primary).

Q6

A company has an RTO of 1 hour and an RPO of 15 minutes for a critical Azure VM. Which solution meets BOTH requirements?

  • A. Azure Backup with daily backup policy
  • B. Azure Site Recovery replicating to a secondary region
  • C. Geo-redundant Storage for VM disks
  • D. Availability Zones with Standard Load Balancer
Answer + Explanation

Correct: B — Azure Site Recovery

Why B: ASR provides:

  • RPO of ~15 minutes (crash-consistent recovery points; ASR replicates continuously with recovery points every 15 minutes by default)
  • RTO of < 1 hour (failover can complete in minutes for a pre-tested DR plan with automation)

Both requirements are satisfied.

Why not A: Azure Backup takes daily snapshots — the RPO is up to 24 hours, far exceeding the 15-minute requirement.

Why not C: GRS replicates storage data but doesn't provide VM-level failover automation. You can't "fail over" to GRS — you'd need to manually reconstruct the VM from the replicated disks in the secondary region.

Why not D: Availability zones protect against datacenter failure within the same region — they don't provide cross-region DR. If the entire region fails, AZ-protected VMs fail too.

Q7

Azure Advisor shows a recommendation to "Enable soft delete for your Recovery Services vault." Your vault already has soft delete enabled. Why might Advisor still show this recommendation?

  • A. Advisor recommendations are cached and may lag up to 24 hours
  • B. Advisor requires a Log Analytics workspace linked to the vault to detect the setting
  • C. Soft delete was recently disabled and re-enabled — Advisor needs a manual refresh
  • D. Advisor recommendations cannot be dismissed and always appear even when resolved
Answer + Explanation

Correct: A — Advisor recommendations may be cached/delayed up to 24 hours

Why A: Azure Advisor scans resources periodically and caches results. After you make a change, it can take up to 24 hours for the recommendation to disappear. You can also manually Dismiss or Postpone a recommendation in the Advisor portal.

Why not B: Advisor doesn't require Log Analytics to detect vault settings — it reads resource configuration directly.

Why not C: Re-enabling a setting doesn't require a manual refresh beyond the normal scan cycle.

Why not D: Advisor recommendations can be dismissed — there's a "Dismiss" option for each recommendation.