Domain 5 of 6 · Chapter 2 of 2

Programmatic Access

Four ways to reach Google Cloud, one decision

A PCA question rarely asks "how do I run a command"; it asks which way of touching Google Cloud fits a requirement. Picture three stems from the case studies: a Cymbal engineer needs to check one bucket's settings right now, an Altostrat service needs to publish messages to Pub/Sub at runtime, and an EHR Healthcare platform team needs to recreate an entire environment identically in a second region. Those are three different answers, and naming the work names the tool.

The methods sit on one spectrum, from interactive and one-off to repeatable and declarative. At the interactive end is Cloud Shell, an in-browser environment where, as Google puts it, "the Google Cloud CLI and other utilities you need are pre-installed, fully authenticated, up-to-date, and always available"[1]; it gives you a Terminal plus a built-in Editor with an integrated Cloud Code experience, backed by a 5 GB persistent home directory. Next is the gcloud command-line interface (CLI) for imperative commands and scripts. Then the Cloud Client Libraries, the per-language software development kits (SDKs) an application uses to call Google APIs at runtime. At the declarative end is Infrastructure as Code (IaC), where you write down the desired end state and a tool makes the project match it.

The governing rule is to climb toward the declarative end as the requirement gets more repeatable. A throwaway lookup stays imperative (Cloud Shell or gcloud). Anything that must be reproducible, peer-reviewed, or rebuilt on demand belongs in IaC. The sections below take each rung in turn: the gcloud CLI and its tools, the client libraries and how they authenticate, the three IaC options on GCP, and the local emulators that let you develop against a service without the real one. Each term here gets its full treatment where it is introduced; this page walks them as one connected toolchain so a single workload's choices fit together.

Interactive, one-offRepeatable, declarativeCloud Shell + Cloud Codebrowser terminal and editor, preinstalled gcloudgcloud CLI (gcloud, gsutil, bq)imperative commands and scriptsCloud Client Librariesapp code calls APIs at runtimeInfrastructure as Codedeclare desired state, apply idempotently
The four programmatic-access methods ordered from interactive one-off work to repeatable declarative infrastructure.

The gcloud CLI: gcloud, gsutil, bq, and gcloud storage

The Google Cloud CLI is the set of command-line tools that create and manage resources from a terminal, and Google describes the SDK as bundling the "command-line tools (gcloud, gsutil, and bq)"[2]. Each owns a surface: gcloud is the general-purpose tool for almost every service, gsutil is the original Cloud Storage tool, and bq is the BigQuery tool. The first exam reflex is to map the verb in the stem to the tool, then to the current recommended command.

gcloud storage has superseded gsutil

The one currency change to internalize: for Cloud Storage, prefer gcloud storage over gsutil. Google states plainly that "gsutil is not the recommended CLI for Cloud Storage"[3] and that you "should use gcloud storage commands instead of gsutil commands," because gsutil is "a legacy Cloud Storage CLI and minimally maintained" that "does not support working with newer Cloud Storage features, such as soft delete and managed folders." So a recent question that offers both gsutil cp and gcloud storage cp wants the latter. The name gsutil looks like the canonical storage tool, but it is the legacy one; gcloud storage is the successor, and gsutil still appears in older material only because it is not yet removed.

Configurations and authentication

gcloud groups settings into named configurations (the active project, region, and account) so you can switch context with gcloud config configurations activate. Two auth commands look similar but do different jobs, and confusing them is a classic trap. gcloud auth login authenticates the gcloud tool itself as you. gcloud auth application-default login writes a separate local credential file that Application Default Credentials reads, so your locally-run application code can authenticate; it does not change which account gcloud uses. The next section covers ADC in full, since the client libraries depend on it.

# Quick imperative task: create a bucket and copy an object
gcloud storage buckets create gs://my-bucket --location=europe-west1
gcloud storage cp ./report.csv gs://my-bucket/

# Set up credentials for locally-run application code
gcloud auth application-default login

Client libraries and Application Default Credentials

When application code calls a Google API, it uses a Cloud Client Library, and Google states that "Cloud Client Libraries are the recommended option for accessing Cloud APIs programmatically, where available"[4]. They are the modern successor to the older Google API Client Libraries: the Cloud libraries give idiomatic, per-language code and support gRPC, while the legacy Google API Client Libraries "provide access to the API's REST interface only; gRPC is not supported." When a question contrasts the two, the Cloud Client Libraries are the right answer unless a service offers only the legacy library.

One auth strategy under every library

The libraries do not each invent authentication. They resolve credentials through Application Default Credentials (ADC), which Google defines as "a strategy used by the authentication libraries to automatically find credentials based on the application environment"[5]. The same code authenticates on a laptop and in production with no change, because ADC looks in the same fixed order everywhere.

That order, shown above, is: first the GOOGLE_APPLICATION_CREDENTIALS environment variable if set (it points to a credential file); then the credentials written by gcloud auth application-default login; then the service account attached to the running resource, read from the metadata server. Note one subtlety the docs call out directly, so you do not misread the list as a ranking: "The order of the locations ADC checks for credentials is not related to the relative merit of each location." Position 1 is checked first, but it is not the recommended source.

The architectural rule: attach a service account, do not ship a key

For code running on Google Cloud, the right answer is almost always the third location. Google states that "using the credentials from the attached service account is the preferred method for finding credentials," and it warns that service account keys are "discouraged due to security risks." So a workload on GKE, Cloud Run, or Compute Engine should run as an attached service account and let ADC find it through the metadata server, with no downloaded key file anywhere. A stem that proposes exporting a JSON key and setting GOOGLE_APPLICATION_CREDENTIALS on an in-cloud workload is the trap; that pattern exists for the rarer off-Google case, not as the default. On a developer laptop, gcloud auth application-default login (location 2) gives the same keyless result locally.

1. GOOGLE_APPLICATION_CREDENTIALS env var?points to a key/config file2. gcloud ADCapplication-default login3. Attached serviceaccountvia metadata servernonoPreferred on Google Cloud: attached service accountno key file to manage or leakfound
ADC search order: env var, then gcloud user credentials, then the attached service account via the metadata server (Google authentication docs).

Infrastructure as Code: Terraform, Infrastructure Manager, Config Connector

Infrastructure as Code means describing the desired infrastructure in configuration files a tool applies, instead of clicking a console or running imperative commands. The declarative property is the whole point: you state the end result and the tool computes and applies the diff, so reapplying the same configuration is idempotent and the files become the version-controlled, reviewable source of truth. GCP offers three IaC tools, and the exam separates them by where the workflow already lives, not by capability.

Terraform

Terraform is the standalone, third-party tool and the default IaC answer for GCP. Google calls it "the most commonly used tool to provision and automate Google Cloud infrastructure"[6]. You write HashiCorp Configuration Language (HCL) in .tf files; the google and google-beta providers translate that into Google Cloud API calls (the google-beta provider exists to "provision and manage Google Cloud beta APIs"). The core loop is terraform plan to preview the diff, then terraform apply to converge, which produces a state file that "keeps track of all resources in a deployment." Because that state is the system of record, a team should store it in a shared remote backend such as a Cloud Storage bucket rather than on one laptop, so concurrent runs do not corrupt it.

Infrastructure Manager

Infrastructure Manager is Google's own managed Terraform service, "a managed service that simplifies and automates the deployment and management of your Google Cloud infrastructure resources"[7] using "Terraform configurations (also called blueprints)." You still write Terraform HCL, but Google runs it for you in "an ephemeral Cloud Build environment" that is discarded after use, and it stores the state file as part of each revision. The practical difference from plain Terraform is operational: you skip running your own state backend and execution runner, and you gain native IAM and revision history. Choose it when you want Terraform but not the chore of operating it.

Config Connector

Config Connector takes declarative management into Kubernetes. It is an "open source Kubernetes add-on that lets you manage Google Cloud resources through Kubernetes"[8], implemented as "a collection of Kubernetes Custom Resource Definitions (CRDs) and controllers." You define a Cloud SQL instance or a bucket as a Kubernetes object in YAML (the Kubernetes Resource Model, KRM) and apply it with kubectl; a controller in the cluster reconciles the real Google Cloud resource to match, continuously, with no separate .tfstate file. It fits a team that already runs GKE and wants one control plane and one toolchain for both applications and infrastructure. The trade-off is that it presumes a Kubernetes cluster to host the controllers, so it is overhead for a team with no GKE footprint.

Terraformwrite HCL .tf filesgoogle provider to APIsyou run a state backendInfrastructure Managersame Terraform HCLruns in Cloud Buildstate stored for youConfig ConnectorKubernetes YAML (KRM)CRDs and controllersreconciled in a cluster
Three IaC tools as separate families: Terraform you run yourself, Infrastructure Manager as managed Terraform, Config Connector inside Kubernetes.

Local emulators and exam-pattern recognition

Local emulators let you develop and test against a Google Cloud data service without provisioning the billed, network-backed instance. The gcloud CLI ships them, and the gcloud beta emulators command group[9] covers Bigtable, Datastore, Firestore, Pub/Sub, and Spanner. You start one locally, point your client library at it (typically by an environment variable the library reads), and your code runs offline against a local stand-in. The value is fast iteration, zero cost, and deterministic integration tests in CI; the limit, and the trap, is that an emulator approximates the service and is not a release gate. Validate against the real API before shipping, because an emulator can miss quotas, IAM behavior, and edge cases the live service enforces.

Network patterns: which access method

PCA programmatic-access questions are scenario-shaped, so match the requirement keyword to the method. "Reproducible, version-controlled, peer-reviewed infrastructure" or "rebuild this environment identically" points to Infrastructure as Code, not a gcloud script. "We already run everything through GKE and want one control plane for infrastructure too" points to Config Connector over plain Terraform. "We want Terraform but not to manage the state backend or a runner" points to Infrastructure Manager. "A quick one-off check or a small script" points to the gcloud CLI, and for Cloud Storage specifically that means gcloud storage, not the legacy gsutil.

Auth patterns

"Application running on Compute Engine, GKE, or Cloud Run needs to call a Google API" points to an attached service account resolved through ADC and the metadata server, never a downloaded key. "Developer needs to run the app locally against real services" points to gcloud auth application-default login, which sets up keyless local ADC. A stem that hands you a JSON service account key to copy onto an in-cloud VM is the distractor: it is the discouraged path that exists for workloads outside Google Cloud, and the secure answer removes the key entirely.

Library and emulator patterns

"Build an application that calls Google APIs" points to the Cloud Client Libraries, the recommended SDK, over the legacy Google API Client Libraries, which only reach the REST interface. "Test against Pub/Sub or Firestore in CI without incurring cost or flakiness" points to the local emulator for that service, with the caveat that final validation still runs against the real API.

Infrastructure as Code on GCP: which tool when

DimensionTerraformInfrastructure ManagerConfig Connector
What it isStandalone IaC tool (HCL)Managed Terraform serviceKubernetes add-on (CRDs)
Config languageHCL (.tf files)HCL (Terraform blueprints)Kubernetes YAML (KRM)
Where it runsWherever you run terraformEphemeral Cloud Build envControllers in a GKE/K8s cluster
State managementYou run a backend (e.g. GCS)Stored for you per revisionReconciled continuously, no .tfstate
Best fitStandalone, portable IaCWant Terraform fully managedKubernetes is already the control plane

Decision tree

Repeatable, reviewableinfrastructure?noyes (use IaC)App code calling APIsat runtime?noyesgcloud CLIone-off / scriptsCloud ClientLibrariesGKE is already yourcontrol plane?yesnoConfig Connectorresources as K8s CRDsWant Terraform managed(no backend to run)?noyesTerraformHCL, you run the backendInfrastructure Managermanaged Terraform on Cloud BuildAlways authenticate via ADC: attach a service account on Google Cloud, never ship a downloaded key
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Reach for IaC when infrastructure must be repeatable and reviewable, not gcloud scripts

When a requirement stresses reproducibility, peer review, drift detection, or rebuilding an environment identically, the answer is Infrastructure as Code (IaC), where you declare the desired end state and a tool converges to it idempotently. An imperative gcloud command or shell script performs a single action and can fail or duplicate on rerun, so it fits a throwaway task, not a managed environment. The deciding keywords are version-controlled, reproducible, and rebuild-from-scratch.

Trap Reaching for a gcloud shell script to stand up infrastructure that must be reproducible and reviewed; an imperative script is not idempotent and is not the version-controlled source of truth IaC gives you.

Declarative IaC is idempotent; imperative tools are not

IaC is declarative: you describe the end state once and the tool computes the diff, so applying the same configuration twice changes nothing the second time. A gcloud command or client-library call is imperative, performing one action when run, which is why rerunning it can create duplicates or error. This idempotence is the property questions point at when they ask which approach safely converges an environment to a known state.

Prefer gcloud storage over the legacy gsutil for Cloud Storage

For Cloud Storage from the command line, use gcloud storage, not gsutil. Google states gsutil is not the recommended CLI: it is a legacy, minimally-maintained tool that does not support newer features like soft delete and managed folders, while gcloud storage is the successor and needs less manual tuning for fast transfers. When a question offers both gsutil cp and gcloud storage cp, the modern recommended choice is gcloud storage.

Trap Picking gsutil because its name looks like the canonical storage tool; it is the legacy CLI, and gcloud storage is what Google now recommends.

The gcloud CLI bundles gcloud, gsutil, and bq

The Google Cloud CLI ships three command-line tools: gcloud for almost every service, gsutil as the original Cloud Storage tool, and bq for BigQuery. Mapping the service in the stem to its tool is the first step, then choosing the current recommended command (for storage, gcloud storage rather than gsutil).

gcloud auth login and gcloud auth application-default login do different jobs

gcloud auth login authenticates the gcloud tool itself as you, for running gcloud commands. gcloud auth application-default login instead writes a local Application Default Credentials (ADC) file that your locally-run application code reads, and it does not change which account gcloud uses. Use the application-default variant when the goal is to let code on your laptop authenticate to Google APIs without a key file.

Trap Running gcloud auth login expecting your application code to pick up the credentials; that only authenticates the gcloud tool, while application code needs gcloud auth application-default login to populate ADC.

ADC is the one auth strategy every client library uses

Application Default Credentials (ADC) is the strategy the authentication libraries use to find credentials automatically from the environment, so the same application code authenticates unchanged on a laptop and in production. Cloud Client Libraries resolve credentials through ADC rather than each inventing its own scheme, which is why you configure auth once via the environment, not per-service.

3 questions test this
Know the ADC search order, and that order is not a ranking

ADC checks three locations in a fixed sequence: the GOOGLE_APPLICATION_CREDENTIALS environment variable, then the credentials from gcloud auth application-default login, then the service account attached to the running resource via the metadata server. Google explicitly notes the order is not related to the relative merit of each location, so being checked first does not make the env var the recommended source. The first hit wins, but the preferred source for in-cloud code is the attached service account.

Trap Reading the search order as a quality ranking and treating GOOGLE_APPLICATION_CREDENTIALS as the recommended source because ADC checks it first; the docs say order is unrelated to merit.

On Google Cloud, attach a service account instead of shipping a key file

For code running on Google Cloud (GKE, Cloud Run, Compute Engine), attach a service account and let ADC find it through the metadata server; Google calls this the preferred method for finding credentials. Downloaded service account keys are discouraged because of the security risk of a leaked long-lived credential, so they are a fallback for the rarer off-Google case, not the default. The keyless attached-service-account pattern removes any key to manage or rotate.

Trap Exporting a JSON service account key and setting GOOGLE_APPLICATION_CREDENTIALS on an in-cloud workload; that ships a leakable long-lived key when the attached service account would authenticate with none.

7 questions test this

For application code calling Google APIs, use the Cloud Client Libraries, which Google recommends where available: they are idiomatic per language and support gRPC. The older Google API Client Libraries provide access to the REST interface only, with no gRPC, and are auto-generated rather than idiomatic. Choose the legacy library only when a service offers no Cloud Client Library.

Trap Defaulting to the Google API Client Libraries; they are the legacy REST-only option, and Cloud Client Libraries are the recommended, gRPC-capable choice where available.

2 questions test this
Terraform is the default standalone IaC tool for Google Cloud

Terraform, Google's most commonly used provisioning tool, is the default IaC answer when the workflow is standalone and portable. You write HashiCorp Configuration Language (HCL) in .tf files, and the google and google-beta providers translate it to Google Cloud API calls (google-beta exists for beta APIs). The loop is terraform plan to preview the diff, then terraform apply to converge, producing a state file that tracks every resource.

Store Terraform state in a shared remote backend, not on a laptop

Terraform's state file is the system of record mapping configuration to real resources, so a team must store it in a shared remote backend such as a Cloud Storage bucket rather than locally. A local-only state file blocks collaboration and risks corruption when two engineers apply concurrently, because each would work from a divergent copy of the truth.

Trap Leaving Terraform state on one engineer's machine for a team project; concurrent applies then race on divergent state and can corrupt or drift the deployment.

15 questions test this
Config Connector manages Google Cloud resources as Kubernetes objects

Config Connector is a Kubernetes add-on, a set of Custom Resource Definitions (CRDs) and controllers, that lets you define Google Cloud resources as Kubernetes objects in YAML (the Kubernetes Resource Model) and apply them with kubectl, with a controller continuously reconciling the real resource to match. It fits a team already running GKE that wants one control plane for apps and infrastructure, but it presumes a cluster to host the controllers, so it is overhead for a team with no Kubernetes footprint.

Trap Adopting Config Connector for IaC with no existing GKE footprint; you then run a cluster solely to host its controllers, overhead that Terraform or Infrastructure Manager avoids.

Local emulators let you develop offline but are not a release gate

The gcloud beta emulators command group ships local emulators for Bigtable, Datastore, Firestore, Pub/Sub, and Spanner, so you can build and run integration tests offline against a local stand-in with no cost or network. The limit, and the trap, is that an emulator approximates the service and can miss quotas, IAM behavior, and edge cases, so final validation must still run against the real API before release.

Trap Treating an emulator as proof the integration works in production; it approximates the service, so behaviors and limits the live API enforces can be absent.

Cloud Shell comes preinstalled, authenticated, and with a persistent home directory

Cloud Shell is a browser-based environment where the gcloud CLI and common utilities are pre-installed, fully authenticated, and up to date, backed by a 5 GB persistent home directory that survives across sessions. It pairs a Terminal with a built-in Editor that has an integrated Cloud Code experience, so it suits quick interactive work or learning without any local setup.

Cloud Code adds IDE support for Kubernetes and Cloud Run apps

Cloud Code provides IDE support across VS Code, IntelliJ, and the Cloud Shell Editor for the full development cycle of Kubernetes and Cloud Run applications, with run-ready samples, configuration snippets, advanced Kubernetes YAML support, and a Gemini Code Assist extension. It targets developers building and deploying container workloads, distinct from gcloud (commands) and the client libraries (runtime API access).

Authenticate external CI/CD with Workload Identity Federation, not service account keys

When an external workload (GitHub Actions, GitLab, Jenkins, Terraform Cloud, on-prem CI/CD) must act as a Google Cloud service account without downloaded keys, use Workload Identity Federation: the external identity provider's OIDC/SAML token is exchanged for short-lived Google Cloud credentials that impersonate the service account. This eliminates long-lived key files and is the recommended pattern for workloads running outside Google Cloud.

Trap Attaching a service account covers workloads running on Google Cloud; external/off-Google-Cloud systems use Workload Identity Federation instead.

6 questions test this
Share outputs between Terraform configurations via terraform_remote_state

When one Terraform configuration (e.g. networking) must expose values like VPC and subnet IDs to another configuration (e.g. application) managed separately, have the producing config declare those values as outputs in its root module and store state in a remote backend such as Cloud Storage. The consuming config reads them with the terraform_remote_state data source pointing at that backend. This is Google's recommended way to reference another root module's outputs.

Trap Reading or copying another team's state file directly to share its values, instead of exposing them as outputs consumed through the terraform_remote_state data source.

7 questions test this
Use google_*_iam_member to avoid Terraform IAM drift

google_project_iam_member (and the matching _iam_member resources) add individual bindings additively without touching other roles. google_project_iam_policy is authoritative: it overwrites the entire IAM policy, removing roles that Google Cloud services manage automatically, which makes Terraform show constant IAM changes (drift) on every plan. Prefer the non-authoritative _iam_member resources for adding bindings.

Trap _iam_policy is authoritative and overwrites everything (causing drift); _iam_member is additive and only manages the binding you declare.

1 question tests this

Also tested in

References

  1. Cloud Shell documentation
  2. gcloud CLI overview (Google Cloud SDK)
  3. gsutil tool (legacy Cloud Storage CLI)
  4. Client libraries explained
  5. Application Default Credentials (ADC)
  6. Terraform on Google Cloud overview
  7. Infrastructure Manager overview
  8. Config Connector overview
  9. gcloud beta emulators reference