A grain-elevator API registration still uses a two-year client secret pasted into a Function app setting. What credential approach should the security engineer prefer on the app registration?
Select an answer to reveal the explanation.
Short Explanation
A two-year secret living in an app setting is a long-lived spare key under the doormat. Prefer a certificate on the app registration—and if a secret must linger, make its remaining life short while you migrate.
Full Explanation
App registrations support password (client secret) and certificate credentials. Prefer certificates (or federated credentials / managed identity patterns where applicable) over long-lived pasted secrets. For the grain-elevator API registration whose two-year client secret sits in a Function app setting, prefer a certificate credential on the app registration and keep any remaining secret lifetime short if a temporary secret must still exist during migration.
Lengthening the client secret to maximum lifetime in plain text beside Function code fails credential hygiene. Replacing Entra credentials with a storage account access key shared across APIs fails by swapping one secret problem for a broader data-plane key problem and does not authenticate to Entra as the app. Disabling the password blade and hoping Functions bindings invent tokens fails—bindings still need a sound identity strategy such as managed identity or a certificate-backed app registration.
Exam caveat: AZ-500 favors reducing client secrets; managed identities remove secrets entirely when the caller is an Azure resource calling Azure APIs. Operational check: add a certificate credential, update the Function to use it (or preferably a managed identity when suitable), disable or remove the old secret after cutover, and alert on credential expiry before the next grain season.