a0deploy error forbidden tenant is in another region bug

Not specified by the original author.

TL;DR

Either request a quota increase for the model in that region, or deploy to a different region: azd env set AZUREAIDEPLOYMENTS_LOCATION [new-region] followed by azd up. Check current usage first with az cognitiveservices usage list --location [region], and list available models per region with az cognitiveservices model list --location [region] before retrying.

The error

Bicep deployment fails with model quota or region capacity error

Fix

1. Either request a quota increase for the model in that region, or deploy to a different region: azd env set AZUREAIDEPLOYMENTS_LOCATION [new-region] followed by azd up. Expected: You get the expected result; the problem is gone.

2. Re-run the original operation and confirm the error is gone. Expected: no error, normal output.

When to use

• You hit this exact error with Azure AI Foundry.
• The symptom matches: Bicep deployment fails with model quota or region capacity error.

When NOT to use

• A different error message from Azure AI Foundry; the cause here is specific to this error.
• Unrelated Azure AI Foundry issues (different feature, different failure).
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported against Azure AI Foundry. Source: https://github.com/microsoft/microsoft-iq-solution-accelerator/blob/HEAD/docs/foundry/DeploymentGuideFoundry.md.

Variant phrasings

Bicep deployment fails with model quota or region capacity error

Why it happens

Deploying an Azure AI Foundry project with azd fails when the Bicep template requests model deployments (e.g. gpt-5-mini at 150K TPM) that exceed the target region's quota or capacity. The deployment errors out on quota even though the template is valid.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/microsoft/microsoft-iq-solution-accelerator/blob/HEAD/docs/foundry/DeploymentGuideFoundry.md

Source: Deploying an Azure AI Foundry project with azd fails when the Bicep template requests model deployments (e.g. gpt-5-mini at 150K TPM) that exceed the target region's quota or capacity. The deployment errors out on quota even though the template is valid.

Verified resolution: [Microsoft solution accelerator deployment guide]: Either request a quota increase for the model in that region, or deploy to a different region: azd env set AZUREAIDEPLOYMENTS_LOCATION [new-region] followed by azd up. Check current usage first with az cognitiveservices usage list --location [region], and list available models per region with az cognitiveservices model list --location [region] before retrying.

Source URL: https://github.com/microsoft/microsoft-iq-solution-accelerator/blob/HEAD/docs/foundry/DeploymentGuideFoundry.md

Not specified by the original author.

TL;DR

Pass --subscription on every mutating command, or set the ARM\SUBSCRIPTION\ID environment variable. 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.

Steps

1. 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.
2. Check where you are before doing anything that creates or bills:

az account show --output table

3. 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

4. Rules that save loops:
5. - Never trust the default in a script. Pass --subscription on every mutating command, or set the ARMSUBSCRIPTIONID 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 ARMSUBSCRIPTIONID / ARMTENANTID 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.

6. When a resource "disappears", the checklist is: right subscription, right tenant, right resource group, then panic. The first two explain most of it.

When to use

You are seeing this: Agents trip on this constantly. Use this skill when you run into "Azure: set the right subscription and tenant before you create anything".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Proactive skill. Context rules verified against the Azure CLI authentication docs. Evidence: https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli

Not specified by the original author.

TL;DR

Set them: ` gcloud config set project [YOUR-PROJECT-ID] gcloud config set compute/region [YOUR-REGION] gcloud config set compute/zone [YOUR-ZONE] Inspect: gcloud config list Env var overrides (useful in scripts and CI, no config file touched): - CLOUDSDK\CORE\PROJECT - CLOUDSDK\COMPUTE\REGION - CLOUDSDK\COMPUTE\ZONE The pattern is CLOUDSDK\SECTION\NAME\PROPERTY\NAME, uppercased.

Steps

1. Every gcloud command that takes --project, --region, or --zone falls back to your config properties. Wrong defaults mean resources in the wrong project or region, which is painful to undo.

gcloud config set project [YOUR-PROJECT-ID]
gcloud config set compute/region [YOUR-REGION]
gcloud config set compute/zone [YOUR-ZONE]

gcloud config list

2. Env var overrides (useful in scripts and CI, no config file touched):

• CLOUDSDKCOREPROJECT
• CLOUDSDKCOMPUTEREGION
• CLOUDSDKCOMPUTEZONE

3. The pattern is CLOUDSDKSECTIONNAMEPROPERTYNAME, uppercased. Env vars beat config file values for that invocation.
4. Notes agents get wrong:

• gcloud config set project sets core/project. There is no separate command; the section prefix matters for region and zone (compute/region, compute/zone).
• The active config is per-installation, not per-shell. gcloud config configurations list shows them; CI runners often inherit a config you did not expect, so prefer explicit --project flags or env vars in automation.
• BigQuery and some other tools do not read compute/region; they take location per job or dataset. Do not assume the gcloud region default applies to BigQuery queries.
• Quota and billing follow the project, not the region. Deploying to the wrong project can also mean the wrong billing account.

5. Verification: after setting, run gcloud config list and confirm core/project, compute/region, compute/zone before any create or deploy command.

When to use

You are seeing this: Every gcloud command that takes --project, --region, or --zone falls back to your config properties. Use this skill when you run into "gcloud project, region, and zone defaults: stop deploying to the wrong place".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified 2026-09-26 on the gcloud properties docs: config set syntax, section prefixes, and the CLOUDSDKSECTIONNAMEPROPERTYNAME env var pattern with the CLOUDSDKCOREPROJECT / CLOUDSDKCOMPUTEZONE examples. Agents routinely deploy to wrong projects because they assume flags they never passed have safe defaults.