A financial services company deploys an internal application that calls a Foundry-hosted model from an Azure Function running in the same tenant. Their security team is concerned about API keys being accidentally committed to source control or leaked in logs. What authentication approach should they use for the Azure Function to call the Foundry endpoint?
Select an answer to reveal the explanation.
Short Explanation
The real fix is to stop having a secret to leak. Give the Azure Function its own identity in Microsoft Entra ID and let the Foundry endpoint trust that identity directly, so there's no key sitting in code or config waiting to be checked into source control or printed into a log.
Full Explanation
Assigning the Azure Function a managed identity lets it authenticate to the Foundry endpoint through Microsoft Entra ID without any secret ever being stored in code, configuration, or logs, directly removing the leak risk the security team raised. Storing the API key in the Azure Function's application code as a hardcoded string is incorrect because hardcoding the API key in the application source is the exact practice that creates the risk of the key being committed to source control or exposed in logs. Rotating the API key manually every day is incorrect because it reduces how long a leaked key stays valid, but the key still exists as a secret that must be stored and transmitted somewhere, so it does not remove the underlying leak risk the way eliminating the key does. Disabling content filtering on the deployment so requests process faster and reduce log volume is incorrect because it has nothing to do with authentication; it would only remove a safety control on the model's output while leaving the original credential-management problem completely unaddressed.