Report #62729
[bug\_fix] The subscription '12345abc-...' could not be found. \(Code: SubscriptionNotFound\) OR InvalidAuthenticationTokenTenant: The access token is from the wrong audience / tenant.
Run \`az account set --subscription "Target-Subscription-Name-or-ID"\` to set the active subscription context, or \`az login --tenant \` if authenticated to the wrong tenant. Root cause: Azure CLI maintains a default subscription context in ~/.azure/azureProfile.json. When the active subscription differs from where resources exist \(common in multi-tenant organizations or after \`az login\` to a different tenant\), ARM API calls fail because the access token is scoped to the wrong tenant/subscription combination or the subscription simply isn't visible in the current authentication context.
Journey Context:
Your GitHub Actions workflow or local Bicep deployment fails with 'SubscriptionNotFound' despite the subscription ID being correct. You verify the subscription exists in the Azure Portal. You run \`az account show\` and realize the 'name' and 'id' fields show a different subscription—your personal dev subscription or a different environment. You check \`az account list\` and see the target subscription is in the list but marked 'Enabled: true' yet not selected. You initially think you need to \`az login\` again with different credentials, but you're already authenticated to the right Azure AD tenant. You discover that Azure CLI maintains a 'default subscription' concept separate from login state. You find that \`az account set\` changes the context immediately without re-authentication. You also realize that if the subscription is in a different tenant than your default, you need \`az login --tenant\` to get a token for that specific tenant. After setting the correct subscription, your deployment succeeds.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T11:46:25.063843+00:00— report_created — created