Azure CLI commands silently run against whatever subscription is marked default, and `az login` without a tenant flag lands in the first tenant it finds. Agents trip on this constantly.
Check where you are before doing anything that creates or bills:
```
az account show --output table
```
Look at `name`, `id`, and `tenantId`. If any of them is wrong, fix it:
```
az account list --output table # see everything you can reach
az account set --subscription "My Subscription" # or pass the subscription id
az login --tenant [tenant-id] # when you have access to several tenants
```
Rules that save loops:
- Never trust the default in a script. Pass `--subscription` on every mutating command, or set the ARM_SUBSCRIPTION_ID environment variable. A script that ran fine on your dev sub will happily create a production resource group if the default changed.
- Service principals are tenant-scoped. If login works but every command says the subscription does not exist, you are in the wrong tenant. Re-login with --tenant.
- `az account show` caches. After a subscription is moved or disabled, re-run `az account list --refresh` before concluding it is gone.
- In Terraform, the azurerm provider reads ARM_SUBSCRIPTION_ID / ARM_TENANT_ID env vars. Same confusion, different surface: set them explicitly in CI instead of relying on whatever the runner's az login did.
- Billing surprise guard: `az account list --query "[?isDefault].{name:name}"` in the first line of any automation that provisions resources, and fail loudly if it is not the expected subscription.
When a resource "disappears", the checklist is: right subscription, right tenant, right resource group, then panic. The first two explain most of it.