Examkin

Question

Difficulty: HardSystem-Assigned and User-Assigned Managed Identities

You are designing the security architecture for an enterprise Azure Function app that processes financial transactions. The app requires access to an Azure SQL Database and retrieves cryptographic keys from an Azure Key Vault. Due to strict CI/CD and compliance policies, the Function app is frequently torn down and recreated in different resource groups using automated Terraform scripts. You need to choose a managed identity configuration that ensures the application can authenticate to Azure SQL and Key Vault with the least administrative effort during deployment cycles, specifically avoiding the need to recreate database users or update Key Vault access policies after each deployment.

Which configuration should you implement?

  1. Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.Answer
  2. B
    Configure a system-assigned managed identity for the Function app, and grant it the required roles on the Azure SQL Database and Key Vault.
  3. C
    Configure a single system-assigned managed identity on the Azure Key Vault, and share its credentials with the Function app across all deployment resource groups.
  4. D
    Configure a user-assigned managed identity, assign it to the Function app, and rely on the default Azure RBAC Reader role at the subscription level to grant it access to the Key Vault secrets.

Answer

Configure a user-assigned managed identity as a standalone Azure resource, grant it the required roles on the Azure SQL Database and Key Vault, and assign this identity to the Function app during deployment.
A user-assigned managed identity exists as a standalone Azure resource with its own lifecycle. When the Azure Function app is deleted and recreated by Terraform, the user-assigned identity and its associated service principal object ID remain unchanged. Consequently, the permissions granted to the identity in the Azure SQL Database and Azure Key Vault persist across deployments, requiring only that the new Function app instance be associated with the existing identity.

Step-by-Step Solution

1
Analyze the resource lifecycle requirement.
The application infrastructure is ephemeral (frequently deleted and recreated via CI/CD), while the target systems (Azure SQL and Key Vault) are persistent.
Choosing a system-assigned identity would tie the identity's lifecycle to the ephemeral resource, causing credential loss and requiring constant manual reconfiguration.
2
Compare system-assigned and user-assigned managed identities.
A user-assigned managed identity is created as a standalone Azure resource. It survives the deletion of the associated Azure Function App.
To maintain persistent authorization in Key Vault and Azure SQL without updating permissions during deployments, the identity must have an independent lifecycle.
3
Verify authorization requirements.
The managed identity must have specific data plane permissions (e.g., Key Vault Secrets User, Azure SQL database roles) to retrieve keys and query data.
Generic management plane roles like Reader do not authorize data plane operations, so direct RBAC role assignments or access policies are required.

Key Concept

The lifecycle difference between System-Assigned and User-Assigned Managed Identities.
Estimated Time:2m 0s
Rate this question

Topics

System-Assigned and User-Assigned Managed Identities

More questions from this topic