Troubleshooting Lab: Configure backup for an App Service
Diagnostic Scenarios
Scenario 1 — Root Cause
An administrator reports that automatic backups for an App Service stopped being generated three days ago. The App Service is on a Standard S2 plan, hosts a .NET application in production, and is linked to an Azure SQL database. The application continues responding normally to all requests.
The administrator checks the backup history in the portal and finds the following error message repeated in the last three scheduled runs:
Backup failed: Unable to access the storage destination.
StorageErrorCode: AuthorizationFailure
Container: app-backups
Timestamp: 2025-03-23T02:00:00Z
The administrator additionally reports that:
- The storage account exists and the
app-backupscontainer is present - The App Service was migrated to a new Resource Group four days ago
- The Storage Account region is different from the App Service region
- The App Service plan was not changed
What is the root cause of the backup failures?
A) The destination container was deleted during the migration to the new Resource Group.
B) The SAS URL configured for backup expired or was invalidated after the migration to the new Resource Group.
C) The region difference between the App Service and Storage Account started blocking access after the migration.
D) The linked Azure SQL database is no longer accessible from the new Resource Group, causing complete backup failure.
Scenario 2 — Action Decision
The problem cause has been identified: the SAS URL configured in the App Service backup expired. The App Service is in production, receiving heavy traffic, and the team has a maintenance window scheduled in 48 hours. The most recent valid backup is 3 days old.
The team discussed the following actions:
- Revoke the current SAS and generate a new SAS with 2-year validity
- Wait for the maintenance window to reconfigure backup with the new SAS
- Trigger a restore from the most recent backup to validate integrity
- Update the backup configuration with the new SAS URL immediately, without waiting for the window
What is the correct action to take at this moment?
A) Wait for the 48-hour maintenance window to reconfigure backup, avoiding any changes in production outside the window.
B) Trigger a restore from the 3-day backup to validate if the backup is intact before any other action.
C) Update the backup configuration with the new SAS URL immediately, without waiting for the maintenance window.
D) Revoke the current SAS before generating the new one, to ensure no duplicate credentials are simultaneously active.
Scenario 3 — Root Cause
A newly hired administrator tried to configure automatic backup for an App Service and reports that the backup feature simply doesn't appear as an option in the Azure portal menu. He opens a ticket describing the behavior:
Environment:
- App Service Name: webapp-homolog-01
- Plan: B1 (Basic)
- Operating System: Linux
- Stack: Node.js 20
- Region: East US
- Resource Group: rg-homologacao
Observed behavior:
The "Backups" option doesn't appear in the App Service side menu in the portal.
I tried accessing via direct URL and received a 404 error in the backup panel.
The administrator also mentions that he tested on two other App Services in the company and the backup menu appeared normally in both. He verified that he has the Contributor role in the Resource Group. The App Service uses a Custom Domain configured two weeks ago.
What is the root cause of the problem?
A) The Contributor role is not sufficient to access backup functionality; the Owner role is required in the Resource Group.
B) App Services with Linux operating system on Basic plan don't support Azure's native backup feature.
C) The Custom Domain configuration performed recently is blocking access to the backup panel in the portal.
D) The Basic plan doesn't support the native backup feature, regardless of operating system.
Scenario 4 — Diagnostic Sequence
An administrator receives an alert that a scheduled App Service backup failed. He has access to the Azure portal, the Storage Account configured as destination, and the application's backup history. Below are the available investigation steps, presented out of order:
[P] Check if the App Service plan supports backup
[Q] Check the detailed error message in the App Service backup history
[R] Try executing a manual backup to confirm if the failure is recurring
[S] Check if the SAS URL is valid and if the destination container exists and is accessible
[T] Check if the linked database is correctly listed in the backup configuration
What is the most efficient and logically progressive diagnostic sequence?
A) P, Q, S, T, R
B) Q, P, S, T, R
C) S, Q, P, T, R
D) R, Q, S, P, T
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The AuthorizationFailure error message indicates that Azure attempted to access the Storage Account, but authorization failed. The container exists and the Storage Account is accessible, ruling out accidental deletion (alternative A). The real cause is that the SAS URL used in the backup configuration was invalidated or expired. Resource Group migrations don't directly invalidate SAS, but it's common that during this process, configurations are reviewed and the SAS may have been regenerated or removed without the backup being updated.
The information about the region difference between the Storage Account and App Service is purposely irrelevant: Azure allows cross-region backup without restrictions, and this condition existed before the failure without causing problems. Alternative D is plausible, but the error returned is authorization on Storage, not connectivity with the database; linked database backup errors produce distinct messages. The most dangerous distractor is A: confirming the container exists before checking SAS validity can lead the administrator to waste time unnecessarily creating a new container.
Answer Key — Scenario 2
Answer: C
The cause has already been identified (expired SAS) and the correction is non-destructive: updating the SAS URL in the backup configuration doesn't affect application traffic, doesn't cause downtime, and doesn't change any running components. Waiting 48 hours (alternative A) unnecessarily prolongs the period without valid backup in a production environment, which represents real operational risk. Triggering a restore (alternative B) would be a destructive and unnecessary action at this moment, since the problem isn't backup integrity, but access configuration. Revoking the SAS before generating the new one (alternative D) would create a window without valid configuration, making the problem temporarily worse. The critical restriction in the scenario is the risk of continuing without backup, which outweighs any argument for waiting for the maintenance window.
Answer Key — Scenario 3
Answer: D
The Basic plan doesn't support App Service's native backup feature, regardless of operating system or stack used. Support starts with the Standard plan. The absence of the menu in the portal is expected behavior for unsupported plans. The fact that the menu appears in the company's other two App Services indicates they're on higher plans, which is confirmatory evidence.
The information about Custom Domain is irrelevant and was purposely included to misdirect the diagnosis. Custom Domains have no relationship with backup feature availability. Alternative B is the most refined distractor: it mixes two real factors (Linux operating system and Basic plan), but the determining restriction is exclusively the plan, not the OS. Alternative A is factually incorrect: the Contributor role is sufficient to configure backups.
Answer Key — Scenario 4
Answer: B
The correct sequence is Q, P, S, T, R, which follows progressive diagnostic logic:
- Q — Reading the detailed error message is always the first step; it directs all others.
- P — Checking if the plan supports backup eliminates the most fundamental cause before investigating configurations.
- S — Validating the SAS URL and container addresses the destination access problem, the most frequent error in established backups.
- T — Checking the linked database covers a less common cause, investigated after the more likely ones.
- R — Executing a manual backup at the end confirms if the applied correction resolved the problem, serving as validation.
Sequence D (starting with manual backup) represents the classic error of testing before diagnosing: the manual backup will fail for the same reason, without adding new information. Sequence A (starting with P) ignores the error message, which would already provide the correct direction at no cost.
Troubleshooting Tree: Configure backup for an App Service
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (root) |
| Blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Validation or intermediate verification |
When facing a backup failure, start at the root node and answer each question based on what is observable in the portal or logs. The first bifurcation point separates resource availability problems (incompatible plan) from execution problems (invalid configuration). Follow the path that corresponds to what you observe, not what you suspect. When you reach an action, execute it and return to the validation node before ending the diagnosis.