A quaking-bog path API uses the Azure SDK on a developer laptop (interactive login) and in Azure (managed identity) without #if AZURE secret forks. Which credential pattern supports that?
Select an answer to reveal the explanation.
Short Explanation
DefaultAzureCredential is the Swiss Army knife: Visual Studio or az login on the laptop, managed identity in Azure, one code path. No #if AZURE secret spaghetti and no password in App Configuration.
Full Explanation
DefaultAzureCredential (and the documented Azure.Identity chain) tries multiple sources in order so the same quaking-bog path API code can use interactive developer login on a laptop and managed identity in Azure without #if AZURE secret forks. Locally it may use Visual Studio, Azure CLI, or brokered credentials; in Azure it prefers the managed identity endpoint. One SecretClient or Blob client construction path serves both environments.
Hard-coding a client secret for every environment and ignoring Azure.Identity recreates secret distribution and the conditional compilation mess the question wants to avoid. Storing the developer's password in App Configuration for reuse in production fails security and platform design—passwords are not app settings, and production must not authenticate as a person. Using only SharedKeyCredential for Key Vault and Blob in all environments fails Key Vault entirely (Key Vault is AAD/RBAC oriented) and keeps account keys in play for Storage when MI is available.
Exam caveat: credential chain order and exclude flags matter in locked-down CI; know how to disable interactive credentials in automation so builds do not hang waiting for a browser. Operational check: run the API on a developer machine signed in with az login, then deploy to App Service with MI only, and confirm both paths retrieve the same Key Vault secret without compiling different credential types.