AZ-204 Develop for Azure storage Practice Question
Your application runs on Azure App Service and needs to access Azure Queue Storage. You want to avoid storing connection strings in configuration files. Which approach should you use?
⚠ Common exam trap
A common mix-up: candidates choose Key Vault references (Option D) thinking it's the most secure, but fail to recognize that managed identity eliminates the need for any secret at all, which is the true 'zero-trust' approach tested in AZ-204.
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 system-assigned managed identity with RBAC role 'Storage Queue Data Contributor' on the queue.
Using a system-assigned managed identity for an Azure App Service allows it to authenticate to Azure Queue Storage without any stored secrets. By assigning the 'Storage Queue Data Contributor' RBAC role, the app gains the necessary permissions to read, write, and delete queue messages, and the identity is automatically managed by Azure AD, eliminating the need for connection strings.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Hardcode the connection string in the application code.
Why it's wrong here
Hardcoding sensitive connection strings directly within application code is a significant security vulnerability. This practice exposes credentials to anyone with access to the source code repository, potentially through accidental commits or repository breaches. Furthermore, it complicates credential rotation, as any change to the connection string necessitates a code modification, recompilation, and redeployment of the entire application, increasing operational overhead and risk.
- ✓
Use a system-assigned managed identity with RBAC role 'Storage Queue Data Contributor' on the queue.
Why this is correct
A system-assigned managed identity provides an automatically managed identity for the Azure App Service within Azure Active Directory. This identity can then be granted specific Azure Role-Based Access Control (RBAC) roles, such as 'Storage Queue Data Contributor', directly on the target Azure Storage Queue. This approach eliminates the need for developers to manage or store any connection strings or secrets in the application code or configuration, as Azure AD handles the authentication and authorization securely.
- ✗
Use an environment variable in the App Service configuration.
Why it's wrong here
While using environment variables in App Service configuration is a common practice for application settings, it is not considered secure for highly sensitive credentials like storage connection strings. Environment variables are visible in the Azure Portal, via Azure CLI, and through ARM templates to anyone with contributor access to the App Service. This exposure means that sensitive data is not adequately protected against unauthorized viewing, making it a less secure option than managed identities or properly secured Key Vault secrets.
- ✗
Store the connection string in Azure Key Vault and retrieve it at runtime using Key Vault references.
Why it's wrong here
Storing secrets in Azure Key Vault is a robust security practice, and Key Vault references in App Service simplify retrieval. However, this method still requires the App Service to authenticate to Azure Key Vault to retrieve the connection string. This authentication is typically achieved using a managed identity for the App Service, which then fetches the secret. Since the Azure Storage Queue itself supports Azure AD authentication and RBAC, directly assigning a managed identity to the App Service and granting it permissions on the queue is a more streamlined and direct security model, avoiding the extra hop through Key Vault for the connection string itself.
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
Azure Functions Development
Key term
Managed identity
A managed identity is an automatically managed service principal in Azure that allows your code to authenticate to any service that supports Azure AD authentication without storing credentials.
Key term
Key Vault Secrets
Key Vault Secrets are secure containers in Microsoft Azure that store sensitive information like passwords, connection strings, and API keys, keeping them encrypted and accessible only to authorized applications and users.
About these practice questions
One of 881 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.