You are developing an ASP.NET Core web API hosted on Azure App Service. The API needs to read secrets from Azure Key Vault at startup. You have enabled a system-assigned managed identity for the App Service. Which code should you use to create the Key Vault SecretClient?
DefaultAzureCredential attempts to authenticate using the environment's managed identity (among others). In an App Service with system-assigned managed identity, it will use that identity.
Why this answer
Option A is correct because `DefaultAzureCredential` automatically attempts to authenticate using the environment's managed identity when running on Azure App Service. Since a system-assigned managed identity is enabled, `DefaultAzureCredential` will chain through available credential sources and successfully use the managed identity endpoint to obtain a token for Key Vault, without requiring any explicit tenant ID, client ID, or secret.
Exam trap
The trap here is that candidates often choose `ClientSecretCredential` (Option B) because they are accustomed to using service principals with secrets, forgetting that managed identities eliminate the need for any hardcoded credentials.
How to eliminate wrong answers
Option B is wrong because `ClientSecretCredential` requires a client secret, which defeats the purpose of using a managed identity—it introduces a secret that must be stored and rotated, increasing security risk. Option C is wrong because `ChainedTokenCredential` is not a concrete credential class; it is a base class for building custom credential chains, and cannot be instantiated directly with `new`. Option D is wrong because `InteractiveBrowserCredential` is designed for interactive user authentication via a browser, which is not suitable for a server-side, unattended startup scenario in Azure App Service.