A code reviewer inspecting an internal application notices that the connection string used to call a Foundry-hosted model deployment includes an API key hard-coded directly in the application's source file, which is stored in a shared repository. The application runs on an Azure VM inside the company's tenant. Which change would most improve the security of this authentication approach?
Select an answer to reveal the explanation.
Short Explanation
Finding a live API key sitting in a shared repository is really a sign that the whole authentication approach needs rethinking, not that the key needs to be handled a little more carefully. Rotating it on a schedule shrinks the window during which a leaked copy would work, but the key is still sitting there in the code the entire time between rotations, so anyone with repository access still has it. Sticking it in a comment does not hide it, it just makes it easier to spot, which is the opposite of helpful. Locking the whole file behind a password only one person knows just breaks the file for everyone else on the team without actually getting rid of the secret. The move that actually solves the underlying problem is getting rid of the hard-coded secret entirely and letting the virtual machine prove who it is using an identity that Azure issues and manages on its behalf, so there is simply nothing sitting in the code for someone to steal in the first place.
Full Explanation
The correct answer is A. Replacing the hard-coded API key with Microsoft Entra ID authentication through a managed identity removes the secret from source code entirely; the VM authenticates using an identity issued and managed by Azure, so there is no long-lived credential sitting in a shared repository for anyone with read access to copy. Option B is incorrect because moving the key into a comment does not remove it from the source file at all, it simply makes an already-exposed secret more visible and easier for anyone browsing the repository to find and misuse. Option C is incorrect because encrypting the file with a password known only to one developer breaks the ability of the rest of the team to build, run, or review the application, and it does not eliminate the underlying problem of a static secret; anyone with the password still has full access to the same hard-coded key. Option D is incorrect because rotating the key on a schedule reduces how long a leaked key stays valid, but the key still lives in the source file and shared repository the whole time between rotations, leaving the same exposure risk in place until the next rotation. Managed identity removes the secret from the codebase altogether rather than managing it more carefully.