AZ-104 Implement and Manage Storage Practice Question
A web app running in Azure App Service must upload files to a blob container. The team wants to avoid storing any secrets in application settings and wants the app to authenticate without a password or access key. What should the administrator configure?
⚠ Common exam trap
Watch out — candidates often confuse managed identities with SAS tokens or access keys, assuming any form of shared secret is acceptable, but the question explicitly requires no secrets in application settings and no password or access key.
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
✓
Enable a system-assigned managed identity for the app and grant it a storage data role
A system-assigned managed identity allows the App Service to authenticate to Azure Storage without storing any secrets. By granting the identity the 'Storage Blob Data Contributor' role via Azure RBAC, the app can upload files using Azure AD authentication, eliminating the need for passwords or access keys.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the storage account key in the app configuration and use it from the application
Why it's wrong here
Storing the storage account key in App Service application settings is a common but poor practice: the account key is a static shared secret that grants full control over all data in the storage account. It is not scoped to a single container, and because it's stored in configuration, it must be rotated regularly and had tight security controls to avoid leakage from the portal, deployment logs, or the app config. This approach also bypasses Microsoft Entra ID identity-based access, so you lose per-user or per-app source auditing and must manage secret lifecycle overhead.
When this WOULD be correct
This option would be correct if the question allowed storing secrets in application settings and did not mandate passwordless authentication. For example, if the requirement was simply to connect to blob storage from App Service without specifying secretless methods, using the storage account key in app settings would be a valid approach.
- ✓
Enable a system-assigned managed identity for the app and grant it a storage data role
Why this is correct
Enabling a system-assigned managed identity for the App Service and granting it the Storage Blob Data Contributor (or Owner) role lets the app authenticate to Azure Storage using Microsoft Entra ID. This is the recommended approach because the App Service runtime automatically obtains an OAuth 2.0 token from the managed identity endpoint, requiring no credentials in code or configuration. The identity is tied to the app's lifecycle, so secrets are never stored, rotated, or leaked. This provides fine-grained, auditable access to the specific storage container, fully satisfying the requirement for controlled, credential-free uploads.
- ✗
Create an anonymous public container so the app can upload without authentication
Why it's wrong here
Creating an anonymous public container would expose the blob container to anyone with the URL, granting unauthenticated upload access on the public internet. This not only violates Azure security best practices but also makes it impossible to identify which user or application performed an upload, breaking auditability and access control. Anonymous access is intended only for read-only public content, never for write operations, and it directly contradicts the requirement for authenticated uploads.
When this WOULD be correct
If the question asked for a solution to allow public read access to blobs (e.g., for a static website) without requiring authentication, and the app only needs to read files, then an anonymous public container would be correct.
- ✗
Use a shared access signature generated from the storage account root key
Why it's wrong here
A shared access signature (SAS) generated from the storage account root key delegates specific permissions but still depends on aggregating and storing that root key in the app's configuration or a key vault. While a SAS can be scoped and time-limited, the app must obtain it at runtime, which either puts the root key in environment settings or forces you to build a secret-brokering service. More seriously, if the root key is compromised, all SAS tokens generated from it are also compromised, so it does not offer the same security as managed identity, which uses short-lived token signed by Azure AD.
When this WOULD be correct
This option would be correct if the question asked for a time-limited, delegated access method for a specific blob container without requiring the app to have a managed identity, and the SAS could be generated externally (e.g., by a separate secure service) and passed to the app.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Enable a system-assigned managed identity for the app and grant it a storage data roleCorrect answer▾
Why this is correct
Enabling a system-assigned managed identity for the App Service and granting it the Storage Blob Data Contributor (or Owner) role lets the app authenticate to Azure Storage using Microsoft Entra ID. This is the recommended approach because the App Service runtime automatically obtains an OAuth 2.0 token from the managed identity endpoint, requiring no credentials in code or configuration. The identity is tied to the app's lifecycle, so secrets are never stored, rotated, or leaked. This provides fine-grained, auditable access to the specific storage container, fully satisfying the requirement for controlled, credential-free uploads.
✗Store the storage account key in the app configuration and use it from the applicationWrong answer — click to see why▾
Why this is wrong here
The question explicitly requires avoiding secrets in application settings and authenticating without a password or access key. Storing the storage account key in app configuration violates both requirements, as the key is a secret and must be stored securely.
★ When this WOULD be the correct answer
This option would be correct if the question allowed storing secrets in application settings and did not mandate passwordless authentication. For example, if the requirement was simply to connect to blob storage from App Service without specifying secretless methods, using the storage account key in app settings would be a valid approach.
Why candidates choose this
Candidates may default to using storage account keys because it's a familiar and straightforward method for accessing Azure Storage, and they might overlook the specific requirement to avoid secrets and use passwordless authentication.
✗Create an anonymous public container so the app can upload without authenticationWrong answer — click to see why▾
Why this is wrong here
The question requires authenticated uploads without secrets; anonymous public containers allow unauthenticated access, violating the requirement to avoid secrets and potentially exposing the container to unauthorized uploads.
★ When this WOULD be the correct answer
If the question asked for a solution to allow public read access to blobs (e.g., for a static website) without requiring authentication, and the app only needs to read files, then an anonymous public container would be correct.
Why candidates choose this
Candidates may think anonymous access simplifies authentication by removing the need for keys, but they overlook the security implications and the requirement for authenticated uploads.
✗Use a shared access signature generated from the storage account root keyWrong answer — click to see why▾
Why this is wrong here
The question requires passwordless authentication without secrets, but a shared access signature (SAS) is derived from a storage account key, which is a secret. The SAS itself must be stored or generated at runtime, introducing a secret management issue.
★ When this WOULD be the correct answer
This option would be correct if the question asked for a time-limited, delegated access method for a specific blob container without requiring the app to have a managed identity, and the SAS could be generated externally (e.g., by a separate secure service) and passed to the app.
Why candidates choose this
Candidates may think SAS provides secure, keyless access because it can be scoped and expired, but they overlook that generating a SAS requires a key, which violates the 'no secrets' constraint.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Privileged Identity Management (PIM)
Key term
System-assigned managed identity
A system-assigned managed identity is an automatically created Azure Active Directory identity that is tied to a specific Azure resource and is used to securely authenticate to other Azure services without storing credentials.
Key term
Container
A container is a lightweight, standalone software package that includes everything needed to run an application, such as code, runtime, system tools, and libraries.
About these practice questions
One of 1,049 original AZ-104 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 →
Same concept, more angles
3 more ways this is tested on AZ-104
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A web app running in Azure App Service must upload images to a blob container without storing any account keys, passwords, or connection strings in configuration. The app uses only one Azure resource. What should the administrator configure?
medium- ✓ A.A system-assigned managed identity on the App Service and an Azure RBAC role on the storage account.
- B.The storage account key, because it is the simplest way to authenticate an application securely.
- C.A shared access signature embedded in the app settings, because SAS is the same as managed identity.
- D.An anonymous public container with write access disabled on the account.
Why A: A system-assigned managed identity allows the App Service to authenticate to Azure Storage without storing any credentials in configuration. By assigning the RBAC role (e.g., Storage Blob Data Contributor) to that identity, the app can securely upload images using Azure AD authentication, meeting the requirement of no account keys, passwords, or connection strings.
Variation 2. A web app running in Azure App Service must read blobs from a storage account. The app must authenticate without storing secrets or SAS tokens, and administrators should grant only blob data permissions, not storage management permissions. What should you configure?
medium- A.The storage account access key in an application setting, because it works with any blob operation.
- ✓ B.A system-assigned managed identity for the app with Storage Blob Data Reader assigned at the storage scope.
- C.The Contributor role on the storage account, because it includes both management and data permissions.
- D.A service endpoint on the subnet, because service endpoints are used for application authentication.
Why B: A system-assigned managed identity allows the App Service to authenticate to Azure Storage without storing any secrets or SAS tokens. By assigning the Storage Blob Data Reader role at the storage account scope, you grant only the necessary blob read permissions while explicitly excluding any storage management permissions (e.g., creating or deleting storage accounts). This aligns with the principle of least privilege and eliminates credential management overhead.
Variation 3. A web API running in an Azure App Service needs to read and write blobs in a storage account. The operations team does not want to store secrets in app settings or rotate credentials manually. What should they enable on the App Service?
medium- A.A storage account access key stored in Key Vault
- ✓ B.A system-assigned managed identity
- C.A shared access signature embedded in the application settings
- D.A service endpoint on the App Service integration subnet
Why B: A system-assigned managed identity allows the App Service to authenticate to Azure Storage without storing any secrets. The identity is automatically managed by Azure AD, and the App Service can use it to obtain an OAuth 2.0 token for accessing blob storage via RBAC. This eliminates the need for manual credential rotation and secret storage.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 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-104 exam.