A heather-honey coop pasted the storage account key into appsettings.json checked into source control. How should the developer construct the Azure Blob Storage v12 client instead?
Select an answer to reveal the explanation.
Short Explanation
Keys in source are like leaving the warehouse master key under the doormat in a public photo. Prefer DefaultAzureCredential / TokenCredential, or pull a connection string from Key Vault or another secret store—not from git.
Full Explanation
Blob clients should be constructed with credentials that are not committed to source control. Prefer DefaultAzureCredential (or another TokenCredential) for Microsoft Entra ID authentication with RBAC on the storage account, or load a connection string / account key from a secret store such as Azure Key Vault, App Configuration with Key Vault references, or environment variables injected at deploy time. The heather-honey coop’s pasted account key in appsettings.json checked into source is exactly the anti-pattern to eliminate: rotate the exposed key, remove it from git history where feasible, and rebuild the v12 client using managed identity or secret-backed configuration.
Keeping the account key in source and rotating only when a PR review fails fails because secrets in repositories are already compromised once pushed; rotation gated on review misses the continuous exposure and does not establish a secure client construction pattern.
Hard-coding a never-expiring SAS as a public class constant fails least privilege and secret hygiene. Long-lived SAS tokens are difficult to revoke cleanly if not backed by a stored access policy, and embedding them in code duplicates the same leakage problem as account keys.
Using QueueClient with the account key so Blob uploads inherit security fails because QueueClient does not authenticate Blob uploads; each service client needs appropriate credentials for its data plane. Sharing an account key across the wrong client type does not “inherit” Blob security.
Exam caveat: DefaultAzureCredential’s chain differs across local dev versus Azure hosts—test the identity that will run in production (managed identity) and grant Storage Blob Data roles, not only management-plane access. Operational check: remove the key from appsettings, run with DefaultAzureCredential or a Key Vault–backed secret, and successfully list or upload against the account; confirm no account keys remain in the repository.