AZ-204 · Question #413
Drag and Drop Question You are developing a serverless Java application on Azure. You create a new Azure Key Vault to work with secrets from a new Azure Functions application. The application must…
The correct answer is Create the Azure Functions app with a Consumption plan type.; Create a system-assigned managed identity for the application.; Create an access policy in Azure Key Vault for the application identity. Explanation of Azure Functions + Key Vault Access Question --- Quick Requirements Mapping | Requirement | Implies | |---|---| | No code changes for Key Vault references | Key Vault references via app settings | | Dynamic scaling based on events | Event-driven plan | |…
Question
Exhibit
Answer Area
Drag items
Correct arrangement
- Create the Azure Functions app with a Consumption plan type.
- Create a system-assigned managed identity for the application.
- Create an access policy in Azure Key Vault for the application identity.
Explanation
Explanation of Azure Functions + Key Vault Access Question
Quick Requirements Mapping
| Requirement | Implies |
|---|---|
| No code changes for Key Vault references | Key Vault references via app settings |
| Dynamic scaling based on events | Event-driven plan |
| Perpetually warm, no cold starts | Pre-warmed instances |
| VNet connectivity | VNet integration support |
| Identity deleted when app is deleted | System-assigned managed identity |
Step-by-Step Breakdown
Step 1: Create the Azure Functions app with a Consumption Premium plan type
Important: The provided "correct" answer for Step 1 appears to be wrong. The stated requirements explicitly require:
- No cold starts ("perpetually warm") - Consumption plan cannot guarantee this; it is the defining weakness of Consumption. Premium plan has Always Ready / pre-warmed instances.
- VNet connectivity - Consumption plan has very limited VNet support. Premium plan provides full VNet integration.
The technically correct answer for Step 1 is Premium plan. Consumption plan violates two of the stated requirements directly.
Step 2: Create a system-assigned managed identity
This is correct and the reasoning is precise:
- A system-assigned identity is tied to the lifecycle of the Azure Function app. When the app is deleted, the identity is automatically deleted - satisfying the requirement "Authentication to Key Vault must be removed if the Function app is deleted."
- A user-assigned identity is a standalone resource with an independent lifecycle. It would persist after the Function app is deleted, violating the requirement.
- The identity also enables Key Vault references in app settings (e.g.,
@Microsoft.KeyVault(SecretUri=...)) - satisfying the "no code changes" requirement.
Step 3: Create an access policy in Azure Key Vault for the application identity
- This grants the Function app's managed identity permission to read secrets from Key Vault.
- An SSL certificate (wrong distractor) is used for TLS/HTTPS, not for granting access to secrets.
- The access policy must come after the identity exists - you need the identity's object ID to create the policy.
Common Mistakes & Misconceptions
| Mistake | Why It's Wrong |
|---|---|
| Choosing user-assigned identity | It survives app deletion - fails the cleanup requirement |
| Choosing Consumption plan for "no cold starts" | Consumption plan is the source of cold starts, not the solution |
| Choosing SSL certificate instead of access policy | SSL certs handle transport security, not Key Vault authorization |
| Reversing steps 2 and 3 | You can't create an access policy for an identity that doesn't exist yet |
Summary
The correct sequence is: provision the right Function plan -> establish a lifecycle-bound identity -> grant that identity Key Vault access. Each step is a prerequisite for the next, and the identity type choice is the most discriminating decision in the question.
Topics
Community Discussion
No community discussion yet for this question.