Managing implementation · Topic 3 of 3
Tools, SDKs, Emulators and Infrastructure as Code
Working with Google Cloud in code: Cloud Shell, Cloud Code, gcloud and bq, emulators, Terraform and Infrastructure Manager, client libraries.
- 4 min
- Cloud Shell for quick admin; Cloud Code for IDE development on GKE and Cloud Run; Cloud Workstations for managed private dev environments.
- gcloud, gcloud storage (replacing gsutil), bq, kubectl.
- Emulators for Pub/Sub, Spanner, Bigtable and Firestore; still test against real services.
What it is
Teams interact with Google Cloud through browser shells, IDE plugins, command-line tools, local emulators, infrastructure as code and client libraries. The exam asks which tool fits a task and how to use Google APIs safely and efficiently.
How it works
Cloud Shell, Cloud Shell Editor and Cloud Code
| Tool | What it is | Use |
|---|---|---|
| Cloud Shell (terminal) | A browser-based shell with the Google Cloud CLI and common tools preinstalled, plus a small persistent home directory | Quick administration from anywhere |
| Cloud Shell Editor | A browser IDE on top of Cloud Shell | Light editing without a local setup |
| Cloud Code | Plugins for VS Code and JetBrains IDEs | Develop, deploy and debug for GKE and Cloud Run; runs Skaffold for continuous development |
| Cloud Workstations | Managed development environments in your VPC | Source code stays off laptops; standard images for teams |
Cloud Shell is not attached to your VPC network. For development that must reach private systems, use Cloud Workstations in a private configuration.
Command-line tools
| Tool | For |
|---|---|
| gcloud | Most Google Cloud services: projects, IAM, compute, GKE, networking |
| gcloud storage | Cloud Storage operations; the recommended replacement for gsutil |
| bq | BigQuery: datasets, tables, queries, loads |
| kubectl | Kubernetes objects in GKE clusters |
Use configurations in gcloud to switch between projects and accounts, and service account impersonation for scripts that need elevated rights.
Emulators
Local emulators let developers and CI test without cloud resources or cost:
| Emulator | Notes |
|---|---|
| Pub/Sub | Topics and subscriptions locally |
| Spanner | Schema and queries locally |
| Bigtable | Tables and reads and writes locally |
| Firestore (and Datastore) | Documents and queries locally |
Client libraries switch to an emulator through environment variables such as PUBSUB_EMULATOR_HOST. Emulators do not reproduce every production behaviour (performance, IAM, quotas), so keep a staging test against real services.
Infrastructure as code
| Option | Notes |
|---|---|
| Terraform with the Google provider | The most common choice; plan, review, apply |
| Infrastructure Manager | Google-managed service that runs Terraform deployments, with previews, from Git or Cloud Storage |
| Config Connector | Manage Google Cloud resources as Kubernetes objects |
Practices: modules for reuse, remote state with locking, one state per environment, plans reviewed in pull requests, and drift detection.
Google API client libraries and best practices
- Cloud Client Libraries are the recommended, idiomatic libraries for each language; they handle authentication with Application Default Credentials, retries and pagination.
- Use Application Default Credentials so the same code runs locally (user credentials) and in the cloud (attached service account) without embedding keys.
- Respect quotas: back off exponentially on errors, batch requests where possible.
- Use resumable uploads for large Cloud Storage objects so interrupted transfers continue.
- Prefer event notifications (for example Cloud Storage notifications to Pub/Sub) over polling.
A worked scenario
Developers wait minutes for a pipeline to roll out each small change to a shared development cluster. They want edits running within seconds, from their IDE, with debugging. Cloud Code running Skaffold in continuous development mode syncs or rebuilds changes into the dev cluster and attaches a debugger; Cloud Build triggers and Cloud Deploy still pass every change through a full pipeline.
How the exam asks about this
- "Integration tests for Pub/Sub without cloud cost." The Pub/Sub emulator.
- "Google runs Terraform for us, with previews from Git." Infrastructure Manager.
- "No credentials in code, same code locally and on Cloud Run." Application Default Credentials.
What to remember for the exam
- Cloud Shell for quick admin; Cloud Code for IDE development on GKE and Cloud Run; Cloud Workstations for managed private dev environments.
- gcloud, gcloud storage (replacing gsutil), bq, kubectl.
- Emulators for Pub/Sub, Spanner, Bigtable and Firestore; still test against real services.
- Terraform, Infrastructure Manager and Config Connector for infrastructure as code.
- Client libraries with Application Default Credentials, backoff and resumable uploads.
Downloading service account keys for local development is unnecessary; use your own credentials with Application Default Credentials or impersonation.
Common mistakes
Cloud Shell to reach private VPC systems. It sits outside your network.
Testing only against emulators. Production behaviour differs.
Hand-run gcloud scripts as the system of record for infrastructure.
Check yourself
Which tool replaces gsutil for Cloud Storage commands?
gcloud storage.
How do client libraries find credentials without keys in code?
Application Default Credentials.
Which managed service runs Terraform deployments with previews?
Infrastructure Manager.
Topic 3 of 3 in Managing implementation
Test yourself on Managing implementation
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.