Study guide
9.3 CLI Configurations, Local ADC, and Cloud Shell
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
9.3 CLI Configurations, Local ADC, and Cloud Shell
Key Takeaways Explain This Topic AI
gcloud named configurations select CLI properties; they do not rewrite local ADC.
Service-account impersonation can avoid downloaded private keys when configured for the intended client.
Keep persistent Shell work in its documented home storage; preview and idle limits are separate settings.
Last updated: October 2026
Local Development Environments, Cloud Workstations & Cloud Code
Modern cloud-native development requires a fast, reproducible "inner loop"—the iterative cycle of writing code, building containers, running local integration tests, and debugging before committing changes to version control. On Google Cloud, building applications efficiently requires mastering the Google Cloud CLI ( gcloud ) , leveraging browser-based developer environments ( Cloud Shell and Cloud Workstations ), and utilizing container workflow tools ( Cloud Code and Skaffold ).
Google Cloud CLI ( gcloud ) Management & Authorization Deep Dive
The gcloud CLI is the primary command-line tool for provisioning, managing, and automating Google Cloud resources. For professional cloud developers, understanding its multi-account configuration mechanics, authorization boundaries, and programmatic output formatting is essential.
Named Configurations and Multi-Project Switching
Developers frequently work across multiple Google Cloud projects (e.g., development, staging, production) and different corporate or personal Google identities. Rather than repeatedly overriding project flags or re-authenticating, gcloud provides named configurations : ## Create a new configuration for the staging environment
gcloud config configurations create order-service-staging
- ## Set the active identity, GCP project, and default compute region
- gcloud config set account developer@company.com
- gcloud config set project order-service-staging-4281
- gcloud config set compute/region us-central1
- ## Switch between configurations instantly
- gcloud config configurations activate order-service-dev
- gcloud config configurations activate order-service-staging
- ## List all existing configurations and view the currently active profile
- gcloud config configurations list
- Environment Variable Overrides
When running automated scripts, CI/CD jobs, or terminal sessions that must temporarily target an alternate project without mutating the persistent global gcloud state, use environment variables:
CLOUDSDK_CORE_PROJECT : Overrides the active GCP project ID.
CLOUDSDK_ACTIVE_CONFIG_NAME : Specifies which named configuration to activate for the current shell session.
CLOUDSDK_COMPUTE_REGION : Overrides the default Compute Engine/Cloud Run region.
Authorization Architecture: CLI Login vs. Application Default Credentials (ADC)
A critical exam concept and frequent developer stumbling block is the distinction between authorizing the gcloud CLI tool and authorizing application code:
Authorization Mechanism Command Credential Storage Location Primary Consumer
gcloud User Auth gcloud auth login ~/.config/gcloud/credentials.db (SQLite) gcloud CLI commands ( gcloud run deploy , gcloud storage ls )
Application Default Credentials (ADC) gcloud auth application-default login ~/.config/gcloud/application_default_credentials.json Google Cloud Client Libraries ( @google-cloud/* , google-cloud-* )
Service Account Key File Set GOOGLE_APPLICATION_CREDENTIALS Absolute path to downloaded .json key Local code explicitly simulating a specific Service Account
Service Account Impersonation gcloud config set auth/impersonate_service_account Ephemeral OAuth2 tokens retrieved via IAM API CLI calls; ADC impersonation is configured separately
Exam Trap: Running gcloud auth login authenticates the gcloud tool itself. If a developer subsequently runs a Node.js, Python, Java, or Go application locally that uses official Google Cloud client libraries, ADC can fail if no other valid credential source exists. To authorize local application code to access cloud APIs using the developer's identity, the developer must run gcloud auth application-default login .
Service Account Impersonation for Local Development
Downloading long-lived JSON service account keys onto developer laptops creates severe security and exfiltration risks. The Google Cloud recommended practice for local development requiring service account privileges is IAM Service Account Impersonation : ## Grant the developer the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator)
## on the target service account:
- gcloud iam service-accounts add-iam-policy-binding backend-sa@my-project.iam.gserviceaccount.com \
- -member="user:developer@company.com" \
- -role="roles/iam.serviceAccountTokenCreator"
## Configure gcloud to automatically impersonate the service account for all subsequent actions:
gcloud config set auth/impersonate_service_account backend-sa@my-project.iam.gserviceaccount.com
## Generate ADC credentials that automatically impersonate the service account:
gcloud auth application-default login --impersonate-service-account=backend-sa@my-project.iam.gserviceaccount.com
Token Generation for Authenticated Testing
When testing private Cloud Run services or Cloud Functions protected by IAM, developers must send an OpenID Connect (OIDC) ID token in the HTTP Authorization header: ## Generate an OIDC ID token for an authenticated Cloud Run endpoint
- curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
- https://private-order-service-xyz.a.run.app/api/v1/orders
- ## Print an OAuth2 access token for Google Cloud REST APIs
- curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
- https://storage.googleapis.com/storage/v1/b/my-app-bucket/o
- Programmatic Output Formatting ( --format ) and Filtering ( --filter )
In automation and shell pipelines, developers should never parse raw human-readable CLI tables. The gcloud CLI provides powerful client-side formatting and server-side filtering: ## Filter Cloud Run services deployed in us-central1 that are in ready status
## and output only their live HTTPS URLs as unadorned text:
- gcloud run services list \
- -filter="region:us-central1 AND status.conditions[0].status=True" \
- -format="value(status.url)"
## Extract the internal IP address of a specific Compute Engine VM instance:
- gcloud compute instances list \
- -filter="name=order-worker-*" \
- -format="value(networkInterfaces[0].networkIP)"
## Output resource metadata as clean, parseable JSON or YAML:
- gcloud secrets versions describe latest --secret=db-password --format="json"
- Google Cloud Shell: Architecture & Inner-Loop Capabilities
Google Cloud Shell is an interactive, browser-accessible Debian Linux development environment hosted directly within Google Cloud. It eliminates the "works on my machine" friction by providing a standardized, pre-configured development toolchain accessible from any modern web browser.
Cloud Shell Architecture and Storage Guarantees
Compute Instance: Each user receives an ephemeral Compute Engine VM provisioned on demand. The root filesystem ( / ) is ephemeral; when the ephemeral VM is recycled or the session reaches its idle/session limits, the underlying VM is discarded and any changes made outside the home directory are lost.
Persistent Storage: Cloud Shell allocates 5GB of persistent storage mounted at $HOME . This directory is preserved across sessions and VM restarts. Code, Git repositories, dotfiles ( .bashrc ), and developer tools installed into $HOME persist indefinitely (provided the user accesses Cloud Shell at least once every 120 days).
Built-in Authorization: Cloud Shell is automatically authenticated with the Google credentials used to log into the Google Cloud Console. Both the gcloud CLI and Application Default Credentials (ADC) are pre-configured without requiring gcloud auth login .
Pre-installed Tooling: Includes Docker, gcloud , kubectl , terraform , Helm, Skaffold, Minikube, Git, and major language runtimes (Go, Python, Java, Node.js, .NET).
Web Preview Proxy: Provides a built-in HTTP proxy that securely tunnels ports (8080 by default; supported preview ports are documented by Cloud Shell) from the Cloud Shell VM to the user's browser over HTTPS, allowing immediate testing of web servers and microservices.
Cloud Shell Editor: A full-featured browser IDE based on Theia / VS Code, containing native Git integration, a terminal multiplexer, and the pre-installed Cloud Code extension.
Official references checked October 18, 2026: Google Cloud 1 .