AZ-204 Develop for Azure storage Practice Question
You are building a web application that stores user-uploaded images in Azure Blob Storage. The application requires that images be accessible only via a time-limited URL. Which security mechanism should you use?
⚠ Common exam trap
Many exam-takers confuse persistent access control methods (like RBAC roles or account keys) with the time-limited, delegated access that only a SAS token provides, leading them to pick options that secure the key but do not enforce an expiration on the URL.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Generate a shared access signature (SAS) token for each blob.
A shared access signature (SAS) token provides delegated, time-limited access to a specific blob without exposing the storage account key. By generating a SAS token with an expiration time, you can enforce that the image URL is only valid for a limited period, meeting the requirement exactly. This is the standard Azure mechanism for granting granular, time-bound access to blob storage resources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use storage account access keys in the application code.
Why it's wrong here
Storing storage account access keys directly in application code is a significant security risk, as these keys grant full administrative access to all data within the storage account. This approach lacks granular control, making it impossible to restrict access to specific blobs or implement time-limited permissions for individual operations. If compromised, an access key could lead to unauthorized access to all stored data, violating the principle of least privilege and posing a severe data breach threat.
- ✓
Generate a shared access signature (SAS) token for each blob.
Why this is correct
Generating a Shared Access Signature (SAS) token for each blob is the most appropriate solution for providing secure, time-limited access to specific storage resources. A SAS token is a URI that grants restricted permissions to Azure Storage resources for a specified interval or with specific permissions, such as read or write. This allows the application to provide users with temporary, granular access to upload or retrieve individual blobs without exposing the storage account's primary keys, aligning perfectly with the need for controlled, temporary access.
- ✗
Assign the 'Storage Blob Data Reader' role to the application's managed identity.
Why it's wrong here
Assigning the 'Storage Blob Data Reader' role to the application's managed identity grants the application itself persistent read access to *all* blobs within the storage account. While Azure RBAC is crucial for controlling data-plane access, it does not provide the mechanism to generate time-limited, per-blob access tokens for *end-users* or external clients. This approach would give the application broad, continuous access, rather than enabling the application to issue temporary, restricted access to individual users for specific blobs, which is the core requirement.
- ✗
Use Azure Key Vault to store and retrieve the storage account key.
Why it's wrong here
While Azure Key Vault is an excellent service for securely storing secrets like storage account keys, merely storing and retrieving the key from Key Vault does not inherently provide a mechanism for generating time-limited, granular access URLs for individual blobs. The application would still need to use that retrieved key to *create* a Shared Access Signature (SAS) token. Key Vault protects the key itself from being hardcoded or easily compromised, but it doesn't directly facilitate the creation of temporary, user-specific access to storage resources, which is the core requirement.
Quick reference
Azure Blob Storage Tier Comparison
| Tier | Storage Cost | Retrieval Cost | Latency | Use Case |
|---|---|---|---|---|
| Hot | Highest | Lowest | Immediate | Active data, frequent reads |
| Cool | Lower | Higher | Immediate | Data accessed < once / month |
| Cold | Lower still | Higher | Immediate | Data accessed < once / quarter |
| Archive | Lowest | Highest + rehydration delay | Hours | Long-term compliance retention |
Go deeper
Related to this question
About these practice questions
Courseiva writes every AZ-204 question from scratch — 881 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-204 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-204 exam.