Troubleshooting Lab: Manage Access Keys
Diagnostic Scenarios
Scenario 1 — Root Cause
A web application hosted on an Azure App Service consumes files from a storage account of type GPv2. The application has been working normally for weeks. On Friday afternoon, the operations team executes a security maintenance routine and, hours later, the application starts returning 403 errors on all requests trying to read blobs.
The administrator checks the App Service and confirms it is running. They also verify the storage account firewall and find that the App Service IP is in the allow list. The storage account diagnostic log shows the following:
2026-03-26T18:42:11Z AuthenticationFailed
StorageErrorCode: AuthenticationFailed
AuthenticationType: SharedKey
CallerIP: 20.x.x.x
StatusCode: 403
ErrorMessage: Server failed to authenticate the request.
Make sure the value of Authorization header is formed
correctly including the signature.
The application's connection string is stored in the App Service Application Settings and hasn't been changed since the original deployment three months ago.
What is the root cause of the observed 403 error?
A) The storage account firewall is blocking the App Service IP despite it being listed.
B) The access key referenced in the connection string was regenerated during maintenance, making it invalid.
C) The App Service lost connectivity to the storage account endpoint due to network instability.
D) The storage account reached the requests per second limit and is returning temporary throttling errors.
Scenario 2 — Action Decision
The cause of an incident has been identified: the production storage account's key1 was accidentally regenerated by a team member who confused the production environment with staging. Key2 remains with the original value and is unknown to the production application, which uses only key1 via a connection string stored in Azure Key Vault.
The incident is active. The application has been down for 12 minutes. The team has the following confirmed information:
| Item | Status |
|---|---|
| key2 (original value) | Intact, available in portal |
| Connection string in Key Vault | References key1, outdated |
| Permission to regenerate key1 | Available |
| Maintenance window | Not open |
| Availability SLA | 99.9% monthly, already at risk |
What is the correct action to take at this moment to restore service as quickly as possible?
A) Regenerate key1 again, update the connection string in Key Vault with the new value, and restart the application.
B) Update the connection string in Key Vault to reference key2 and wait for the application's automatic reload.
C) Open a formal maintenance window, update the connection string in Key Vault to reference key2, and restart the application manually.
D) Revert the key1 regeneration through Azure Monitor Activity Log to restore the original value.
Scenario 3 — Root Cause
A Python automation script performs nightly blob backups between two storage accounts. The script runs on a VM and has worked without failures for two months. On Monday morning, the administrator receives an alert indicating that Sunday's backup failed.
When examining the script log, they find:
[2026-03-23 02:14:33] Starting backup job...
[2026-03-23 02:14:33] Source account: backupsource01
[2026-03-23 02:14:33] Destination account: backupdest01
[2026-03-23 02:14:35] ERROR: azure.core.exceptions.HttpResponseError:
(AuthorizationFailure) This request is not authorized to perform
this operation using this permission.
RequestId: a3f2...
StatusCode: 403
[2026-03-23 02:14:35] Backup job failed after 2 seconds.
The administrator checks the portal and confirms that:
- The VM is on and has normal network connectivity
- The storage account
backupsource01has firewall disabled - The storage account
backupdest01was migrated to a new subscription on the previous Friday - The script uses a SAS token generated 65 days ago, with original validity of 60 days
- The VM and storage accounts region experienced no reported incidents
What is the root cause of the backup failure?
A) The migration of storage account backupdest01 to another subscription changed its endpoint, invalidating script references.
B) The SAS token used by the script expired before Sunday's backup execution.
C) The storage account backupsource01 firewall blocked the request from the VM during the nighttime window.
D) The migration of storage account backupdest01 to another subscription automatically revoked all associated SAS tokens.
Scenario 4 — Diagnostic Sequence
An administrator receives a ticket: an application is failing to access a storage account with intermittent authentication errors. They have access to the Azure portal, Azure Monitor, and the application code.
The available investigation steps are:
- Step P: Check the Activity Log for recent
listKeysoperations or key regeneration on the storage account - Step Q: Check the application code for which authentication mechanism is being used (access key, SAS, or Managed Identity)
- Step R: Confirm if the "Disable storage account key access" option is enabled on the storage account
- Step S: Verify if the connection string or key referenced in the application matches the current access key value in the portal
- Step T: Check the storage account diagnostic log for
AuthenticationTypeandStatusCodereturned on failed requests
What is the most efficient diagnostic sequence, starting from symptom to cause?
A) T, Q, R, P, S
B) Q, T, R, S, P
C) P, S, R, Q, T
D) R, P, T, Q, S
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
Explanation:
- The log shows
AuthenticationType: SharedKeyandAuthenticationFailedwith the message that the request signature is incorrect. This indicates that the key used to sign the request doesn't match the key stored on the server, which is the exact behavior after a key regeneration. - The decisive clue in the scenario is that the "security maintenance" occurred hours before the errors started, and that the connection string "hasn't been changed since the original deployment." The key was changed on the server, but the application still has the old value.
- The information about the firewall and App Service IP is deliberately irrelevant: firewall errors result in timeouts or TCP connection rejections, never in
AuthenticationFailedwith StatusCode 403 and invalid signature message. - Distractors A and C represent the classic error of focusing on the visible element (firewall, network) instead of reading the exact type of authentication error. Distractor D is dismissible because throttling errors return StatusCode 503 or 429, not 403.
- Acting on distractor A, trying to adjust firewall rules, would delay resolution with no effect, prolonging the incident.
Answer Key — Scenario 2
Answer: B
Explanation:
- Key2 is intact and available. Updating the connection string in Key Vault to reference key2 is the action that restores service with the fewest steps and without depending on any additional regeneration.
- Alternative A is technically valid in another context, but requires regenerating key1, updating Key Vault, and restarting the application: three steps where two are sufficient with alternative B.
- Alternative C represents a correct action applied at the wrong time. Requiring a maintenance window opening when SLA is already at risk and an immediate solution is available is a poor governance decision.
- Alternative D is the most dangerous distractor: the Activity Log records that the regeneration operation occurred, but does not store the previous key value. There is no access key rollback mechanism in Azure. Acting on this alternative would consume critical incident time with no possible result.
- The clue that key2 is "intact and available" is the central element of the scenario that should guide the decision.
Answer Key — Scenario 3
Answer: B
Explanation:
- The scenario explicitly states that the SAS token was generated 65 days ago with original validity of 60 days. Therefore, it expired 5 days before Sunday's backup execution. An expired SAS token results exactly in the
AuthorizationFailureerror with StatusCode 403 that the log shows. - The migration of
backupdest01to another subscription is irrelevant information inserted purposefully. Subscription migrations in Azure don't change the storage account endpoint nor invalidate existing SAS tokens, contrary to what distractor D suggests. - Distractor A is superficially plausible but incorrect: a storage account's endpoint is not changed by a subscription change.
- Distractor C is dismissible because the scenario explicitly states that the
backupsource01firewall is disabled, and the error occurs on thebackupdest01operation. - Distractor D represents a real and common technical misconception: SAS tokens are derived from access keys at generation time, but subscription migration doesn't retroactively invalidate them. Believing this would lead the administrator to unnecessarily regenerate keys instead of simply recreating the SAS token.
Answer Key — Scenario 4
Answer: B
Explanation:
- The correct sequence is Q, T, R, S, P because it follows progressive diagnostic logic: first understand the authentication mechanism in use (Q), then observe what the system is returning for that mechanism (T), next verify if key access is enabled on the storage account (R), compare the value referenced in the application with the current value (S), and lastly investigate if there was a recent event that could have caused the divergence (P).
- Starting with P (Activity Log) without even knowing which authentication mechanism is in use is premature: the log would be analyzed without sufficient context to interpret relevant events.
- Alternative A reverses priorities by starting with telemetry (T) before understanding the application context (Q), which can lead to incorrect log interpretations.
- Alternative C starts with the hypothetical cause (P) instead of the observable symptom, violating the progressive diagnostic principle.
- Alternative D starts with R, which only makes sense after confirming the mechanism in use is SharedKey; checking this configuration for an application using Managed Identity would be an irrelevant step.
Troubleshooting Tree: Manage Access Keys
Color Legend:
| Color | Meaning |
|---|---|
| Dark blue | Root node: initial symptom or failure |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate validation or verification |
When facing a 403 error on a storage account, start with the root node and read the AuthenticationType in the diagnostic log to choose the initial path. If the type is SharedKey, check if key access is disabled before comparing key values. If it's SAS, validate the token validity. If it's Microsoft Entra ID authentication, investigate RBAC role assignments. In each path, follow the diagnostic questions until reaching a cause node (red), apply the corresponding action (green), and finally validate recovery through the orange node before closing the incident.