Resolve the exception:Azure.RequestFailedException at Azure.Storage.Queues.QueueRestClient+

Hi @Jain, Lisha ,

Thanks for reaching out to Microsoft Q&A.

In most cases this happens due to how the Functions runtime is connecting to your storage account and whether the Function App identity has the right RBAC roles.

Here are a couple of ways to fix it:

1. Enable the System-Assigned Managed Identity in your Function App,

• In your storage account’s IAM (Access control) assign:
• “Storage Blob Data Contributor” for the blob-trigger’s service URI
• “Storage Queue Data Contributor” for the queue-trigger’s service URI

Correct env variables, they are called: FileUploadStorage__queueServiceUri (for queues) and FileUploadStorage__serviceUri(for blobs).

For identity-based connections, Azure Functions expects a specific format as below:

In Configuration, add two app settings:

FileUploadStorage__blobServiceUri = https://<storage>.blob.core.windows.net
FileUploadStorage__queueServiceUri = https://<storage>.queue.core.windows.net

• In your C# code, refer to those with:

    [BlobTrigger("my-container", Connection = "FileUploadStorage")]
    [QueueTrigger("my-queue", Connection = "FileUploadStorage")]
    
  

• Deploy.

The runtime will pick up the service URIs, use DefaultAzureCredential which uses the managed identity, and authenticate properly.

Additional checks:

• Ensure the blob container name and queue name match exactly (they’re case-sensitive and must exist).
• The blob trigger container must exist before the function runs. Example:

    [BlobTrigger("uploads/{name}")]
  

• Make sure you’re on a Functions runtime version that supports serviceUri parameters.
• Check your Function’s Log Stream / Application Insights for more detailed failure messages.

Hope this helps!

The error Azure.RequestFailedException with Status: 403 and ErrorCode: AuthorizationFailure indicates that the function app is reaching the storage account but the request is being rejected at authorization time. The additional 404 errors for queue/blob typically mean the SDK is trying to access resources that either don’t exist yet or are hidden behind authorization issues.

Based on the context, focus on these areas:

1. Check authentication method and token validity
   A 403 AuthorizationFailure in Azure Storage commonly comes from:
   • An invalid or malformed SAS token or shared key.
   • Using a SAS with IP restrictions (sip) or network restrictions that don’t match the function app’s outbound IPs.
   • Using a SAS or key that doesn’t match the storage account.
   From the 403 troubleshooting guidance:
   • For SAS: verify the signature, expiry (se), and start time (st) and avoid clock-skew issues. If using SAS, regenerate it with correct permissions and a future expiry, and without overly strict IP restrictions.
   • If using account keys and they were regenerated, ensure the function app configuration is updated with the new key.
   See: common authentication failures such as AuthenticationFailed and AuthorizationFailure and how to validate tokens and signatures.
2. Verify RBAC vs. data-plane access
   Having data-plane RBAC roles like Storage Blob Data Owner and Queue Contributor is necessary when using Azure AD/Entra ID, but a 403 can still occur if:
   • The function app’s managed identity is not the principal actually used by the SDK (for example, connection string or SAS is still configured and takes precedence).
   • The role assignment scope is wrong (e.g., assigned at subscription or resource group, but the function is accessing a different storage account).
   For authorization failures:
   • Confirm that the identity used by the function (system-assigned or user-assigned managed identity) has the correct data-plane roles on the specific storage account or queue/container.
   • Ensure the role assignment scope includes the target storage account.
3. Check network/firewall restrictions on the storage account
   A 403 AuthorizationFailure can also be caused by network restrictions:
   • Public network access disabled.
   • IP address restrictions that do not include the function app’s outbound IPs.
   • Virtual network or firewall rules blocking the request.
   Validate on the storage account:
   • If “Selected networks” is enabled, ensure the function app’s outbound IPs or its VNet integration subnet are allowed.
   • If using private endpoints, ensure DNS and routing are correctly configured so the function app resolves the storage account to the private endpoint.
4. Resolve the 404 for queue and blob
   The 404 errors:
   • The specified queue does not exist.
   • The specified blob does not exist.
   can be caused by:
   • The client attempting to use a SAS that doesn’t include the necessary permissions; in some cases, Azure Storage returns 404 to avoid leaking existence information when authorization fails.
   • The queue or container/blob truly not existing yet.
   From the client error guidance:
   • If a SAS doesn’t include required permissions, the service can return HTTP 404 while Azure Monitor shows AuthorizationError. Investigate why the client is attempting an operation without the required permissions.
   • Ensure the queue and container names used in configuration exactly match the actual resources in the storage account.
   • For queues used by the function (e.g., poison queues or auxiliary queues), create them explicitly or ensure code calls CreateIfNotExists and that this call succeeds before other operations.
5. Concrete steps to fix in this scenario
   1. In the storage account:
      • Confirm the blob container and queue names used by the function exist.
      • If they don’t, create them manually.
   2. In the function app configuration:
      • Verify FileUploadStorage__serviceUri and FileUploadStorage__queueServiceUri point to the correct storage account endpoints.
      • If using SAS or connection strings, regenerate them with correct permissions and no conflicting IP restrictions.
   3. In Azure RBAC:
      • Confirm the managed identity of the function app has appropriate roles (for blob and queue data) at the storage account scope.
   4. In the storage account networking settings:
      • Ensure the function app is allowed by firewall/VNet rules.
   5. After changes, redeploy or restart the function app so new settings take effect and retest.

If, after these checks, 403 persists, capture the x-ms-request-id and x-ms-error-code from the failing calls and use Azure resource logs for the storage account to see the exact reason (authorization vs. network vs. token issue) as described in the 403 troubleshooting article.

References:

• Troubleshoot 403 errors in Azure Blob Storage
• Common errors related to authentication failures
• Common errors related to authorization failures
• Troubleshoot client application errors in Azure storage accounts
• Status and error codes