Why prefer an SDK with Microsoft Entra authentication over raw keys for Azure services?
Why A is the answer
There are no long-lived secrets to manage
Token-based identity removes stored secrets and allows role-based access.
In detail
- Entra tokens are short-lived, so no long-lived secrets need managing.
- DefaultAzureCredential helps in both local and cloud use.
Use case
An illustrative scenario, not a real incident.
An app calls Azure services through an SDK with Microsoft Entra authentication, so there are no long-lived secrets to rotate.
See it in different ways
sequenceDiagram participant A as App with managed identity participant E as Microsoft Entra ID participant K as Key Vault A->>E: Request a token E-->>A: Token A->>K: Get secret K-->>A: Secret value
sequenceDiagram participant A as App participant C as App Configuration participant V as Key Vault A->>C: Reads settings and flags C-->>A: Key Vault reference A->>V: Reads the secret, with its managed identity V-->>A: Current value
sequenceDiagram participant P0 as App participant P1 as Microsoft Entra ID participant P2 as Azure service P0->>P1: Request a token P1-->>P0: Short-lived token P0->>P2: Call with the token
Key point: Entra authentication avoids long-lived secrets.
Why the other options are wrong
- B. SDK calls do not count toward service limits
- Service limits still apply.
- C. Entra authentication makes each request free
- Requests still cost the same.
- D. Keys cannot be used in any Azure service
- Keys can still be used in many services.