Troubleshooting Lab: Create an Azure Backup vault
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator reports that when trying to configure a backup policy for a managed Azure Disk, the Azure portal does not display the newly created vault in the list of available vaults for association. The administrator confirms that the vault exists, is visible in the resource group, and shows no health alerts.
The environment has the following characteristics:
| Attribute | Value |
|---|---|
| Vault type | Recovery Services vault |
| Vault region | Brazil South |
| Azure Disk region | Brazil South |
| Configured redundancy | LRS |
| Resource group | rg-backup-prod |
| Administrator permission | Contributor on the resource group |
The administrator verified their own user permissions and confirmed they have Contributor access to the resource group. The LRS redundancy was chosen by the architecture team's decision to reduce costs, and this configuration was approved. No resource lock policies are active on the resource group.
What is the root cause for the vault not appearing as an available option to protect the Azure Disk?
A) Contributor permission is not sufficient to associate datasources to a vault; the Backup Contributor role is required.
B) The created vault is a Recovery Services vault type, which does not support Azure Disks as datasource; only the Backup vault supports this type of workload.
C) LRS redundancy prevents the association of Azure Disk type datasources, as this type of workload requires at least ZRS.
D) The vault and Azure Disk are in different resource groups, which blocks the association by default.
Scenario 2 — Action Decision
The operations team identified that a production Backup vault has the Soft Delete option disabled. A security analyst opened an urgent ticket requesting immediate enablement of the feature, arguing that without it any accidental deletion of a backup instance becomes permanent and irrecoverable.
The current operational context is as follows:
- The vault currently protects 47 active backup instances of Azure blobs
- There is a backup job running at the moment for 3 of these instances
- Enabling Soft Delete does not require a maintenance window and does not interrupt ongoing jobs
- The security team has an audit deadline in 2 hours and needs to record compliance
- The administrator has Owner permission on the vault
What is the correct action to take at this time?
A) Wait for the completion of the 3 ongoing jobs before enabling Soft Delete, as modifying vault configurations during active jobs may corrupt recovery points.
B) Enable Soft Delete immediately, as the operation does not interrupt ongoing jobs and resolves the vulnerability without operational impact.
C) Create a new Backup vault with Soft Delete enabled and migrate the 47 instances to it before the audit deadline.
D) Open a ticket with Microsoft support to enable Soft Delete remotely, as this configuration cannot be changed after vault creation.
Scenario 3 — Root Cause
An administrator created a Backup vault and successfully configured a backup policy for an Azure Database for PostgreSQL Flexible Server. However, when checking the jobs panel the next day, they observe the following output:
Job Name: BackupJob-pg-flexserver-prod
Datasource: pg-flexserver-prod (PostgreSQL Flexible Server)
Status: Failed
Error Code: UserErrorMissingRequiredPermissions
Error Message: The backup extension does not have the required permissions
to access the datasource. Ensure the vault's managed identity
has been granted the necessary roles on the datasource.
Start Time: 2025-11-14T03:00:00Z
Duration: 00:02:17
Policy Applied: policy-pg-daily
The administrator verifies and confirms that:
- The
policy-pg-dailypolicy is correctly configured with 30 days retention - The PostgreSQL server is running and accessible
- The vault is in the same region as the server
- The server's resource group has a Read-Only type lock applied by another team
- The vault was created with the managed identity option enabled
What is the root cause of the backup job failure?
A) The Read-Only lock on the server's resource group prevents the backup service from accessing the data for reading.
B) The vault's managed identity has not received the necessary roles on the PostgreSQL server resource for the backup service to execute the operation.
C) The policy-pg-daily policy was applied before the vault completed the internal registration process of the datasource, generating a state conflict.
D) The job schedule at 03:00Z coincides with the PostgreSQL Flexible Server's default maintenance window, which temporarily suspends external connections.
Scenario 4 — Diagnostic Sequence
An administrator receives a report that backups of Azure Blobs protected by a Backup vault have stopped running. No explicit error message was logged in the jobs panel, only the NotStarted status for the last 3 consecutive schedules.
The available investigation steps are:
- Step P: Check if the backup policy associated with the datasource is active and if the configured schedule is valid
- Step Q: Confirm if the storage account hosting the blobs is accessible and has not been deleted or moved to another region
- Step R: Check the vault's activity logs to identify if there was any recent configuration change
- Step S: Confirm if the vault is in the expected operational state and if there are no pending health alerts
- Step T: Check if the vault's managed identity still has the necessary permissions on the storage account
What investigation sequence follows the correct progressive diagnostic logic, starting from the most comprehensive to the most specific?
A) S, R, P, T, Q
B) P, T, Q, S, R
C) T, Q, P, R, S
D) Q, P, S, T, R
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The Recovery Services vault and the Backup vault do not support the same types of datasources. Azure Disk is protected exclusively by the Backup vault. When the administrator created a Recovery Services vault, this vault simply does not appear as a valid option in the backup configuration interface for Azure Disks, because the portal filters vaults by compatibility with the datasource type.
The clue in the statement is the vault type: the table clearly indicates Recovery Services vault, not Backup vault. This detail is sufficient to identify the cause.
The information about Contributor permission, LRS redundancy, and absence of locks are purposefully irrelevant. None of them relate to the vault's absence from the selection list.
The most dangerous distractor is alternative A, since the permissions issue is a real problem in other contexts. An administrator who would investigate permissions instead of checking the vault type would waste time and reach a wrong conclusion, possibly recreating the vault with the same permissions and the same incorrect type.
Answer Key — Scenario 2
Answer: B
Enabling Soft Delete on a Backup vault is a non-destructive operation that can be performed at any time, including with ongoing jobs, without risk of data corruption or interruption of active operations. The statement explicitly declares that enabling Soft Delete does not require a maintenance window and does not interrupt ongoing jobs. This information eliminates the only technical argument that would support alternative A.
Alternative C would be valid in a scenario where the configuration could not be changed after creation, but the statement does not establish this restriction. Migrating 47 instances to a new vault in less than 2 hours would be operationally unfeasible and introduce unnecessary risks.
Alternative D is incorrect because the Soft Delete configuration can be changed by the administrator directly in the portal, without Microsoft support intervention.
The most dangerous distractor is alternative A: waiting for jobs before applying a configuration change seems prudent, but in this case represents unnecessary caution that would delay the resolution of a real vulnerability without any technical benefit.
Answer Key — Scenario 3
Answer: B
The error code UserErrorMissingRequiredPermissions and the message the vault's managed identity has been granted the necessary roles on the datasource precisely identify that the vault's managed identity does not have the necessary roles to access the PostgreSQL server. Enabling the managed identity on the vault is only the first step; roles must be explicitly assigned on the target resource for the backup service to operate.
The information about the Read-Only lock is the irrelevant information purposefully included. Read-Only type locks applied to the server's resource group do not prevent Azure services with correct permissions from accessing the resource data for reading via backup APIs. The lock restricts write and delete operations on the control plane, not the access of authorized services on the data plane.
The most dangerous distractor is alternative A. An administrator who associates the lock with the permissions error may erroneously conclude they need to remove the lock, which could generate an organizational conflict with the team that applied it, and still would not solve the real problem.
Answer Key — Scenario 4
Answer: A
The correct sequence is S, R, P, T, Q, which follows the diagnostic logic from most comprehensive to most specific:
- S confirms that the vault is operational before any other investigation. If the vault has health alerts, all other steps are irrelevant.
- R checks activity logs to identify if there was a configuration change that could have caused the job interruption.
- P checks if the policy is active and with valid scheduling, as a deactivated or corrupted policy would explain the
NotStartedstatus. - T checks the managed identity permissions on the storage account, which is a common cause for silent failures.
- Q confirms the storage account accessibility, which would be the last investigation resource before escalating the case.
Sequence B starts with the most specific (policy) before confirming if the vault is operational, which is a methodological error. Sequence C starts with permissions without first validating the vault or policy state. Sequence D starts with the storage account, which is the asset most distant from the vault in the diagnostic flow and least likely to be checked first.
Troubleshooting Tree: Create an Azure Backup vault
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Blue | Diagnostic question |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
To use this tree when facing a real problem, start with the root node by identifying the observed symptom, such as vault missing from list, job not started, or job failure. Follow the questions in each branch by answering with what is observable in the environment, without assuming the cause. Each answer eliminates a set of hypotheses and directs to a more specific verification. The path ends in a recommended action only after the diagnosis has eliminated alternative causes, avoiding corrections applied in the wrong place.