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):
- CLOUDSDK_CORE_PROJECT
- CLOUDSDK_COMPUTE_REGION
- CLOUDSDK_COMPUTE_ZONE
The pattern is CLOUDSDK_SECTION_NAME_PROPERTY_NAME, 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.