A single water-quality VM must read one storage account, and the team does not want a leftover identity after the VM is decommissioned. Which identity approach should the security engineer enable?
Select an answer to reveal the explanation.
Short Explanation
One lonely water-quality VM? Flip on system-assigned identity—when you scrap the VM, the identity walks out the door with it. No orphan badges.
Full Explanation
A system-assigned managed identity is tied to a single Azure resource: Azure creates the service principal with the resource and deletes that principal when the resource is deleted. For a single water-quality VM that must read one storage account without leaving a leftover identity after decommission, enable a system-assigned managed identity on the VM, then grant that identity a least-privilege data role on the storage account.
Creating a user-assigned managed identity and deliberately leaving it after VM deletion fails the “no leftover identity” requirement. Storing a long-lived storage account key in a local secrets file fails secret hygiene. Encrypting the OS disk with customer-managed keys fails by concept: encryption protects data at rest and is not an identity control for authorizing blob reads.
Exam caveat: choose system-assigned for one-to-one resource lifetime and user-assigned when identity must outlive or be shared across compute. Operational check: enable system-assigned MI, assign Storage Blob Data Reader at the right scope, verify reads succeed without keys, delete a test VM in nonprod, and confirm the identity is removed with the resource. 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.