AZ-204 Implement Azure security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  After user authentication, have the client generate a SAS token using the storage account key retrieved from a secure endpoint.

  Why it's wrong here

  The storage account key grants full administrative access to the entire storage account. If this key is ever exposed to the client-side code, even temporarily or through a 'secure endpoint' that then passes it to the client for SAS generation, it creates a severe security vulnerability. A malicious user could intercept or extract this key and gain unrestricted access to all containers, blobs, queues, and tables within the storage account, bypassing any intended access controls. This completely undermines the principle of least privilege and is an unacceptable security risk.

• ✓

  After user authentication, use the server-side code to generate a user delegation SAS for a specific blob container path that includes the user's identifier. Store the SAS in the user's session and return it to the client. The client then uses the SAS to upload the file directly to Blob Storage.

  Why this is correct

  This approach is correct because it leverages a User Delegation SAS, which is generated server-side using an Azure AD identity (not the storage account key) and provides fine-grained, time-limited permissions. By scoping the SAS to a specific blob container path incorporating the user's identifier, it ensures each user can only access their designated storage area, upholding data isolation and the principle of least privilege. The client receives only the SAS token, enabling direct and secure uploads to Blob Storage without the server acting as an intermediary or exposing sensitive credentials.

• ✗

  After user authentication, use the server-side code to generate a service SAS for the entire blob container. Return the SAS to the client. The client uploads the file, and the server later moves the file to a user-specific folder.

  Why it's wrong here

  Generating a service SAS for the entire blob container and returning it to the client grants that client broad access to all blobs within that container, not just their own. This violates the security principle of least privilege and the requirement that users should only see their own files, as a malicious user could potentially list, read, or overwrite other users' data. While the server might later move files, the initial broad access granted by the SAS is an unacceptable security risk, and the 'move later' strategy adds unnecessary complexity and latency.

• ✗

  After user authentication, use the server to upload the file to Blob Storage using the storage account key. Then return the URL of the uploaded blob to the client.

  Why it's wrong here

  While using the storage account key on the server is generally more secure than exposing it to the client, it still carries risks if the server-side code is compromised. More critically, having the server act as an intermediary for all file uploads introduces a significant scalability bottleneck. The server becomes responsible for receiving the entire file from the client, then re-uploading it to Blob Storage, consuming server resources (CPU, memory, network bandwidth) and increasing latency. This approach does not leverage the direct-to-storage capabilities of SAS tokens, which offload the upload burden from the application server.