A canal authority recycles VM scale-set instances weekly but needs the same identity and the same Azure role assignments to survive instance replacement. What should the security engineer create?
Select an answer to reveal the explanation.
Short Explanation
Scale-set instances come and go like canal barges. Hang one user-assigned identity on the fleet so the Azure roles stay put when the hulls get swapped.
Full Explanation
User-assigned managed identities are independent Azure resources that can be attached to multiple compute resources and keep the same principal and role assignments across instance replacement. For a canal authority that recycles VM scale-set instances weekly but needs the same identity and Azure role assignments to survive, create a user-assigned managed identity as a standalone resource and attach it to each compute resource that needs those shared roles.
A system-assigned managed identity on each instance fails survival: each new instance gets a new principal, so weekly recycling churns identities. Storing a new app registration password in each instance’s custom data reintroduces secrets managed identities exist to avoid. Assigning an Entra security group with Owner on the subscription to every recycled NIC fails by concept and massively over-privileges the platform.
Exam caveat: user-assigned MI is the scale-set and shared-identity pattern on AZ-500. Operational check: create the user-assigned identity, assign least-privilege Azure roles once, attach it to the scale set, recycle instances, and confirm the same principal still accesses target resources. In municipal Azure estates, document the decision in the change record, validate with a nonproduction rehearsal, and confirm monitoring still pages the on-call operator when the control fails closed during an incident drill.