Backup practice questions

A developer wants to keep application data separate from the operating system so the VM can be rebuilt without losing files. Before making a risky change, the administrator also wants a fast rollback point for that data disk. Which two actions should the administrator take? Select two.

Trap 1: Use an ephemeral OS disk for the application files

An ephemeral OS disk is stored on the VM's local temp drive (SSD or NVMe) and is not backed by Azure Storage. Its contents are lost when the VM is stopped/deallocated, redeployed, or rebooted for maintenance on some instances, and it cannot hold durable application data. Using it for application files means critical state may vanish without warning, leading to application failures or data loss. Ephemeral disks are intended only for temporary caching or workloads that tolerate recreating data from an external source.

Trap 2: Keep the files only on the OS disk and rely on reimaging

Storing application data on the OS disk couples your data lifecycle to the VM image and the OS disk's health. Reimaging replaces the entire OS disk with a fresh copy from the image, erasing any files that were added or modified—including your application data—unless you had already captured them in a custom image. Additionally, if the OS disk experiences corruption or must be deleted to resize the VM, the data goes with it. This approach eliminates the isolation that Azure's data disk architecture exists to provide.

Trap 3: Delete and recreate the VM from the same image

Deleting a VM and recreating it from the same image discards the current OS disk and any attached data disks, unless you explicitly detach and preserve them beforehand. The image represents only the captured or marketplace configuration at the time it was created, so any subsequent writes, user data, or runtime state are lost forever. Merely recreating the VM does not restore the pre-change state of the data disk; it resets to the image's baseline. Without a separate backup or snapshot, this action amplifies data loss instead of protecting against it.

A
Store the application data on a separate managed data disk
A managed data disk is an independent virtual hard disk (VHD) attached to the VM via the Azure storage subsystem. Because it sits outside the OS disk, it survives VM reimaging, resize, or even deletion of the VM itself, as long as the disk is not deleted. This separation lets you rebuild or patch the OS without touching application data, and you can independently snapshot, back up, or replicate the data disk for disaster recovery. It is the canonical Azure best practice for durability and operational flexibility.
B
Create a snapshot of the data disk before the change
Creating a snapshot before modifying the data disk gives you a crash-consistent, point-in-time restore point. Managed disk snapshots are incremental, meaning they only capture changed blocks since the last snapshot, making them quick and cost-efficient. If the change causes corruption or unintended data loss, you can create a new managed disk from the snapshot and attach it to the VM, or even restore the original disk, minimizing downtime. This proactive safety measure is a standard pre-change control in production environments.
C
Use an ephemeral OS disk for the application files
Why wrong: An ephemeral OS disk is stored on the VM's local temp drive (SSD or NVMe) and is not backed by Azure Storage. Its contents are lost when the VM is stopped/deallocated, redeployed, or rebooted for maintenance on some instances, and it cannot hold durable application data. Using it for application files means critical state may vanish without warning, leading to application failures or data loss. Ephemeral disks are intended only for temporary caching or workloads that tolerate recreating data from an external source.
D
Keep the files only on the OS disk and rely on reimaging
Why wrong: Storing application data on the OS disk couples your data lifecycle to the VM image and the OS disk's health. Reimaging replaces the entire OS disk with a fresh copy from the image, erasing any files that were added or modified—including your application data—unless you had already captured them in a custom image. Additionally, if the OS disk experiences corruption or must be deleted to resize the VM, the data goes with it. This approach eliminates the isolation that Azure's data disk architecture exists to provide.
E
Delete and recreate the VM from the same image
Why wrong: Deleting a VM and recreating it from the same image discards the current OS disk and any attached data disks, unless you explicitly detach and preserve them beforehand. The image represents only the captured or marketplace configuration at the time it was created, so any subsequent writes, user data, or runtime state are lost forever. Merely recreating the VM does not restore the pre-change state of the data disk; it resets to the image's baseline. Without a separate backup or snapshot, this action amplifies data loss instead of protecting against it.

Question 2mediummatching

Match each access scenario to the SAS or key type that best fits it.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

User delegation SAS

Service SAS

Account SAS

Storage account key

Trap 1: Interactive logins: Storage account access keys

Storage account access keys are shared keys that confer full administrative control over the entire storage account, including the ability to read and delete all data, so they completely violate the principle of least privilege for an interactive user login. They cannot be scoped to a single user or operation, do not expire automatically, and are intended only for admin-level account management. In any interactive scenario, a user delegation SAS or Azure AD-based access should be used instead.

Trap 2: Automated backups: User delegation SAS

A user delegation SAS is inherently user-oriented because it is signed with an individual Azure AD user's credentials and expires after a short interval, so it is unsuitable for unattended, recurring backup processes. Automated backups need a credential that can authenticate without a manually signed token and that does not require scheduled rotation, which is exactly what a system-assigned managed identity provides. Relying on a SAS for backups would risk service interruption every time the token expires.

Trap 3: Cross-tenant access: System-assigned managed identity

A system-assigned managed identity is tied to both a single Azure resource and a single Azure AD tenant, so it cannot authenticate to resources in a different tenant where it has no identity or trust relationship. Cross-tenant access depends on a service principal that is explicitly registered and consent-granted in the target tenant, allowing its RBAC assignments to cross tenant boundaries. Managed identities are therefore limited to same-tenant scenarios such as reading storage in the same subscription.

A
Interactive logins: User delegation SAS
A user delegation SAS is signed with Azure AD credentials rather than a storage account key, meaning it can be issued to an individual user with narrowly scoped permissions and a configurable expiration. This makes it ideal for interactive logins where a human needs temporary, least-privilege access to specific blobs or containers. It requires the calling principal to have the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey permission.
B
Automated backups: System-assigned managed identity
Automated backups need to write data continuously without human intervention or the burden of maintaining credentials, and a system-assigned managed identity gives an Azure resource a first-class identity in Azure AD with no secrets to store or rotate. When a backup service or workload uses its own managed identity, it can authenticate to Azure Storage via Azure AD and be granted exactly the RBAC roles needed for backup operations. This is secure and fully automated, unlike key-based or SAS-based approaches.
C
Cross-tenant access: Service principal with certificate
Cross-tenant access requires an identity that exists outside the context of a single resource's tenant, and a service principal with a certificate provides that independent, strongly authenticated identity. The service principal is registered in the home tenant and can be granted RBAC permissions in another tenant, while the certificate proves the principal's identity without exposing secrets. This is a standard pattern for multi-tenant applications and federated automation scenarios.
D
Interactive logins: Storage account access keys
Why wrong: Storage account access keys are shared keys that confer full administrative control over the entire storage account, including the ability to read and delete all data, so they completely violate the principle of least privilege for an interactive user login. They cannot be scoped to a single user or operation, do not expire automatically, and are intended only for admin-level account management. In any interactive scenario, a user delegation SAS or Azure AD-based access should be used instead.
E
Automated backups: User delegation SAS
Why wrong: A user delegation SAS is inherently user-oriented because it is signed with an individual Azure AD user's credentials and expires after a short interval, so it is unsuitable for unattended, recurring backup processes. Automated backups need a credential that can authenticate without a manually signed token and that does not require scheduled rotation, which is exactly what a system-assigned managed identity provides. Relying on a SAS for backups would risk service interruption every time the token expires.
F
Cross-tenant access: System-assigned managed identity
Why wrong: A system-assigned managed identity is tied to both a single Azure resource and a single Azure AD tenant, so it cannot authenticate to resources in a different tenant where it has no identity or trust relationship. Cross-tenant access depends on a service principal that is explicitly registered and consent-granted in the target tenant, allowing its RBAC assignments to cross tenant boundaries. Managed identities are therefore limited to same-tenant scenarios such as reading storage in the same subscription.

Question 3hardmatching

A VM suffered corruption and an auditor also needs one missing file. Match each Azure Backup restore workflow to the recovery outcome it provides.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Creates a separate virtual machine from the recovery point.

Recovers the managed disks so you can rebuild or inspect the workload manually.

Mounts the recovery point so you can retrieve individual files or folders.

Restores from the paired region when the primary region is unavailable.

Trap 1: Restore VM: Recovers individual files

This is incorrect because the Restore VM operation is designed to deploy an entire virtual machine from the recovery point, not to extract individual files. If you only need a few files or folders, Azure Backup provides a dedicated Restore files workflow that mounts the backup as a network drive without provisioning a VM. Using Restore VM for file recovery would be unnecessarily resource-intensive and does not give you direct file access.

Trap 2: Restore files: Overwrites the original VM

This is wrong because the Restore files operation mounts a read-only copy of the backup for file browsing and extraction; it never touches or overwrites the original VM's data. In contrast, overwriting the original VM is only achieved through the Replace existing VM restore option, which actively writes backup data back to the VM's managed disks. Restore files is non-destructive and leaves both the original VM and the backup unchanged.

A
Restore VM: Creates a new VM
Restore VM is the default restore action in Azure Backup for IaaS VMs. It creates a brand-new virtual machine from the selected recovery point, letting you choose a target resource group, virtual network, and storage settings while leaving the original VM untouched. This is the go-to method when the original VM is corrupted beyond repair and you need a fully functional replacement with the same disks and configuration.
B
Restore files: Recovers individual files
Restore files is a separate Azure Backup workflow that mounts the selected recovery point as an iSCSI target on a designated machine, not as a full VM. This enables granular recovery of individual files or folders from the backup without incurring the overhead of deploying an entire virtual machine. It is ideal when only a few files are missing or corrupt and the original VM itself remains operational.
C
Replace existing VM: Overwrites the original VM
Replace existing VM is an Azure Backup restore option that writes the disks from the recovery point directly onto the original VM, overwriting its current state. This operation is destructive because the live VM's data is replaced by the backup snapshot, so it should be used only when you need to revert the same VM resource to an earlier state. The VM's identity, NICs, and other attached resources are preserved, but all changes made after the recovery point are lost.
D
Cross-region restore: Restores to another region
Cross-region restore is available when the Recovery Services vault has Cross-Region Restore enabled and uses geo-redundant storage for backups. This option restores the VM (or its disks) to the paired Azure region, providing disaster recovery capability if the primary region is unavailable. It is particularly valuable for compliance or business continuity scenarios where a secondary copy of the VM must be created in a different geography.
E
Restore VM: Recovers individual files
Why wrong: This is incorrect because the Restore VM operation is designed to deploy an entire virtual machine from the recovery point, not to extract individual files. If you only need a few files or folders, Azure Backup provides a dedicated Restore files workflow that mounts the backup as a network drive without provisioning a VM. Using Restore VM for file recovery would be unnecessarily resource-intensive and does not give you direct file access.
F
Restore files: Overwrites the original VM
Why wrong: This is wrong because the Restore files operation mounts a read-only copy of the backup for file browsing and extraction; it never touches or overwrites the original VM's data. In contrast, overwriting the original VM is only achieved through the Replace existing VM restore option, which actively writes backup data back to the VM's managed disks. Restore files is non-destructive and leaves both the original VM and the backup unchanged.

Question 4easymultiple choice

Before changing a production VM's data disk, you want a point-in-time copy that can be restored later without affecting the VM. What should you create?

Trap 1: Availability set

An availability set is a logical grouping of VMs that spreads workloads across fault domains and update domains to increase availability during platform maintenance or failures. It does not capture or preserve the contents of a data disk; it only ensures that some VMs remain available, so it is irrelevant for creating a point-in-time copy.

Trap 2: Azure Policy assignment

Azure Policy assignment does not create any copy of disk contents; it evaluates and enforces compliance rules on resources, such as requiring specific SKUs or tags. While it can trigger remediation tasks, it neither snapshots nor backs up data, so it cannot serve as a recovery point for a VM's data disk.

Trap 3: Virtual network peering

Virtual network peering connects two Azure virtual networks to route traffic between them with low latency, but it operates at the network layer and has no involvement with disk I/O or data persistence. It cannot create a point-in-time copy of a disk; it merely enables resource communication across networks, making it useless for pre-change disk backup.

A
Snapshot
A snapshot of a managed disk captures the disk state at a specific point in time, storing only the changes (incremental) or a full copy depending on type. It can be used to create a new managed disk or restore the original disk, making it ideal before modifications like resizing or changing a data disk.
B
Availability set
Why wrong: An availability set is a logical grouping of VMs that spreads workloads across fault domains and update domains to increase availability during platform maintenance or failures. It does not capture or preserve the contents of a data disk; it only ensures that some VMs remain available, so it is irrelevant for creating a point-in-time copy.
C
Azure Policy assignment
Why wrong: Azure Policy assignment does not create any copy of disk contents; it evaluates and enforces compliance rules on resources, such as requiring specific SKUs or tags. While it can trigger remediation tasks, it neither snapshots nor backs up data, so it cannot serve as a recovery point for a VM's data disk.
D
Virtual network peering
Why wrong: Virtual network peering connects two Azure virtual networks to route traffic between them with low latency, but it operates at the network layer and has no involvement with disk I/O or data persistence. It cannot create a point-in-time copy of a disk; it merely enables resource communication across networks, making it useless for pre-change disk backup.

Question 5easymultiple choice

Based on the exhibit, where should the administrator go next to review the failed backup job details?

Exhibit

Recovery Services vault > Jobs
Last 24 hours:
- Backup job: Succeeded
- Backup job: Failed
- Restore job: In progress
Need: Review the error details for the failed backup job

Trap 1: Backup policy, because it shows the retention and schedule…

The Backup policy blade defines the backup schedule and retention rules, such as when backups are taken and how long recovery points are kept. It does not store any runtime execution history or per-attempt error information, so it cannot indicate whether a specific backup job succeeded or failed. It is a configuration object, not an operational log, making it the wrong place to look for failure details.

Trap 2: Backup items, because it lists protected resources and recovery…

The Backup items blade shows the protected resources within the vault and their associated recovery points. While it may show the latest backup status for each item, it does not provide the granular error details or job-level history of individual backup attempts. Its purpose is to manage and monitor the protection state of workloads, not to drill into the failure diagnostics of a specific job entry.

Trap 3: Properties, because it contains the general vault settings.

The Properties blade displays general vault-level settings such as the vault's subscription, resource group, ID, and encryption configuration. It contains no backup job activity, job history, or runtime errors, and it is not designed to surface operational health information. Because the exhibit shows a failed backup job, the Properties blade lacks any of the diagnostic data needed to investigate the failure.

A
Backup policy, because it shows the retention and schedule configuration.
Why wrong: The Backup policy blade defines the backup schedule and retention rules, such as when backups are taken and how long recovery points are kept. It does not store any runtime execution history or per-attempt error information, so it cannot indicate whether a specific backup job succeeded or failed. It is a configuration object, not an operational log, making it the wrong place to look for failure details.
B
Backup items, because it lists protected resources and recovery points.
Why wrong: The Backup items blade shows the protected resources within the vault and their associated recovery points. While it may show the latest backup status for each item, it does not provide the granular error details or job-level history of individual backup attempts. Its purpose is to manage and monitor the protection state of workloads, not to drill into the failure diagnostics of a specific job entry.
C
Jobs, because it contains the backup job status and error details.
The Jobs blade in a Recovery Services vault is the operational log for Azure Backup. It lists every backup, restore, and protection-change operation with a status such as Completed, Failed, or In Progress, and for failed jobs it surfaces the specific error code and a detailed message. Selecting the failed job from the exhibit opens its full error context, including the impacted data source and timestamps, which is exactly what you need to diagnose the failure.
D
Properties, because it contains the general vault settings.
Why wrong: The Properties blade displays general vault-level settings such as the vault's subscription, resource group, ID, and encryption configuration. It contains no backup job activity, job history, or runtime errors, and it is not designed to surface operational health information. Because the exhibit shows a failed backup job, the Properties blade lacks any of the diagnostic data needed to investigate the failure.

Question 6mediummultiple choice

Based on the exhibit, a user accidentally deleted one file from the VM and you need to restore only that file without recovering the entire virtual machine. What should you use?

Exhibit

Recovery Services vault > Backup item > vm-finance01
Restore points available: 3
Most recent recovery point: 2026-04-25 01:00 UTC
Requirement: restore C:\Data\Quarterly\budget.xlsx only

Trap 1: Restore the entire VM to the original resource group.

Restoring the entire VM to the original resource group may overlap with the existing VM's name, IP addresses, or managed disks, causing restoration failures or requiring you to delete or rename the current VM. Even if you choose 'create new VM', you are restoring all disks and the full operating system when only one file is missing, which dramatically increases restore time. File-level recovery is the least invasive option because it mounts just the disk from the recovery point so you can copy out the specific file.

Trap 2: Create a new backup policy with longer retention and wait for the…

Changing backup retention does not retroactively affect existing restore points; retention policies only govern how long new backups are kept. The missing file is already present in the current recovery point, so you can launch a file recovery immediately without waiting for another backup. Postponing recovery increases the risk of additional data loss and is unnecessary, because the recovery point already contains the exact file you need.

Trap 3: Use Azure Monitor alerts to trigger an automatic file restore.

Azure Monitor alerts are designed to notify on conditions such as resource health or metric thresholds; they have no native built-in action to execute an Azure Backup file recovery. While an action group could theoretically trigger an automation runbook that calls Backup REST APIs, that is custom engineering, not a supported out-of-box recovery mechanism. The intended and supported path to retrieve a single file is to use Azure Backup's 'File Recovery' option from an available recovery point.

A
Run file recovery from the available recovery point.
Azure VM backup supports file-level recovery from a restore point. Because only one file is needed, file recovery is the least disruptive and most efficient choice. It mounts the recovery point and lets you copy back the missing file without restoring the entire VM or its disks.
B
Restore the entire VM to the original resource group.
Why wrong: Restoring the entire VM to the original resource group may overlap with the existing VM's name, IP addresses, or managed disks, causing restoration failures or requiring you to delete or rename the current VM. Even if you choose 'create new VM', you are restoring all disks and the full operating system when only one file is missing, which dramatically increases restore time. File-level recovery is the least invasive option because it mounts just the disk from the recovery point so you can copy out the specific file.
C
Create a new backup policy with longer retention and wait for the next backup.
Why wrong: Changing backup retention does not retroactively affect existing restore points; retention policies only govern how long new backups are kept. The missing file is already present in the current recovery point, so you can launch a file recovery immediately without waiting for another backup. Postponing recovery increases the risk of additional data loss and is unnecessary, because the recovery point already contains the exact file you need.
D
Use Azure Monitor alerts to trigger an automatic file restore.
Why wrong: Azure Monitor alerts are designed to notify on conditions such as resource health or metric thresholds; they have no native built-in action to execute an Azure Backup file recovery. While an action group could theoretically trigger an automation runbook that calls Backup REST APIs, that is custom engineering, not a supported out-of-box recovery mechanism. The intended and supported path to retrieve a single file is to use Azure Backup's 'File Recovery' option from an available recovery point.

Question 7mediummultiple choice

A user deleted one Excel file from a Windows Server VM that is protected by Azure Backup. The VM must keep running, and the administrator must restore only that file as quickly as possible. What should the administrator do?

Trap 1: Restore the entire virtual machine from the most recent recovery…

Restoring the entire virtual machine from the most recent recovery point is a heavy-handed approach that would require redeploying the VM and likely deallocating it, causing downtime and potentially overwriting newer changes made on the production VM. This method treats the incident as a full VM failure rather than a single deleted file, and it could roll back the OS, applications, and other data to an older state. Azure Backup's File Recovery feature is explicitly designed to avoid this disruption by mounting only the needed recovery point and allowing selective file copy, so a full VM restore is unnecessarily destructive and slower.

Trap 2: Fail over the VM by using Azure Site Recovery and then copy the…

Azure Site Recovery (ASR) is a disaster recovery service that replicates entire virtual machines to a secondary region for business continuity during regional outages, not for routine file-level recovery. Failing over would switch production traffic to the replica, change the VM's identity/IP addressing, and require a failback afterward—severe disruption for an otherwise healthy VM. ASR does not provide a granular browse-and-restore interface for individual files from backup recovery points; that capability belongs to Azure Backup, making ASR both architecturally and operationally wrong for this scenario.

Trap 3: Create a snapshot of the VM disk and restore the spreadsheet from…

Creating a VM disk snapshot captures the entire disk at a point in time, but snapshots are not integrated with Azure Backup recovery points and do not offer file-level restore. To retrieve the file, you would have to manually create a managed disk from the snapshot, attach it to another VM, mount the filesystem, and then locate and copy the file—a complex, time-consuming process. Additionally, a snapshot alone does not guarantee application-consistent state unless you specifically coordinate it with the application, and it does not leverage the Recovery Services vault's granular restore capabilities.

A
Restore the entire virtual machine from the most recent recovery point.
Why wrong: Restoring the entire virtual machine from the most recent recovery point is a heavy-handed approach that would require redeploying the VM and likely deallocating it, causing downtime and potentially overwriting newer changes made on the production VM. This method treats the incident as a full VM failure rather than a single deleted file, and it could roll back the OS, applications, and other data to an older state. Azure Backup's File Recovery feature is explicitly designed to avoid this disruption by mounting only the needed recovery point and allowing selective file copy, so a full VM restore is unnecessarily destructive and slower.
B
Use File Recovery from the Recovery Services vault, mount the recovery point, and copy back the deleted file.
File Recovery is designed for this exact scenario. It mounts a backup recovery point so the administrator can browse the contents and copy back only the missing file, while the production VM continues running without a full restore.
C
Fail over the VM by using Azure Site Recovery and then copy the file from the replica.
Why wrong: Azure Site Recovery (ASR) is a disaster recovery service that replicates entire virtual machines to a secondary region for business continuity during regional outages, not for routine file-level recovery. Failing over would switch production traffic to the replica, change the VM's identity/IP addressing, and require a failback afterward—severe disruption for an otherwise healthy VM. ASR does not provide a granular browse-and-restore interface for individual files from backup recovery points; that capability belongs to Azure Backup, making ASR both architecturally and operationally wrong for this scenario.
D
Create a snapshot of the VM disk and restore the spreadsheet from the snapshot.
Why wrong: Creating a VM disk snapshot captures the entire disk at a point in time, but snapshots are not integrated with Azure Backup recovery points and do not offer file-level restore. To retrieve the file, you would have to manually create a managed disk from the snapshot, attach it to another VM, mount the filesystem, and then locate and copy the file—a complex, time-consuming process. Additionally, a snapshot alone does not guarantee application-consistent state unless you specifically coordinate it with the application, and it does not leverage the Recovery Services vault's granular restore capabilities.

Question 8hardmatching

A VM backup policy is being designed in a Recovery Services vault. Match each backup policy element to the behavior it controls.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Defines when the backup job starts, such as daily at a specific time.

Defines how long recovery points remain available for restore.

Determines how the scheduled backup time is interpreted in the policy.

Keeps snapshot copies available for fast local restores before the vault copy completes.

Reusable object that combines schedule, retention, and related backup settings.

Trap 1: Retention Range: Controls the time zone for backup scheduling.

Retention Range is entirely concerned with how long recovery points and snapshots are retained, expressed as a time span measured in days, weeks, months, or years. The time zone used by the backup schedule is a separate, independent setting configured alongside the backup schedule's start time, and it does not influence retention. Thus, conflating time zone with retention range is inaccurate because these are two unrelated policy attributes.

Trap 2: Backup Schedule: Defines how many backups are retained.

Backup Schedule only defines the frequency and the time of day when backup jobs are executed; it does not determine the number of backups retained in the vault. The quantity of kept backups is instead dictated by the retention range in combination with the schedule's frequency—for example, a daily schedule with a 30-day retention yields at most 30 recovery points. So saying the backup schedule defines how many backups are retained confuses the trigger mechanism with the expiration policy.

A
Retention Range: Defines how long backup snapshots and recovery points are kept.
Retention Range is the policy element that establishes the lifecycle of every backup copy, defining the duration—from days to years—that daily, weekly, monthly, or yearly recovery points remain available before they expire and are purged from the Recovery Services vault. This duration directly determines how far back in time you can restore a VM, making it the core control for backup durability. It is a time-based measure, not a count.
B
Backup Schedule: Specifies the time and day when backups are created.
Backup Schedule specifies the exact frequency—typically once or twice per day—and the precise time (along with the time zone) at which Azure triggers a backup job for the protected VM, creating a consistent recovery point at that moment. This setting controls the point-in-time granularity of recoverability, such as a nightly 2:00 AM snapshot. It does not determine how long those points are kept; that responsibility belongs to the retention range.
C
Snapshot Retention: Controls the number of instant restore snapshots retained.
Snapshot Retention is a distinct setting in Azure VM backup that limits how many instant restore snapshots—taken immediately at backup time and stored locally in the VM's resource group—are kept. The default is two snapshots, and you can configure between one and five; these snapshots permit rapid file or VM restore from the local snapshot without waiting for data to be copied from the vault. This is separate from vault-based retention, which governs recovery points in the backup storage.
D
Policy Type: Determines whether the policy is Standard or Enhanced.
Policy Type refers to the two available backup policy models for Azure VMs: Standard and Enhanced. The Standard policy only supports the default daily backup and vault-based recovery points up to 30 days, while the Enhanced policy enables multiple backups per day, hourly frequency, and session-level consistency across a VM's disks for faster and more granular recovery. Choosing the correct policy type is a prerequisite because some retention and snapshot options are only available with Enhanced.
E
Retention Range: Controls the time zone for backup scheduling.
Why wrong: Retention Range is entirely concerned with how long recovery points and snapshots are retained, expressed as a time span measured in days, weeks, months, or years. The time zone used by the backup schedule is a separate, independent setting configured alongside the backup schedule's start time, and it does not influence retention. Thus, conflating time zone with retention range is inaccurate because these are two unrelated policy attributes.
F
Backup Schedule: Defines how many backups are retained.
Why wrong: Backup Schedule only defines the frequency and the time of day when backup jobs are executed; it does not determine the number of backups retained in the vault. The quantity of kept backups is instead dictated by the retention range in combination with the schedule's frequency—for example, a daily schedule with a 30-day retention yields at most 30 recovery points. So saying the backup schedule defines how many backups are retained confuses the trigger mechanism with the expiration policy.

Question 9mediummultiple choice

An administrator archived monthly log exports in a blob container six weeks ago. An auditor now needs to open one of those files later today, and the file must be readable from Azure Storage rather than restored from a separate backup copy. What should the administrator do?

Trap 1: Open the blob directly from the Archive tier because archived blobs…

Archive tier is an offline storage class, meaning the blob bytes are not accessible by standard read operations; any HTTP GET or download request on an archived blob fails because the data is not online. To read it, the administrator must first issue a Set Blob Tier call to an online tier (Hot, Cool, or Cold) and wait for the rehydration to complete. Simply knowing the blob's URL or possessing a SAS token does not make the offline data readable.

Trap 2: Change the blob to the Cold tier, because Cold is designed for…

Changing the access tier from Archive to Cold does initiate a rehydration process, but it is not an immediate fix; the tier change is asynchronous and, without a High-priority rehydration request, can take up to 15 hours to become readable. Cold is an online tier meant for infrequently accessed data that is still immediately readable, not a status that simply 'unlocks' archived content. Because the administrator must open the file later the same day, Hot tier with High-priority rehydration is the only option that meets that timing.

Trap 3: Use a snapshot of the archived blob, because snapshots can be…

A snapshot references the same underlying block blobs as the base blob, so it cannot be read independently once the base data resides in Archive. Taking a snapshot before the audit does not copy data to an online tier; if the base blob is archived, the snapshot's content is also offline and still requires rehydration to become readable. The snapshot is useful for versioning or point-in-time restoration, but it is not an access shortcut around the Archive tier.

A
Open the blob directly from the Archive tier because archived blobs remain online for read access.
Why wrong: Archive tier is an offline storage class, meaning the blob bytes are not accessible by standard read operations; any HTTP GET or download request on an archived blob fails because the data is not online. To read it, the administrator must first issue a Set Blob Tier call to an online tier (Hot, Cool, or Cold) and wait for the rehydration to complete. Simply knowing the blob's URL or possessing a SAS token does not make the offline data readable.
B
Start rehydration of the blob to the Hot tier before opening it.
Archived blobs are not immediately readable, so the administrator must rehydrate the blob back to an online tier first. Hot is appropriate when the file needs to be accessible again as soon as the rehydration completes and may be used actively during the audit. This is the correct operational response when the blob must be read later the same day.
C
Change the blob to the Cold tier, because Cold is designed for archived content.
Why wrong: Changing the access tier from Archive to Cold does initiate a rehydration process, but it is not an immediate fix; the tier change is asynchronous and, without a High-priority rehydration request, can take up to 15 hours to become readable. Cold is an online tier meant for infrequently accessed data that is still immediately readable, not a status that simply 'unlocks' archived content. Because the administrator must open the file later the same day, Hot tier with High-priority rehydration is the only option that meets that timing.
D
Use a snapshot of the archived blob, because snapshots can be opened even when the base blob is archived.
Why wrong: A snapshot references the same underlying block blobs as the base blob, so it cannot be read independently once the base data resides in Archive. Taking a snapshot before the audit does not copy data to an online tier; if the base blob is archived, the snapshot's content is also offline and still requires rehydration to become readable. The snapshot is useful for versioning or point-in-time restoration, but it is not an access shortcut around the Archive tier.

Question 10easymultiple choice

Based on the exhibit, what should the administrator change if the business wants backups to be kept for 30 days instead of 7 days?

Exhibit

Azure Backup policy
- Schedule: Daily at 01:00
- Retain instant recovery snapshots: 2 days
- Retain daily backup points: 7 days
- Retain weekly backup points: Not configured
Business requirement: Keep daily backups for 30 days

Trap 1: Change the backup schedule from daily to hourly.

Changing the backup schedule from daily to hourly only increases the frequency at which recovery points are created; it does not alter how long those recovery points are retained. The retention setting still specifies that each daily (or hourly) recovery point is kept for only 7 days, so all created points, regardless of frequency, will expire after that period. This would increase storage costs and management overhead without satisfying the 30-day retention requirement.

Trap 2: Increase the instant recovery snapshot retention to 30 days.

Instant recovery snapshots are temporary, locally stored snapshots used for fast disk-level restores immediately after a backup. They are retained for a short period (typically up to 7 days) and are not the same as long-term backup recovery points stored in the Recovery Services vault. Increasing their retention to 30 days may extend the quick-restore window but would not change how long the daily recovery points themselves are kept, so the requirement for 30-day retention remains unmet.

Trap 3: Enable a CanNotDelete lock on the Recovery Services vault.

A CanNotDelete lock on the Recovery Services vault prevents the vault itself from being deleted or modified by users or automated processes, but it has no effect on the Azure Backup retention policy. Restore points inside the vault still expire according to the current scheduled retention (7 days), and a lock does not preserve or extend them. This control is designed for resource protection against accidental or malicious deletion, not for compliance-driven data retention.

A
Change the backup schedule from daily to hourly.
Why wrong: Changing the backup schedule from daily to hourly only increases the frequency at which recovery points are created; it does not alter how long those recovery points are retained. The retention setting still specifies that each daily (or hourly) recovery point is kept for only 7 days, so all created points, regardless of frequency, will expire after that period. This would increase storage costs and management overhead without satisfying the 30-day retention requirement.
B
Increase the retain daily backup points setting to 30 days.
The requirement is about how long daily recovery points are kept, not how often backups run. The policy setting that controls that is the retention value for daily backup points. Updating it from 7 days to 30 days keeps the restore points available for the required period while leaving the backup schedule unchanged.
C
Increase the instant recovery snapshot retention to 30 days.
Why wrong: Instant recovery snapshots are temporary, locally stored snapshots used for fast disk-level restores immediately after a backup. They are retained for a short period (typically up to 7 days) and are not the same as long-term backup recovery points stored in the Recovery Services vault. Increasing their retention to 30 days may extend the quick-restore window but would not change how long the daily recovery points themselves are kept, so the requirement for 30-day retention remains unmet.
D
Enable a CanNotDelete lock on the Recovery Services vault.
Why wrong: A CanNotDelete lock on the Recovery Services vault prevents the vault itself from being deleted or modified by users or automated processes, but it has no effect on the Azure Backup retention policy. Restore points inside the vault still expire according to the current scheduled retention (7 days), and a lock does not preserve or extend them. This control is designed for resource protection against accidental or malicious deletion, not for compliance-driven data retention.

Question 11easymultiple choice

A line-of-business app must keep serving users if an entire Azure region becomes unavailable. Is Azure Backup by itself enough to meet this requirement?

Trap 1: Yes, because backup alone guarantees immediate failover to another…

Backup creates historical copies of VM disks, but it does not replicate the running state or maintain a booted instance elsewhere. Geo-redundant storage (GRS) may protect the backup data itself, but that data is not an active VM ready to receive traffic. Immediate failover requires continuous replication of the virtual machine to a secondary region—exactly what Azure Site Recovery provides—not merely having a backup artifact in another location.

Trap 2: Yes, as long as the VM has a backup policy

A backup policy simply defines how frequently snapshots are taken and how long they are retained in a Recovery Services vault. It does not provision any compute or maintain a standby replica in another region. Even with an aggressive backup schedule, restoring a VM requires manual steps such as picking a recovery point, deploying a new VM, and reconfiguring network settings, so workloads remain unavailable during a region-wide outage.

Trap 3: Yes, if diagnostic settings are enabled on the VM

Diagnostic settings route VM metrics and logs to Azure Monitor, Storage, or Event Hubs for observability and troubleshooting. They might help you detect an outage, but they do not create a secondary VM, replicate disks, or alter the region in which the VM runs. Monitoring is one component of an incident response plan, not a substitute for disaster recovery replication, so enabling diagnostics has no effect on keeping the application serving users during a regional disaster.

A
Yes, because backup alone guarantees immediate failover to another region
Why wrong: Backup creates historical copies of VM disks, but it does not replicate the running state or maintain a booted instance elsewhere. Geo-redundant storage (GRS) may protect the backup data itself, but that data is not an active VM ready to receive traffic. Immediate failover requires continuous replication of the virtual machine to a secondary region—exactly what Azure Site Recovery provides—not merely having a backup artifact in another location.
B
No, you also need disaster recovery replication such as Azure Site Recovery
Azure Backup is designed for point-in-time data recovery, not continuous uptime. During a region-wide outage, even a geo-redundant backup vault contains only backup data, not a running VM with the application loaded. Azure Site Recovery replicates the VM's disks to a secondary region and enables orchestrated failover, which is what actually keeps the app online in a disaster.
C
Yes, as long as the VM has a backup policy
Why wrong: A backup policy simply defines how frequently snapshots are taken and how long they are retained in a Recovery Services vault. It does not provision any compute or maintain a standby replica in another region. Even with an aggressive backup schedule, restoring a VM requires manual steps such as picking a recovery point, deploying a new VM, and reconfiguring network settings, so workloads remain unavailable during a region-wide outage.
D
Yes, if diagnostic settings are enabled on the VM
Why wrong: Diagnostic settings route VM metrics and logs to Azure Monitor, Storage, or Event Hubs for observability and troubleshooting. They might help you detect an outage, but they do not create a secondary VM, replicate disks, or alter the region in which the VM runs. Monitoring is one component of an incident response plan, not a substitute for disaster recovery replication, so enabling diagnostics has no effect on keeping the application serving users during a regional disaster.

Question 12easymultiple choice

Before changing a managed data disk on a production VM, you want a point-in-time copy that you can keep and restore later if needed. What should you create?

Trap 1: An availability set

An availability set is a logical grouping of virtual machines that ensures they are placed across different fault domains and update domains, protecting the workload from hardware failures and planned maintenance. Its purpose is to maintain service uptime and meet the Azure SLA, not to capture or preserve disk state. No copy of the data disk is created, so an availability set offers no mechanism for reverting to a previous disk configuration after a change.

Trap 2: A load balancer backend pool

A load balancer backend pool is a network-layer configuration that contains the VM IP addresses on which the load balancer forwards incoming traffic. It is used solely for distributing traffic and enabling resilience for network services; it has no visibility into disk contents, file systems, or storage operations. Adding a VM to a backend pool does not generate any disk image or snapshot, and therefore cannot be used to restore a managed data disk after an unwanted change.

Trap 3: A resource lock

A resource lock, such as a CanNotDelete or ReadOnly lock, is an Azure Resource Manager (ARM) management-plane control that prevents accidental deletion or modification of the VM or its resources. However, a lock does not intercept or copy any bits from the managed disk; it only enforces access restrictions on the resource itself. Consequently, it cannot provide a point-in-time disk image or rollback point for data that will be changed on the data disk.

A
A managed disk snapshot
A snapshot captures a point-in-time copy of a managed disk. It is the right choice when you want a recoverable copy before making changes. You can create it for an OS disk or data disk and use it later to restore or create a new disk if the original change does not work as expected.
B
An availability set
Why wrong: An availability set is a logical grouping of virtual machines that ensures they are placed across different fault domains and update domains, protecting the workload from hardware failures and planned maintenance. Its purpose is to maintain service uptime and meet the Azure SLA, not to capture or preserve disk state. No copy of the data disk is created, so an availability set offers no mechanism for reverting to a previous disk configuration after a change.
C
A load balancer backend pool
Why wrong: A load balancer backend pool is a network-layer configuration that contains the VM IP addresses on which the load balancer forwards incoming traffic. It is used solely for distributing traffic and enabling resilience for network services; it has no visibility into disk contents, file systems, or storage operations. Adding a VM to a backend pool does not generate any disk image or snapshot, and therefore cannot be used to restore a managed data disk after an unwanted change.
D
A resource lock
Why wrong: A resource lock, such as a CanNotDelete or ReadOnly lock, is an Azure Resource Manager (ARM) management-plane control that prevents accidental deletion or modification of the VM or its resources. However, a lock does not intercept or copy any bits from the managed disk; it only enforces access restrictions on the resource itself. Consequently, it cannot provide a point-in-time disk image or rollback point for data that will be changed on the data disk.

Question 13easymulti select

An administrator enabled Azure VM backup yesterday and now wants to confirm whether the most recent backup job succeeded. Which two places can they check? Select two.

Trap 1: Activity log

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.

Trap 2: Azure Advisor

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.

Trap 3: Resource Graph

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
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.
B
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.
C
Recovery Services vault backup jobs
The Recovery Services vault's 'Backup Jobs' blade displays the complete history of backup and restore operations for Azure VMs protected by that vault, including their status (completed, failed, in progress) and detailed error messages if a job failed. When an administrator needs a definitive, per-vault list of job success or failure for a specific backup policy, this is the canonical location to check. It also allows filtering by time range, operation type, and status to isolate yesterday's job.
D
Backup center
Backup center is the Azure portal's unified management plane that aggregates backup health, inventory, and job status across multiple Recovery Services vaults, subscriptions, and regions. It provides a dashboard view of recent backup jobs with status, so an administrator can see VM backup success or failure without navigating into individual vaults. This is especially useful for reporting on a fleet of VMs, but it does not retain the full historical job log that a vault's Backup Jobs pane does; both are valid for confirming yesterday's backup result.
E
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.

Question 14mediummultiple choice

An employee deleted one spreadsheet stored on a Windows VM that is protected by Azure Backup. The administrator must recover only that file without restoring the entire VM. What should be used?

Trap 1: A full VM restore to replace the existing virtual machine.

Performing a full VM restore from a Recovery Services vault recovery point would replace the entire operating system and data disks, reverting every file change made after that backup and likely causing an outage or requiring VM recreation. For a single spreadsheet deletion, this is disproportionately invasive and risks overwriting unrelated current data, whereas file-level recovery mounts the same recovery point and lets you copy exactly the deleted file without touching the running VM. Azure Backup explicitly provides file-level recovery to avoid the downtime and data loss inherent in full VM restores.

Trap 2: Blob rehydration from Archive tier in the storage account.

Blob rehydration from the Archive tier is a storage-level operation that changes the access tier of a block blob, not a mechanism to recover deleted files from a VM's disk. A Windows VM's disk is stored as a page blob, which is not eligible for Archive tier rehydration, and even if the underlying blob were accessible, rehydration would not expose the file system hierarchy or resurrect a deleted spreadsheet. This option confuses Azure Storage blob lifecycle management with Azure Backup's mount-and-copy file recovery, which operates on recovery points, not on storage access tiers.

Trap 3: A restore point collection operation in Azure Compute.

Restore point collections in Azure Compute are API-level snapshot groups that capture application-consistent VM state, primarily for custom automation or dev/test scenarios. They do not integrate with the Recovery Services vault's backup chain, and Azure provides no built-in process to mount a restore point collection as a file share to copy out a single deleted spreadsheet. Azure Backup's file recovery, by contrast, creates a temporary mount of a backup recovery point, which is the only supported Azure-native method to recover individual files from a backed-up VM.

A
A full VM restore to replace the existing virtual machine.
Why wrong: Performing a full VM restore from a Recovery Services vault recovery point would replace the entire operating system and data disks, reverting every file change made after that backup and likely causing an outage or requiring VM recreation. For a single spreadsheet deletion, this is disproportionately invasive and risks overwriting unrelated current data, whereas file-level recovery mounts the same recovery point and lets you copy exactly the deleted file without touching the running VM. Azure Backup explicitly provides file-level recovery to avoid the downtime and data loss inherent in full VM restores.
B
The file recovery process from the Recovery Services vault recovery point.
Azure Backup supports file-level recovery by mounting a selected recovery point and allowing the administrator to copy out individual files or folders. This is the best option when the goal is to restore one deleted spreadsheet without replacing the entire virtual machine. It minimizes disruption and avoids overwriting other current VM data that was not affected.
C
Blob rehydration from Archive tier in the storage account.
Why wrong: Blob rehydration from the Archive tier is a storage-level operation that changes the access tier of a block blob, not a mechanism to recover deleted files from a VM's disk. A Windows VM's disk is stored as a page blob, which is not eligible for Archive tier rehydration, and even if the underlying blob were accessible, rehydration would not expose the file system hierarchy or resurrect a deleted spreadsheet. This option confuses Azure Storage blob lifecycle management with Azure Backup's mount-and-copy file recovery, which operates on recovery points, not on storage access tiers.
D
A restore point collection operation in Azure Compute.
Why wrong: Restore point collections in Azure Compute are API-level snapshot groups that capture application-consistent VM state, primarily for custom automation or dev/test scenarios. They do not integrate with the Recovery Services vault's backup chain, and Azure provides no built-in process to mount a restore point collection as a file share to copy out a single deleted spreadsheet. Azure Backup's file recovery, by contrast, creates a temporary mount of a backup recovery point, which is the only supported Azure-native method to recover individual files from a backed-up VM.

Question 15mediummultiple choice

Based on the exhibit, the VM backup item was accidentally deleted from the vault yesterday, but the VM itself still exists. What should you do to resume protection with the existing backup item?

Exhibit

Recovery Services vault: rsv-prod
Backup Items > Azure Virtual Machine
Item: vm-app01
Protection status: Protection stopped
Deletion status: Deleted
Soft Delete: Enabled
Retention window remaining: 13 days

Trap 1: Delete the VM and recreate it so the backup can start again.

Deleting and recreating the Azure VM does not remove the backup item from the Recovery Services vault, because the backup item is a separate metadata entity that persists in a soft-deleted state. A newly created VM has a new resource identity and requires a fresh backup configuration, which forces an initial backup and abandons all existing recovery points. The correct path is to undelete the existing backup item from the vault, preserving the original protection chain and recovery points without rebuilding the workload.

Trap 2: Create a new action group so the vault can re-enable protection.

Action groups are Azure Monitor constructs that define notification or automation responses to alerts, such as sending email, SMS, or firing a webhook; they do not influence the state of backup items in a vault. Azure Backup protection is tied to a backup policy and the item's health state, not to action group membership, so creating a new action group cannot re-enable protection after a deletion. Only the soft-delete recovery operation at the vault level can restore the backup relationship for a deleted item.

Trap 3: Disable diagnostic settings on the vault and then re-enable them.

Diagnostic settings in a Recovery Services vault route monitoring telemetry such as job status and health events to Log Analytics or Storage; they are not part of the Azure Backup control plane that manages protected items. Deleting a backup item creates a soft-deleted record with its own lifecycle, and toggling diagnostic settings only affects whether log data is streamed. This action neither reverts the deletion nor restores the backup item, so it has no effect on recoverability.

A
Delete the VM and recreate it so the backup can start again.
Why wrong: Deleting and recreating the Azure VM does not remove the backup item from the Recovery Services vault, because the backup item is a separate metadata entity that persists in a soft-deleted state. A newly created VM has a new resource identity and requires a fresh backup configuration, which forces an initial backup and abandons all existing recovery points. The correct path is to undelete the existing backup item from the vault, preserving the original protection chain and recovery points without rebuilding the workload.
B
Recover or undelete the backup item from the vault before the soft-delete retention expires.
Because soft delete is enabled and the retention window is still open, the deleted backup item can be recovered from the Recovery Services vault. Undeleting the item restores the backup relationship without requiring a new protection configuration or a rebuild of the VM.
C
Create a new action group so the vault can re-enable protection.
Why wrong: Action groups are Azure Monitor constructs that define notification or automation responses to alerts, such as sending email, SMS, or firing a webhook; they do not influence the state of backup items in a vault. Azure Backup protection is tied to a backup policy and the item's health state, not to action group membership, so creating a new action group cannot re-enable protection after a deletion. Only the soft-delete recovery operation at the vault level can restore the backup relationship for a deleted item.
D
Disable diagnostic settings on the vault and then re-enable them.
Why wrong: Diagnostic settings in a Recovery Services vault route monitoring telemetry such as job status and health events to Log Analytics or Storage; they are not part of the Azure Backup control plane that manages protected items. Deleting a backup item creates a soft-deleted record with its own lifecycle, and toggling diagnostic settings only affects whether log data is streamed. This action neither reverts the deletion nor restores the backup item, so it has no effect on recoverability.

Question 16mediummultiple choice

An admin enables backup on a newly deployed Azure VM, but every backup job fails immediately with a message that the VM agent is not ready. What should the administrator verify first?

Trap 1: The VM is placed in an availability zone that supports backup.

Azure Backup is a regional service and operates uniformly across all availability zones within a supported Azure region; no zone-specific limitation prevents backup extension provisioning or recovery point creation. Availability zone placement defines the physical fault and update domain isolation of the VM's underlying hardware, which is unrelated to the health of the guest-level Azure VM Agent. The reported error is about agent readiness, and the first troubleshooting step should be checking the VM agent status inside the guest OS, not confirming zone support. Thus, checking the availability zone would be a misdirected and ineffective action.

Trap 2: The VM has a public IP address assigned for outbound connectivity.

Azure Backup does not require the VM to have a public IP address assigned. The Azure VM Agent and backup extensions communicate outbound to Azure public endpoints, and this outbound connectivity can be provided through default outbound access, a NAT gateway, or forced tunneling, making a public IP only one possible—not mandatory—method. The error in the scenario specifically references the VM agent's operational state inside the guest OS, not the VM's lack of internet egress. Adding or removing a public IP would not repair an agent that is stopped, uninstalled, or unhealthy.

Trap 3: The VM is added to a load balancer backend pool.

Adding a VM to a load balancer backend pool is a networking configuration that determines how inbound traffic is distributed to the VM's IP address. This has no interaction with the Azure VM Agent or the provisioning of backup extensions, which are guest-level components managed by the Azure fabric. The backup extension is installed via the VM agent using outbound HTTPS to Azure control plane endpoints, and this traffic path is independent of load balancer membership. Therefore, membership in a backend pool would not cause or resolve a 'VM agent not ready' backup error.

A
The VM is placed in an availability zone that supports backup.
Why wrong: Azure Backup is a regional service and operates uniformly across all availability zones within a supported Azure region; no zone-specific limitation prevents backup extension provisioning or recovery point creation. Availability zone placement defines the physical fault and update domain isolation of the VM's underlying hardware, which is unrelated to the health of the guest-level Azure VM Agent. The reported error is about agent readiness, and the first troubleshooting step should be checking the VM agent status inside the guest OS, not confirming zone support. Thus, checking the availability zone would be a misdirected and ineffective action.
B
The Azure VM Agent is installed, running, and able to provision backup-related extensions.
Azure Backup relies on the VM agent and extensions inside the guest. If the agent is missing, stopped, or unhealthy, backup jobs can fail before a recovery point is created. Verifying the agent first addresses the specific error message.
C
The VM has a public IP address assigned for outbound connectivity.
Why wrong: Azure Backup does not require the VM to have a public IP address assigned. The Azure VM Agent and backup extensions communicate outbound to Azure public endpoints, and this outbound connectivity can be provided through default outbound access, a NAT gateway, or forced tunneling, making a public IP only one possible—not mandatory—method. The error in the scenario specifically references the VM agent's operational state inside the guest OS, not the VM's lack of internet egress. Adding or removing a public IP would not repair an agent that is stopped, uninstalled, or unhealthy.
D
The VM is added to a load balancer backend pool.
Why wrong: Adding a VM to a load balancer backend pool is a networking configuration that determines how inbound traffic is distributed to the VM's IP address. This has no interaction with the Azure VM Agent or the provisioning of backup extensions, which are guest-level components managed by the Azure fabric. The backup extension is installed via the VM agent using outbound HTTPS to Azure control plane endpoints, and this traffic path is independent of load balancer membership. Therefore, membership in a backend pool would not cause or resolve a 'VM agent not ready' backup error.

Question 17hardmultiple choice

An Azure VM backup job starts failing immediately after protection is enabled. The error states that the VM agent is not ready. The VM was created from a custom image and no extensions have ever installed successfully. What should the administrator verify first?

Trap 1: That the Recovery Services vault is in the same resource group as…

The physical location of the Recovery Services vault relative to the VM (or its resource group) does not influence the guest-agent readiness check that gates backup execution. While vault and VM often share a resource group for management convenience, the backup extension communicates with the VM Agent directly, regardless of resource group placement. A network or region mismatch might affect data transfer, but a resource-group mismatch is not a technical constraint in Azure Backup. So this setting would never be the first suspect for an immediate failure.

Trap 2: That soft delete is enabled on the vault.

Enabling soft delete on a Recovery Services vault protects against accidental deletion of backup data, but it has no role in the execution of new backup jobs. Soft delete only activates when a backup item or vault is deleted, retaining data for 14 days. An immediate backup failure is typically a pre-flight validation error, such as an unhealthy VM Agent, not a retention or deletion policy. Therefore, soft-delete status would not cause a new backup job to start failing.

Trap 3: That the subscription has enough free Azure Backup storage capacity.

Azure Backup storage is elastic and metered per use; there is no pre-allocated capacity that must be free before a backup job can run. The subscription's storage quota applies to Managed Disks or other storage resources, not to the backup vault's internal storage. An immediate job failure caused by a quota issue would normally show a billing or quota error, not a guest-agent readiness error. Thus, checking free capacity is a red herring when the VM Agent is the actual problem.

A
That the Recovery Services vault is in the same resource group as the VM.
Why wrong: The physical location of the Recovery Services vault relative to the VM (or its resource group) does not influence the guest-agent readiness check that gates backup execution. While vault and VM often share a resource group for management convenience, the backup extension communicates with the VM Agent directly, regardless of resource group placement. A network or region mismatch might affect data transfer, but a resource-group mismatch is not a technical constraint in Azure Backup. So this setting would never be the first suspect for an immediate failure.
B
That the Azure VM Agent service is installed and running inside the guest OS.
Azure VM Backup depends on the VM guest agent to coordinate extensions and backup integration. If the agent is missing, stopped, or unhealthy, backup jobs can fail immediately with a readiness message. Verifying the agent state is the correct first troubleshooting step before looking at policy, retention, or vault configuration.
C
That soft delete is enabled on the vault.
Why wrong: Enabling soft delete on a Recovery Services vault protects against accidental deletion of backup data, but it has no role in the execution of new backup jobs. Soft delete only activates when a backup item or vault is deleted, retaining data for 14 days. An immediate backup failure is typically a pre-flight validation error, such as an unhealthy VM Agent, not a retention or deletion policy. Therefore, soft-delete status would not cause a new backup job to start failing.
D
That the subscription has enough free Azure Backup storage capacity.
Why wrong: Azure Backup storage is elastic and metered per use; there is no pre-allocated capacity that must be free before a backup job can run. The subscription's storage quota applies to Managed Disks or other storage resources, not to the backup vault's internal storage. An immediate job failure caused by a quota issue would normally show a billing or quota error, not a guest-agent readiness error. Thus, checking free capacity is a red herring when the VM Agent is the actual problem.

Question 18mediummultiple choice

A developer deleted a single configuration file on a Windows Azure VM. The administrator wants to restore only that file from the latest backup without replacing the entire VM. Which restore workflow should be used?

Trap 1: Restore the entire VM to a new instance

A full VM restore to a new instance creates an entirely new virtual machine from the selected recovery point, including its complete OS and data disks. This is far more scope than the single deleted configuration file requires, and it forces you to reconfigure the environment, potentially changing the VM name, IP address, and attached resources. Azure Backup's file recovery feature mounts only the needed disk or folder from a recovery point, letting you copy the deleted file back with no new VM provisioning or network impact.

Trap 2: Create a new storage account and copy the file from there

Creating a new storage account provisions an Azure Storage resource for blobs, files, queues, or tables, none of which are mounted as the guest OS disk of the VM. Unless the deleted configuration file was originally copied to Azure Files or Blob Storage, a new storage account will not contain the file, and it cannot access the data stored inside the VM backup. The correct recovery path is to mount the backup's virtual hard disk through Azure Backup item-level recovery and copy the file directly from that VHD, not to create unrelated storage.

Trap 3: Enable a resource lock on the VM

A resource lock on the VM operates at the Azure Resource Manager control plane, preventing accidental deletion or modification of the VM resource itself; it has no effect on the file system inside the guest OS. Deleting a file through Windows Explorer or a process running in the VM is a data-plane operation that a lock does not intercept. Therefore, enabling a lock is a valid preventative measure for future deletions, but it cannot retrieve a file that was already removed from the VM's disk.

A
Restore the entire VM to a new instance
Why wrong: A full VM restore to a new instance creates an entirely new virtual machine from the selected recovery point, including its complete OS and data disks. This is far more scope than the single deleted configuration file requires, and it forces you to reconfigure the environment, potentially changing the VM name, IP address, and attached resources. Azure Backup's file recovery feature mounts only the needed disk or folder from a recovery point, letting you copy the deleted file back with no new VM provisioning or network impact.
B
Use file recovery from the backup item
File recovery lets an administrator mount the backup content and copy back only the deleted file or folder. That is the most efficient option when the VM itself is healthy and only a small set of files needs to be recovered. It avoids downtime and avoids replacing the whole virtual machine or disk set.
C
Create a new storage account and copy the file from there
Why wrong: Creating a new storage account provisions an Azure Storage resource for blobs, files, queues, or tables, none of which are mounted as the guest OS disk of the VM. Unless the deleted configuration file was originally copied to Azure Files or Blob Storage, a new storage account will not contain the file, and it cannot access the data stored inside the VM backup. The correct recovery path is to mount the backup's virtual hard disk through Azure Backup item-level recovery and copy the file directly from that VHD, not to create unrelated storage.
D
Enable a resource lock on the VM
Why wrong: A resource lock on the VM operates at the Azure Resource Manager control plane, preventing accidental deletion or modification of the VM resource itself; it has no effect on the file system inside the guest OS. Deleting a file through Windows Explorer or a process running in the VM is a data-plane operation that a lock does not intercept. Therefore, enabling a lock is a valid preventative measure for future deletions, but it cannot retrieve a file that was already removed from the VM's disk.

Question 19mediummultiple choice

Backup protection was enabled on a new Azure VM, but every backup job fails immediately with a message indicating the guest agent is not ready. What should the administrator verify first?

Trap 1: That the recovery vault uses GZRS storage redundancy.

The Recovery Services vault's GZRS (Geo-Zone-Redundant Storage) setting governs how backup copies are replicated across zones and regions for durability, but it has no effect on the live interaction between the Azure Backup service and the VM agent inside the protected VM. Misconfiguring redundancy may impact storage resilience, yet it would never produce a 'guest agent is not ready' error. The correct fix is to check and repair the agent itself.

Trap 2: That the VM has a private endpoint to the Recovery Services vault.

A private endpoint provides a private network path to the Recovery Services vault, but Azure VM Backup's snapshot orchestration is handled by the Azure Backup service communicating with the VM agent, not by the VM directly reaching the vault's endpoint. The agent readiness status is reported through the agent's control channel, independent of vault networking. Adding or checking a private endpoint does not address the missing or broken guest agent.

Trap 3: That a resource lock has not been applied to the VM.

A resource lock restricts management-plane operations like deleting or modifying the Azure Resource Manager resource, but it does not influence the guest-agent heartbeat or the execution of the backup extension inside the OS. The backup failure is tied to the agent's state, not the lock policy. Removing a lock would not make the guest agent ready.

A
That the Azure VM agent is installed, running, and up to date inside the guest operating system.
Azure VM Backup depends on the VM agent to coordinate snapshot operations and communicate status back to Azure. If the portal reports that the guest agent is not ready, the first troubleshooting step is to verify that the agent exists, is running, and is current. Fixing the agent often resolves immediate backup failures without changing vault settings, policies, or storage configuration.
B
That the recovery vault uses GZRS storage redundancy.
Why wrong: The Recovery Services vault's GZRS (Geo-Zone-Redundant Storage) setting governs how backup copies are replicated across zones and regions for durability, but it has no effect on the live interaction between the Azure Backup service and the VM agent inside the protected VM. Misconfiguring redundancy may impact storage resilience, yet it would never produce a 'guest agent is not ready' error. The correct fix is to check and repair the agent itself.
C
That the VM has a private endpoint to the Recovery Services vault.
Why wrong: A private endpoint provides a private network path to the Recovery Services vault, but Azure VM Backup's snapshot orchestration is handled by the Azure Backup service communicating with the VM agent, not by the VM directly reaching the vault's endpoint. The agent readiness status is reported through the agent's control channel, independent of vault networking. Adding or checking a private endpoint does not address the missing or broken guest agent.
D
That a resource lock has not been applied to the VM.
Why wrong: A resource lock restricts management-plane operations like deleting or modifying the Azure Resource Manager resource, but it does not influence the guest-agent heartbeat or the execution of the backup extension inside the OS. The backup failure is tied to the agent's state, not the lock policy. Removing a lock would not make the guest agent ready.

Question 20hardmultiple choice

A Windows VM in Azure is protected by Azure Backup. A developer accidentally deleted one application folder, but the VM must keep serving users while the administrator restores only that folder. What should the administrator do?

Trap 1: Restore the entire VM from the latest recovery point into the…

Restoring the entire VM creates a new virtual machine from the recovery point (it does not overwrite the existing one); placing it in the same resource group would cause a resource name conflict unless the original VM is deallocated or deleted, which would interrupt the running workload. That approach also resurrects the full OS and all data disks, potentially losing any changes made since the recovery point, whereas only a single folder is missing. This is far more disruptive and not the intended method for item-level recovery.

Trap 2: Restore the managed disk and attach it to the running VM as a…

Restoring a managed disk creates a new disk from the snapshot; attaching it to the same VM as an additional data disk is not a supported way to recover files because the restored disk contains an entire OS volume, not a readable data partition, and doing so risks disk signature conflicts (especially if the original OS disk remains attached). Even if mounted, you'd need to ensure the OS doesn't boot from it, and there's no straightforward method to access the file system for copying files without additional steps. This is much more invasive than needed.

Trap 3: Create a new Recovery Services vault and re-protect the VM before…

Creating a new Recovery Services vault and re-enabling backup on the VM does not transfer or grant access to the existing recovery points; those remain tied to the current vault, and a new vault would have no recovery points until a new backup completes. This action does not help locate or recover the deleted folder and only introduces redundant configuration effort. The correct approach is to access the existing vault's restore flow and use file-level recovery directly.

A
Restore the entire VM from the latest recovery point into the production resource group.
Why wrong: Restoring the entire VM creates a new virtual machine from the recovery point (it does not overwrite the existing one); placing it in the same resource group would cause a resource name conflict unless the original VM is deallocated or deleted, which would interrupt the running workload. That approach also resurrects the full OS and all data disks, potentially losing any changes made since the recovery point, whereas only a single folder is missing. This is far more disruptive and not the intended method for item-level recovery.
B
Use File Recovery from the appropriate recovery point and copy the folder back.
File Recovery is designed for item-level restore from an Azure VM backup. The administrator can mount the recovery point, browse the backed-up contents, and copy the missing folder back without replacing the whole VM. This is the least disruptive option when the machine must remain online and only a small set of files is needed.
C
Restore the managed disk and attach it to the running VM as a second OS disk.
Why wrong: Restoring a managed disk creates a new disk from the snapshot; attaching it to the same VM as an additional data disk is not a supported way to recover files because the restored disk contains an entire OS volume, not a readable data partition, and doing so risks disk signature conflicts (especially if the original OS disk remains attached). Even if mounted, you'd need to ensure the OS doesn't boot from it, and there's no straightforward method to access the file system for copying files without additional steps. This is much more invasive than needed.
D
Create a new Recovery Services vault and re-protect the VM before restoring anything.
Why wrong: Creating a new Recovery Services vault and re-enabling backup on the VM does not transfer or grant access to the existing recovery points; those remain tied to the current vault, and a new vault would have no recovery points until a new backup completes. This action does not help locate or recover the deleted folder and only introduces redundant configuration effort. The correct approach is to access the existing vault's restore flow and use file-level recovery directly.