AZ-204 Implement Azure security Practice Question
You are developing a serverless application using Azure Functions that processes sensitive data. The function needs to access Azure Key Vault to retrieve a secret. You want to use managed identity for authentication. What should you do first?
⚠ Common exam trap
Many candidates confuse which resource gets the managed identity (the function app) versus where permissions are assigned (the Key Vault), leading them to incorrectly enable the identity on the Key Vault itself.
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 the system-assigned managed identity on the function app and grant it the Key Vault Secrets User role.
To use managed identity for authentication with Azure Key Vault, the first step is to enable a system-assigned managed identity on the function app, which creates an identity in Azure AD tied to the resource. Then, you must grant that identity the appropriate role (e.g., Key Vault Secrets User) on the Key Vault to authorize secret retrieval. This eliminates the need for storing credentials in code or configuration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enable the system-assigned managed identity on the function app and grant it the Key Vault Secrets User role.
Why this is correct
Enabling a system-assigned managed identity on the Azure Function App automatically provisions a unique identity in Azure Active Directory, intrinsically linked to the function's lifecycle. Granting this identity the 'Key Vault Secrets User' role provides the necessary Azure Role-Based Access Control (RBAC) permissions for the function to securely retrieve secrets from Key Vault. This robust pattern eliminates the need for developers to manage credentials in code or configuration, significantly enhancing security and simplifying secret rotation.
- ✗
Enable the system-assigned managed identity on the Key Vault.
Why it's wrong here
Managed identities are designed for Azure resources (clients) to authenticate to other Azure services (servers/providers) without managing credentials. Key Vault itself is a service that securely stores and provides secrets; it does not require a managed identity to authenticate to other services to perform its core function. Therefore, enabling a managed identity directly on Key Vault is conceptually incorrect, as Key Vault is the target service, not the client requiring authentication.
- ✗
Store the client ID and client secret of a service principal in the function app settings.
Why it's wrong here
While storing a service principal's client ID and client secret in application settings is a functional method for authentication, it introduces significant security and operational overhead. This approach requires manual management, secure storage, and regular rotation of the secret, increasing the risk of exposure and potential downtime if secrets expire. Managed identities are specifically designed to abstract away this credential management, making this a less secure and less efficient practice compared to using managed identities.
- ✗
Create a user-assigned managed identity and assign it to the Key Vault.
Why it's wrong here
User-assigned managed identities are indeed flexible and can be assigned to multiple resources, but they must be assigned to the *consuming* resource, which is the Azure Function App in this scenario. Assigning a managed identity directly to Key Vault is fundamentally incorrect because Key Vault is the service providing secrets, not a client consuming them via an identity. The identity needs to be associated with the resource that *needs* to authenticate to Key Vault to access its contents.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
Learn chapter
Azure Functions Development
Key term
Durable Functions
Durable Functions is an extension of Azure Functions that lets you write stateful workflows in code, managing complex sequences of tasks, retries, and delays automatically.
Key term
Azure Functions Bindings
Azure Functions Bindings are declarative connections that link your serverless function code to Azure services or external resources, handling input and output data automatically without writing extra networking or authentication code.
About these practice questions
This AZ-204 question is part of Courseiva's 881-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.