AZ-204 Implement Azure security Practice Question
You are a developer for a fintech company. Your application consists of multiple Azure Functions that process sensitive financial transactions. The functions need to access an Azure SQL Database and an Azure Storage account. Security requirements are: (1) No secrets or connection strings should be stored in application settings or code. (2) Access must be restricted to the specific resources each function needs. (3) All access must be audited. (4) The solution must support local development debugging. You have already enabled system-assigned managed identity for each function app. Which course of action should you take to meet the requirements?
⚠ Common exam trap
A common mix-up: candidates think Key Vault references or SDK retrieval are acceptable for 'no secrets in code,' but the requirement explicitly forbids storing secrets in application settings or code, and Key Vault references still inject secrets into settings, while SDK retrieval still handles secret values in code.
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
✓
Grant each function app's system-assigned managed identity access to Azure SQL Database using Microsoft Entra authentication (create contained user) and to Azure Storage using RBAC (Storage Blob Data Contributor role). Enable auditing on SQL and Storage. For local development, use Azure CLI to sign in with your developer account and assign it the same RBAC roles.
It uses the system-assigned managed identity to directly authenticate to Azure SQL Database via Microsoft Entra authentication (creating a contained database user mapped to the identity) and to Azure Storage via RBAC (assigning the Storage Blob Data Contributor role). This meets the requirement of no secrets or connection strings in code or settings, restricts access to only the needed resources, enables auditing on both SQL and Storage, and supports local development by using Azure CLI to sign in with a developer account assigned the same RBAC roles.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Assign a user-assigned managed identity to each function app. Grant the identity access to Azure SQL via Microsoft Entra authentication and to Storage via RBAC. Use service principal for local development.
Why it's wrong here
Assigning a user-assigned managed identity deviates from the existing system-assigned setup and, crucially, using a service principal for local development fails to meet the "no secrets" requirement. Service principals typically necessitate storing client secrets or certificates locally, which contradicts the security mandate. User-assigned managed identities are beneficial when multiple resources require the same identity or when an identity's lifecycle needs to be independent of a single resource, offering centralised management for shared access patterns.
- ✗
Use the system-assigned managed identity to access Key Vault, where you store the SQL connection string and storage account key. Use the Key Vault SDK in the function code to retrieve them. Enable Key Vault audit logging.
Why it's wrong here
This option proposes storing SQL connection strings and storage account keys in Azure Key Vault and retrieving them programmatically using the Key Vault SDK. While leveraging a system-assigned managed identity to access Key Vault is a secure practice for Key Vault access itself, the fundamental issue is that secrets are still being stored and then retrieved by the application. This approach does not eliminate the existence of secrets within the overall solution, violating a strict "no secrets" requirement for the application's operational model, as the application code still handles these sensitive values after retrieval.
- ✗
Store the SQL connection string and storage account key in Azure Key Vault. Use Key Vault references in function app settings to retrieve them at runtime. Enable Key Vault audit logging.
Why it's wrong here
This option suggests storing secrets in Azure Key Vault and using Key Vault references within function app settings. Although Key Vault references abstract the secret retrieval process, making it appear as an environment variable to the function app, the underlying problem persists: the SQL connection string and storage account key are still secrets stored in Key Vault. This method does not achieve a truly "secretless" architecture because the solution still relies on the existence and management of these sensitive credentials, even if the application code doesn't explicitly call the Key Vault SDK.
- ✓
Grant each function app's system-assigned managed identity access to Azure SQL Database using Microsoft Entra authentication (create contained user) and to Azure Storage using RBAC (Storage Blob Data Contributor role). Enable auditing on SQL and Storage. For local development, use Azure CLI to sign in with your developer account and assign it the same RBAC roles.
Why this is correct
This correct option implements a truly secretless authentication model by directly granting the function app's system-assigned managed identity permissions to the target resources. For Azure SQL Database, this involves creating a contained user for the managed identity within the database, enabling Microsoft Entra authentication without connection strings. For Azure Storage, it uses Azure RBAC to assign the 'Storage Blob Data Contributor' role. This eliminates the need for any secrets to be stored or retrieved by the application or in Key Vault, and the local development strategy using Azure CLI with developer accounts maintains this secretless approach.
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
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.
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.
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.