A puffin-burrow census site still hashes passwords in Cosmos DB for municipal staff sign-in. What should the developer do instead for user authentication?

Municipal staff authentication should use Microsoft Entra ID through the Microsoft identity platform (MSAL, OpenID Connect/OAuth 2.0). Entra provides credential protection, MFA integration, Conditional Access hooks, token-based API authorization, and centralized offboarding—none of which a homemade Cosmos password-hash table supplies safely. The puffin-burrow census site should redirect staff to Entra sign-in and accept Entra-issued tokens for the app session.

Keeping Cosmos password hashes and adding a Blob Storage SAS as a second factor fails because SAS is a Storage authorization artifact, not a user authenticator. You still own password storage, reset, and breach response, and SAS does not prove staff identity to the application.

Replacing passwords with unsigned API keys in Application Insights fails because Application Insights is a telemetry service, not an identity provider. Unsigned keys in logs or configuration are forgeable secrets and do not provide user-level authentication or directory integration.

Authenticating only with Queue Storage message visibility timeouts fails because visibility timeouts control competing consumers of a message; they are not proof of who a person is. Queues do not replace interactive sign-in or token validation for a staff portal.

Exam caveat: AZ-204 expects you to prefer platform identity over custom credential stores. External ID or workforce tenants may differ by scenario, but “hash passwords in Cosmos” is not the modern answer for Microsoft-hosted municipal apps.

Operational check: register the census app in Entra, configure redirect URIs, sign in a test staff account with MSAL, and confirm the app receives a valid ID token (and access tokens for any APIs). Disable or remove the Cosmos password path so there is no dual-auth bypass.