A Cloud Operations Engineer manages administrative operations across development, staging, and production Google Cloud projects from a centralized management instance. The engineer runs bash scripts that utilize the gcloud CLI to query and manage cloud resources. Currently, switching between environments relies on globally updating the default project using 'gcloud config set project <PROJECT_ID>', which recently resulted in a staging configuration script executing against the production environment. Which approach should the engineer adopt to prevent cross-environment misconfigurations during programmatic gcloud CLI executions?
- Create named gcloud configurations for each environment and activate them as needed, or override the active configuration per script execution using the CLOUDSDK_CORE_PROJECT environment variable.Answer
- BHardcode dedicated service account JSON keys into each environment's script files to enforce authentication to specific projects.
- CAssign the primitive Owner role to the management instance service account across all projects to bypass project-level configuration scoping.
- DMaintain local unversioned state files for each environment on the local instance and manually copy the active configuration prior to running scripts.
Answer
Create named gcloud configurations for each environment and activate them as needed, or override the active configuration per script execution using the CLOUDSDK_CORE_PROJECT environment variable.
The correct option leverages native gcloud CLI configuration management mechanisms. Named configurations ('gcloud config configurations create') allow storing separate defaults for account, project, and region across different deployment environments. In automated scripts, setting the CLOUDSDK_CORE_PROJECT environment variable or specifying the --project flag provides explicit, non-destructive scoping per execution.
Step-by-Step Solution
Key Concept
gcloud CLI Named Configurations and Environment Variable Overrides