An oxbow-lake sampler Azure Function should have an identity that appears and disappears with the Function app itself. Which identity type fits?
Select an answer to reveal the explanation.
Short Explanation
System-assigned is born with the Function and dies with it—one identity glued to that host. User-assigned is the reusable badge you attach to many hosts and keep after a delete.
Full Explanation
A system-assigned managed identity is created with the host and deleted when the host is deleted. For the oxbow-lake sampler Azure Function that should carry an identity matching the Function app's lifecycle, system-assigned is the fit: enable identity on the Function, grant that principal access to downstream resources, and accept that deleting the Function removes the identity. No separate identity resource remains to clean up.
A user-assigned identity that must be deleted manually after every Function purge describes the reusable identity pattern, not the lifecycle-tied one—user-assigned survives host deletion by design. A shared username and password in Blob metadata is not a managed identity at all and fails modern Azure auth guidance. An API Management subscription key reused as the Function's identity confuses APIM product keys with Azure AD resource identities; subscription keys authorize callers to APIs, they do not make the Function an Entra principal for Key Vault.
Exam caveat: choose user-assigned when many hosts must share one principal; choose system-assigned when one host owns one disposable identity. Operational check: enable system-assigned on a test Function, note the principal in Entra, delete the Function app, and confirm the identity disappears rather than lingering like a user-assigned resource.