You are developing a C# background service that runs on an Azure Virtual Machine and processes data files. The service needs to authenticate to an Azure Queue Storage queue named tasks-queue and enqueue processing tasks. Some task payloads are estimated to be around in size. You must ensure that the solution adheres to the principle of least privilege, uses passwordless authentication where possible, and handles the task payloads successfully.
Which of the following designs should you implement?
- Authenticate the queue client using a system-assigned managed identity via DefaultAzureCredential, store the payloads in Azure Blob Storage, and write the blob reference URL as the queue message.Cevap
- BAuthenticate the queue client using a system-assigned managed identity via DefaultAzureCredential, and write the raw payload directly to the queue as a single message.
- CAuthenticate the queue client using an account-level Shared Access Signature (SAS) token configured with full read, write, and delete permissions for the entire storage account.
- DAuthenticate the queue client using a system-assigned managed identity that is shared across multiple independent Azure Virtual Machines running the background service.
Cevap
Authenticate the queue client using a system-assigned managed identity via DefaultAzureCredential, store the payloads in Azure Blob Storage, and write the blob reference URL as the queue message.
The correct design uses a system-assigned managed identity via DefaultAzureCredential to securely connect to the queue without credentials stored in code, satisfying the least privilege and passwordless requirements. Since the payload size is and exceeds the hard limit of Azure Queue Storage, the payload is offloaded to Azure Blob Storage, and a reference URL is written to the queue instead (the claim-check pattern).
Adım Adım Çözüm
Anahtar Kavram
Handling large message payloads via Blob Storage and secure access using managed identities in Azure Queue Storage