A cormorant-roost daemon still ships a client secret in source control to authenticate to Microsoft Entra ID. What credential approach should the developer prefer?
Select an answer to reveal the explanation.
Short Explanation
Secrets in the repo are a spill waiting to happen. Prefer a certificate on the app registration—or a managed identity when Azure is already hosting the daemon.
Full Explanation
Prefer certificate credentials on the Entra app registration, or a managed identity when the cormorant-roost daemon already runs on Azure (App Service, Functions, VM with identity, Container Apps, and similar). Certificates avoid long-lived shared secrets in source control; managed identities remove app secrets from your code entirely by letting Azure federate the host identity to Entra.
Committing a longer client secret and rotating every decade fails because length does not fix repository leakage, and decade-scale rotation is far too slow after exposure. Secrets in git history remain compromised until rotated and purged from use.
Placing the client secret in a public GitHub gist fails outright: public gists are world-readable, which guarantees credential theft.
Disabling app authentication and calling Entra anonymously fails because Entra token endpoints for protected APIs require an authenticated confidential client or managed identity. Anonymous calls cannot obtain application permissions for the city APIs the daemon needs.
Exam caveat: if you must use a client secret temporarily, store it in Key Vault or platform secret stores—not source control—and rotate on a short schedule. For AZ-204, managed identity or certificate is the preferred durable answer.
Operational check: remove secrets from the repo, configure a certificate or enable system/user-assigned managed identity, grant the identity or app the required Graph/API permissions, and confirm token acquisition succeeds without reading a client secret from configuration files.