AZ-305 Practice Question 11: Shared Workload Identity
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 2 · question 1 of 10
A retailer runs a promotions platform made of a virtual machine scale set that autoscales between 20 and 200 instances during sales events, plus 12 Azure Function apps. Every instance and every function reads the same two secrets from one key vault and writes to the same storage account. The platform team sets these requirements:
- No credential may be stored in code, configuration, or a deployment pipeline variable. - Role assignments on the key vault and the storage account must exist before any compute instance is created, because the deployment pipeline account is not allowed to create role assignments. - Scaling out by 180 instances in a few minutes must not fail because of Microsoft Entra object creation limits. - Adding a third target resource later should require as few new role assignments as possible.
What should you include in the design?
Show answer and explanation
Answer:
A user-assigned managed identity is a standalone Microsoft Entra object whose lifecycle is independent of the resources that use it, and Microsoft's own guidance names exactly this shape of workload (replicated resources carrying out the same task) as the case for user-assigned rather than system-assigned. Because the identity exists first, its role assignments can be created in advance by an identity administrator, so the pipeline never needs permission to write role assignments. Deploying many instances that share one identity creates only one service principal, which avoids the Microsoft Entra object-creation rate limit (HTTP 429) that rapid system-assigned identity creation can hit. And a new target resource means one new role assignment, not one per instance.
Option A inverts every requirement. Each instance gets its own identity that cannot exist before the instance does, so the role assignment has to be created afterwards by a pipeline that is not allowed to create role assignments, and creating 180 identities in minutes is precisely the burst that trips the object-creation limit.
Option C reintroduces a credential. A client secret in a key vault is still a secret the application must authenticate to retrieve, it expires and must be rotated, and it can be copied out of a running host, which is the problem managed identities exist to remove.
Option D is the closest wrong answer, and it fails on timing rather than on concept. Group-based role assignments work, but a managed identity's group membership is carried as claims in a token that the platform caches for around 24 hours, so permission changes can take hours to take effect. Microsoft therefore recommends grouping resources under a shared user-assigned identity with permissions applied directly to the identity, rather than adding identities to a group. The system-assigned identities also still cannot be created ahead of the resources.
Reference: Best practice recommendations for managed identities