AZ-204 Develop for Azure storage Practice Question
Which TWO of the following are valid approaches to secure access to Azure Blob Storage?
⚠ Common exam trap
Many exam-takers confuse Azure Front Door's traffic routing and WAF capabilities with actual blob-level authentication, or they mistakenly believe embedding storage account keys is acceptable for client-side applications, ignoring the severe security implications.
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
✓
Use a Shared Access Signature (SAS) token
Option A is correct because a Shared Access Signature (SAS) is a signed URI token that grants time-limited, scoped, and permission-specific delegated access to Blob Storage resources (containers, blobs, or specific operations like read/write) without exposing the storage account keys. Option C is correct because Azure RBAC roles such as Storage Blob Data Contributor (and Storage Blob Data Reader/Owner) grant Microsoft Entra ID identities fine-grained, least-privilege access to blob data at the management and data-plane level, which is the recommended modern approach for securing Blob Storage. Option B is not a valid access-control mechanism for Blob Storage itself — Azure Front Door is a global HTTP load balancer/CDN that can front a storage endpoint but does not authenticate or authorize blob access. Option D is incorrect because embedding storage account keys in client code exposes full administrative credentials to anyone who obtains the code, violating security best practices. Option E is incorrect because enabling public blob access allows anonymous unauthenticated reads of blobs, which directly weakens rather than secures access.
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 a Shared Access Signature (SAS) token
Why this is correct
Shared Access Signatures (SAS) tokens provide a secure, delegated way to grant time-limited access to specific Azure Storage resources, such as blobs or containers. They allow you to define granular permissions (read, write, delete, list) and a validity period, ensuring that clients only have the necessary access for a defined duration without exposing your storage account keys. This approach is highly effective for distributing access to external clients or web applications.
- ✗
Use Azure Front Door to restrict access
Why it's wrong here
Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network to create fast, secure, and widely scalable web applications. While it offers Web Application Firewall (WAF) capabilities for security against common web exploits and can route traffic, it does not inherently provide identity-based access control or authorization mechanisms for Azure Storage accounts or individual blobs. Its primary role is content delivery and network-level protection, not authentication or authorization to backend storage.
- ✓
Assign RBAC roles like Storage Blob Data Contributor
Why this is correct
Azure Role-Based Access Control (RBAC) allows for fine-grained access management to Azure resources, including storage accounts and their data. By assigning built-in roles like "Storage Blob Data Contributor" or custom roles to Microsoft Entra ID (Azure AD) identities (users, groups, service principals), you can grant specific permissions to perform data operations on blobs. This method leverages Microsoft Entra ID for robust authentication and authorization, providing a secure and auditable security model for internal applications and users.
- ✗
Embed storage account keys in client code
Why it's wrong here
Embedding storage account keys directly into client-side code is a highly insecure practice that grants full administrative access to all data within the storage account across all services (blobs, files, queues, tables). If compromised, an attacker would have unrestricted access, leading to potential data breaches, modification, or deletion. This method bypasses all granular access controls and is extremely difficult to revoke or rotate securely once distributed, making it a significant security vulnerability.
- ✗
Enable public blob access
Why it's wrong here
Enabling public blob access, either at the container level (anonymous read access to blobs and container metadata) or blob level (anonymous read access to blobs), makes the data accessible to anyone on the internet without any authentication or authorization. This completely negates any security measures and is only appropriate for publicly distributable, non-sensitive content. For securing confidential or restricted data, public access must be disabled to prevent unauthorized data exposure.
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
One of 883 original AZ-204 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.