A financial company deploys an Azure Function that calls a Foundry-hosted model to generate transaction summaries. A security review flags that the function's API key is stored as a plain application setting, creating risk if that setting is ever exposed. The team wants to remove the standing secret entirely while still letting the function call the model. What should they configure?
Select an answer to reveal the explanation.
Short Explanation
Storing an API key in a setting is like keeping a spare house key under the doormat: convenient, but anyone who finds the mat finds the key. Changing that key every week is still leaving a key under the mat, just a different key each time, and the risk of someone finding it never actually goes away. Writing it into a code comment or, worse, sending it down to every visitor's browser is like taping the key to the front door in plain sight. Managed identity solves the actual problem: it lets the function prove who it is to Microsoft Entra ID and get permission to call the model based on its own verified identity and an assigned role, so there is no physical key sitting anywhere for someone to find. That is the difference between hiding a secret better and removing the need for a secret entirely, which is what a security review flagging a standing key is really asking for.
Full Explanation
The correct answer is A. Enabling a managed identity lets the function authenticate to the Foundry endpoint using Microsoft Entra ID and an assigned Azure RBAC role, so no API key needs to exist in application settings, code, or configuration at all. This eliminates the standing secret the security review flagged, rather than just managing it more carefully. Option B is incorrect because rotating the key on a schedule still leaves a live secret sitting in application settings between rotations, which does not remove the underlying exposure risk the review identified. Option C is incorrect because moving the key into a code comment does not reduce exposure; source code is typically more widely accessible than application settings, especially in shared repositories, making this worse rather than better. Option D is incorrect because placing an API key in client-side JavaScript sends it to every end user's browser, making it trivially visible to anyone who inspects the page, a far more severe exposure than the original setting.