If you work with more than one GCP project, you have probably typed gcloud config set project more times than you can count. gcloud configurations solve this problem by letting you define named sets of properties, including the project ID, default region, and default zone, that you can activate with a single command. The Associate Cloud Engineer exam tests whether you know this feature exists and how to use it.
A gcloud configuration is a named collection of properties that gcloud uses when running commands. The most important properties are the active project, the default compute zone, and the default compute region. When you activate a configuration, all subsequent gcloud commands use those properties as defaults unless you override them with explicit flags.
The default configuration is called default, and it is created automatically when you run gcloud init. Every property you set with gcloud config set without specifying a configuration modifies the active configuration, which is default unless you have switched to another one.
Creating a configuration requires one command:
gcloud config configurations create stagingThis creates a new empty configuration named staging and makes it the active configuration. From this point, any properties you set go into staging rather than default.
Setting the project and compute defaults for this configuration:
gcloud config set project my-staging-project-id
gcloud config set compute/zone us-central1-a
gcloud config set compute/region us-central1These three commands define a complete environment for the staging project. Now any compute command you run will default to us-central1-a and target my-staging-project-id.
Activating a different configuration:
gcloud config configurations activate productionAfter this command, gcloud uses the properties from the production configuration for all subsequent commands. No need to re-enter the project ID, zone, or region. You switch contexts with a single command.
To see all configurations and which one is currently active:
gcloud config configurations listThis shows each configuration name, whether it is active, the account it uses, the project, and the default zone and region.
A team running a web application on GCP might have three environments: development, staging, and production, each in a separate GCP project. Without configurations, switching from development to production requires manually setting the project and potentially the region for each session.
With configurations, the setup is a one-time task. Create a dev configuration pointing at the development project, a staging configuration for staging, and a production configuration for production. When a developer needs to check something in production, they run gcloud config configurations activate production and every subsequent command targets the right project automatically.
Configurations can hold more properties than just project, zone, and region. You can store the active account (useful if you work with multiple Google accounts), proxy settings, and other gcloud behavioral settings. The most exam-relevant properties are project, compute/zone, and compute/region.
To check the current active properties:
gcloud config listThis shows all properties in the active configuration, which is useful for confirming you are targeting the right project before running a destructive operation.
The Associate Cloud Engineer exam tests configurations in scenarios involving multi-project management. A question might describe a developer who needs to work with both a production and a development project and ask how to configure gcloud to switch between them efficiently. The answer involves creating named configurations for each environment.
The exam also tests the command sequence: create a configuration, set properties for it, activate it. Knowing those three steps in order is enough for most configuration-related exam questions. The specific commands are gcloud config configurations create, gcloud config set, and gcloud config configurations activate.
My Associate Cloud Engineer course covers the full gcloud CLI setup and configuration workflow, including the scenarios where configurations appear alongside other multi-project management topics like resource hierarchy and IAM.
Named configurations set defaults, but you can override any property for a single command using flags. If your active configuration targets the staging project but you need to check one thing in production without switching contexts, add the --project flag:
gcloud compute instances list --project=my-production-project-idThis runs the command against the production project and returns to the staging context immediately after. No configuration switch required. The --zone and --region flags work the same way for location-scoped commands.
To see all the properties in your currently active configuration:
gcloud config listThe output shows the active account, project, compute zone, and compute region. Running this before a destructive operation is a good habit. Confirming you are in the staging project before deleting something is much easier than recovering after deleting it in production.
To see all configurations, not just the active one:
gcloud config configurations listThis shows each configuration with its properties and marks the currently active one. If you work across several environments regularly, this output helps you audit which environments you have configured and verify that each one points at the right project and region.
Some teams use environment variables like CLOUDSDK_CORE_PROJECT to set gcloud defaults in scripted or CI/CD environments. Environment variables take precedence over configuration file settings. In interactive developer workflows, named configurations are cleaner because they keep all settings in one place and make switching explicit. In automated pipelines, environment variables or explicit command flags are often more appropriate than named configurations because each pipeline run should be self-contained and not depend on a developer's local configuration state.
