TL;DR: DefaultAzureCredential tries a chain of credential sources and every one failed in your environment. Give it something to work with: log in with az login for local dev, or set AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET in CI.

```text
azure.identity.exceptions.CredentialUnavailableError: DefaultAzureCredential failed to retrieve a token from the included credentials.
```

## Fix it

1. Read the full exception; it lists each chained credential and why it failed. That tells you which source to fix.
2. Local dev: run az login, then retry your code. Expected: the AzureCliCredential in the chain succeeds.
3. CI or servers: set the AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET env vars for a service principal. Expected: EnvironmentCredential succeeds.
4. On Azure VMs, App Service, or Functions: enable managed identity for the resource instead of secrets. Expected: ManagedIdentityCredential succeeds.

## When this applies
- The error is CredentialUnavailableError from DefaultAzureCredential.
- It works on one machine but not another (environment difference).

## When it doesn't
- You get a 401/403 from the storage or management API: the token was acquired fine; the identity lacks permission (RBAC).
- The import itself fails: that is a packaging problem, not this.

## Compatibility
- azure-identity >= 1.2. Azure CLI 2.x for the az login path.

## Why it happens
DefaultAzureCredential is a chain: environment, managed identity, VS Code, Azure CLI, and more. It only raises this after trying all of them, so the message is really saying your environment offers no credential at all.

## Edge cases
- Exclude noisy sources to get a clearer error: DefaultAzureCredential(exclude_cli_credential=True) etc.
- In Docker, az login state lives in ~/.azure; mount it or log in during build.
- ChainedTokenCredential lets you build a custom chain when the default order is wrong for you.