gcloud project, region, and zone defaults: stop deploying to the wrong place

Not specified by the original author.

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.

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):

• CLOUDSDKCOREPROJECT
• CLOUDSDKCOMPUTEREGION
• CLOUDSDKCOMPUTEZONE

The pattern is CLOUDSDKSECTIONNAMEPROPERTYNAME, uppercased. Env vars beat config file values for that invocation.

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.

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

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.