Terraform, Config Connector, and AI-Assisted Tooling on Google Cloud

Infrastructure as code exists because clicking through the console does not scale, does not review, and does not repeat. When your VPCs, subnets, GKE clusters, and IAM bindings are text in a repository, every change gets a diff, a code review, and a history; every environment — dev, staging, prod — is stamped from the same definitions instead of hand-rebuilt; and disaster recovery becomes running the code again rather than reconstructing tribal knowledge.

The distinction the exam cares about is declarative versus imperative. A gcloud script is imperative: it lists steps, and running it twice may fail or duplicate resources. A declarative tool takes a description of the desired end state — three subnets, this cluster, that firewall policy — computes the difference against what exists, and applies only that difference. Running it twice is safe, because the second run finds nothing to change. gcloud and the console remain the right tools for exploration, one-off inspection, and break-glass fixes; IaC is the right tool for anything you intend to keep.

The exam guide names four IaC tools for Google Cloud, and each occupies a distinct niche: Terraform as the general-purpose provisioning engine, Fabric FAST as an opinionated Terraform-based foundation for whole organizations, Config Connector for managing Google Cloud resources through the Kubernetes API, and Helm for packaging applications deployed to GKE. Knowing which niche a scenario is describing is most of the battle.

Terraform provisions Google Cloud resources through the Google provider — the plugin that translates resource blocks written in HashiCorp Configuration Language (HCL) into Google Cloud API calls. There are two flavors: the google provider for generally available features and the google-beta provider for preview features; both are maintained in partnership between Google and HashiCorp, and Terraform comes preinstalled in Cloud Shell, so you can practice without installing anything.

A minimal configuration declares the provider and a resource:

provider "google" {
  project = "my-project-id"
  region  = "us-central1"
}

resource "google_storage_bucket" "assets" {
  name          = "my-project-assets"
  location      = "US"
  force_destroy = false
}

Each resource block names a resource type and a local identifier, and its arguments mirror the underlying API. Resources reference each other by attribute — a subnet references its network, an instance references its subnet — and Terraform builds a dependency graph from those references so it creates and destroys things in the right order.

Modules: one definition, many instances

A module is a reusable package of Terraform configuration with input variables and outputs. When the same stack — a VPC, its subnets and firewall rules — is needed for every environment or product, write it once as a module and call it once per instance with different variables, instead of copying hundreds of lines and hand-editing names and CIDR ranges. Each module call has its own name, so its resources get their own addresses (module.product_a.google_compute_network.vpc); adding or removing one call never touches the others. That is why named module calls (or for_each over a map keyed by name) are preferred to count for long-lived stacks: count addresses instances by list position, so removing an item from the middle shifts every later index and Terraform plans changes to stacks you did not mean to touch.

You rarely need to start from nothing. Google publishes maintained Terraform modules and blueprints for common patterns — networks, GKE clusters, Cloud SQL, CMEK-encrypted buckets — that encode recommended settings so you supply only variables, and Cloud Foundation Fabric is a larger collection of composable modules. Fabric FAST, covered below, takes this philosophy to the scale of a whole organization.

The google provider authenticates through Application Default Credentials (ADC): it uses whatever credential the environment provides, so the same configuration runs on a workstation, in Cloud Build or in an external CI system without changes. The question is always which identity sits behind ADC, and the answer is never a long-lived service account key file if you can avoid it — keys are bearer secrets that leak through repositories and CI variables and must be rotated by hand.

Impersonation needs the right role on the target service account: Service Account Token Creator (roles/iam.serviceAccountTokenCreator), which allows minting short-lived access tokens for it. Service Account User is a different permission — it lets you attach a service account to a resource such as a VM or Cloud Run service, not obtain its tokens. Running as a dedicated deployer account means changes are made with the deployer's audited, scoped roles rather than with each engineer's personal permissions.

The Terraform workflow is a loop of four commands, and the exam expects you to know what each one does and in what order. terraform init prepares the working directory: it downloads the providers and modules the configuration requires, records provider versions in the dependency lock file, and configures the state backend. It is the first command in any new or freshly cloned configuration, and it must be rerun whenever providers, modules or the backend change — a teammate adding the google-beta provider means your next plan fails until you run init. terraform plan compares your configuration against recorded state and real infrastructure and prints exactly what would be created, changed or destroyed — without touching anything. terraform apply executes changes after a confirmation. terraform destroy tears down everything the configuration manages.

Several commands look like previews but are not:

Saved plans: approving exactly what will run

A plain terraform apply re-plans at the moment it runs. If other commits were merged or the infrastructure changed after someone reviewed a plan, the apply can do something different from what was approved. The fix is a saved plan: terraform plan -out=tfplan writes the proposed actions to a file, a reviewer approves that plan (terraform show tfplan renders it), and terraform apply tfplan executes exactly those actions without asking again. If state has changed since the plan was created, Terraform rejects the file as stale instead of applying it, so nothing unapproved slips through. In CI/CD this is the standard gate: a plan stage publishes the plan file as an artifact, a manual approval follows, and the apply stage consumes that artifact. Code review of the merge request is still valuable, but it reviews the configuration, not the concrete changes against today's infrastructure.

Read plans carefully for the word replace: some argument changes cannot be applied in place, so Terraform destroys and recreates the resource — fine for a firewall rule, catastrophic for a database with data in it. The next section covers how to stop such a change, and how to deal with resources that changed or were created outside Terraform.

Terraform only manages what its state records, and it only enforces the configuration when someone runs plan and apply. Four situations follow from that.

Drift: revert it or adopt it

Drift is an out-of-band change — someone edits a Terraform-managed resource in the console. The next plan shows the difference and proposes changing the resource back to the configuration. You then choose: revert by applying that plan, or adopt the change by updating the configuration to the new value (for example, the new machine_type) and confirming the plan is empty, so configuration, state and reality agree. terraform apply -refresh-only is not a way to keep a change: it only updates state to match reality and never edits configuration, so the very next normal plan proposes reverting the change again. Whichever path you take, the rule that makes IaC work is social as much as technical: once Terraform manages a resource, nobody changes it by hand except in a documented emergency followed by revert or adoption.

Importing resources created outside Terraform

Resources built in the console before Terraform was adopted can be brought under management without re-creation. Write resource blocks that match the current settings, then map each block to the real resource's ID. Import blocks (Terraform 1.5 and later) are configuration —

import {
  to = google_compute_network.prod
  id = "projects/acme-prod/global/networks/prod"
}

— so they are reviewed in the merge request and executed by a normal plan and apply; Terraform can even generate starting configuration with terraform plan -generate-config-out. The older terraform import command writes to state immediately from the CLI. Either way, look for a plan that shows only imports and no changes before you apply: that confirms your blocks match reality, and nothing is modified or recreated.

Refactoring into modules without destroy and create

A resource's address in state includes its module path. Moving google_compute_network.vpc into a module changes its address to module.network.google_compute_network.vpc, so Terraform sees the old address as removed and a new one as added and plans to destroy and recreate the resource — even though nothing about it changed. A moved block (Terraform 1.1 and later) records the rename in configuration:

moved {
  from = google_compute_network.vpc
  to   = module.network.google_compute_network.vpc
}

The plan then shows a move instead of destroy and create, and state is updated during the next apply. Because the move is code, it is reviewed in the merge request like everything else. The CLI alternative, terraform state mv, edits state directly — it works, but it is a manual, unreviewed operation against production state.

Deletion guards: Terraform-only versus API-enforced

Not all protection is equal. Some guards live only inside Terraform; others are set on the resource itself and enforced by the Google Cloud API for every client.

When a requirement says a resource must survive deletion attempts from any tool, you need the API-level setting; the Terraform-side guards protect only against an accidental destroy or replacement in a plan. Many teams set both.

Terraform records everything it manages in a state file — a JSON mapping from your resource addresses to the real resource identifiers in Google Cloud, plus their attribute values. State is how plan knows what already exists and what changed. Lose it, and Terraform believes it manages nothing; corrupt it, and plans become nonsense.

By default state lives in a local terraform.tfstate file, which is unacceptable for teams: it is not backed up, it is invisible to colleagues, and engineers working from their own copies overwrite each other's changes. The standard fix on Google Cloud is the Cloud Storage (gcs) backend:

terraform {
  backend "gcs" {
    bucket = "acme-prod-tf-state"
    prefix = "prod/network"
  }
}

What the backend does, and what it leaves to you:

• Shared state. Every collaborator and pipeline reads and writes the same state object.
• Locking, built in. The gcs backend locks state natively by writing a lock file next to the state object — no separate lock service is needed. A second run that finds the lock held fails immediately with a lock error, because -lock-timeout defaults to 0s; setting -lock-timeout=5m makes it retry for that long instead. Disabling locking with -lock=false is a recovery tool, not a workflow.
• The bucket must already exist. The backend does not create it, and Terraform does not enable Object Versioning on it. Create the bucket first (often with a small bootstrap configuration) and turn versioning on yourself; with versioning, every state write creates a new object generation, so a bad write can be rolled back to an earlier one.

State contains secrets

State stores resource attributes in plain text, including generated and supplied secrets such as database passwords. Marking a variable or output sensitive = true only redacts it in plan, apply and output display; the real value is still written to state, and with Object Versioning on, older generations keep older copies too. (Newer Terraform versions add ephemeral values and write-only arguments that keep a value out of state, but only where a resource supports them.) So:

• Restrict read access to the state bucket with IAM to the identities that run Terraform — anyone who can read state can read every secret in it.
• Never commit state to version control. Add *.tfstate to .gitignore.
• If state has already been exposed, deleting the file is not enough: the value remains in repository history, clones and backups. Rotate every exposed secret so the leaked copy is useless, then move state to a restricted backend.

In short: whenever state lives on one person's machine — so team members overwrite each other's changes, or a lost laptop means lost state — the fix is remote state in a gcs backend bucket with Object Versioning on, which gives a shared copy, built-in locking and recoverable history.

Environment isolation means a run for one environment cannot read or change another. A single root configuration with one shared state for dev, staging and production fails that test: every apply can touch every resource in state, so one mistaken variable or target can change production.

The robust pattern combines three separations:

1. One root configuration and one state per environment. Each environment has its own small root module (a dev/, staging/ and prod/ directory) that calls the same shared modules with different variables. A dev run only knows about dev's resources.
2. A separately scoped deployer service account per environment. The dev deployer has roles only in the dev project, so even a misconfigured dev run gets permission errors in production. Credentials are the hard boundary; separate state is the organizational one.
3. State stored under that environment's own IAM. A bucket's access is governed by its project's (and its own) IAM. Putting prod state under a different prefix in a bucket in the dev project is not isolation — anyone with object access to that bucket in dev can read prod's secrets or overwrite its state. Keep prod state in a bucket in the prod project, readable and writable only by the prod deployer.

Terraform CLI workspaces (terraform workspace new prod) give one configuration several state files in the same backend. HashiCorp itself says they are not suitable where deployments need separate credentials and access controls: every workspace uses the same backend and the same credentials, so they do not provide the isolation above. They suit short-lived copies of the same environment, such as testing a change.

Config Connector lets you manage Google Cloud resources — buckets, Pub/Sub topics, Cloud SQL instances, IAM policies — as Kubernetes objects. It installs into a GKE cluster (available as a GKE add-on) and registers a custom resource definition for each supported Google Cloud resource type. You then declare infrastructure in YAML and apply it with kubectl, exactly as you would a Deployment or Service:

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-team-assets
spec:
  location: US

The differentiating behavior is continuous reconciliation. Terraform enforces desired state only when someone runs apply; between runs, drift just sits there. Config Connector runs a controller loop that watches its resources continuously — if someone deletes or mutates the bucket out-of-band, the controller detects the divergence and drives the resource back to the declared spec. Your Git repository plus a GitOps sync tool plus Config Connector yields infrastructure that is not only versioned but self-healing.

Credentials: cluster mode versus namespaced mode

Config Connector authenticates to Google Cloud as a Google service account, wired up through Workload Identity Federation for GKE rather than exported keys. How many service accounts it uses depends on the mode:

In namespaced mode you grant each namespace's service account roles only on that team's project, so one team's manifests cannot create or change resources in another team's project. The namespace usually also carries the cnrm.cloud.google.com/project-id annotation that sets the default project for its resources.

Lifecycle: deletion, abandoning and acquiring

The Kubernetes object owns the cloud resource: deleting the object deletes the Google Cloud resource by default. To remove the object but keep the resource — for example, when retiring a cluster — annotate it first with cnrm.cloud.google.com/deletion-policy: abandon; deleting the object then leaves the resource running and unmanaged. The reverse also works: when you apply an object whose name (or resourceID) matches a resource that already exists, Config Connector acquires the existing resource instead of creating a new one. Together these let you move management of a live resource, such as a production Cloud SQL instance, from one cluster to another with no re-creation and no downtime.

Choose Config Connector when your team already lives in Kubernetes and wants one API, one toolchain, and one RBAC model for both applications and the infrastructure they depend on. Choose Terraform when you are provisioning the platform itself — organizations, folders, networks, the GKE cluster Config Connector would run on — or when the operators are not Kubernetes-native.

Helm is the package manager for Kubernetes, and its role in this lineup is different from the others: it does not provision Google Cloud infrastructure, it packages and deploys applications onto clusters like GKE. A chart bundles the Kubernetes manifests an application needs — Deployments, Services, ConfigMaps — as templates parameterized by a values file. Installing a chart with a particular set of values produces a release, a named, versioned instance of that application in the cluster.

The workflow is helm install to deploy, helm upgrade to roll out a new version or new values, and helm rollback to return to a previous release revision when an upgrade misbehaves. Because charts are parameterized, one chart serves every environment: the same application chart installs to dev and prod with different replica counts, hostnames, and resource limits supplied by per-environment values. Charts are stored and shared through Artifact Registry, which keeps Helm charts as OCI artifacts in Docker-format repositories, right alongside your container images. You package the chart (helm package ./web produces web-1.4.0.tgz, named from the chart's name and version), authenticate Helm to the registry, and push it to an oci:// address made of the repository path: helm push web-1.4.0.tgz oci://us-central1-docker.pkg.dev/PROJECT_ID/REPOSITORY. Clusters then install it straight from that address with helm install web oci://us-central1-docker.pkg.dev/PROJECT_ID/REPOSITORY/web --version 1.4.0. helm repo add is for classic HTTP chart repositories and does not work with OCI registries.

The exam distinction to hold onto: Helm operates inside the cluster boundary on Kubernetes-native objects. If a scenario is about deploying or templating an application across GKE environments, the answer is Helm. If it is about creating the cluster, the VPC, or a Cloud SQL instance, Helm is the wrong tool — that is Terraform or Config Connector territory.

Fabric FAST is Google's opinionated, production-ready Terraform framework for setting up an entire organization — a landing zone accelerator built from the Cloud Foundation Fabric modules. Rather than writing your own Terraform for the organization hierarchy, billing, centralized logging, VPC design, and security guardrails, FAST provides staged configurations you customize and apply in sequence: bootstrap the organization and its automation service accounts, lay down the resource hierarchy, build networking and security, then stamp out workload projects with a project factory. It encodes Google's enterprise best practices so a small platform team gets an auditable, IAM-segregated foundation in days instead of quarters.

The way FAST runs is itself a security design. The bootstrap stage is run once, by a human user with organization-level administrative roles, because nothing exists yet to run it. It creates the automation project, the Cloud Storage buckets for each stage's state, and a separate, narrowly scoped service account for every later stage. From then on each stage runs by impersonating its own service account — typically from CI/CD — so no single long-lived automation identity holds organization-wide administrative power, and the human admin's elevated access is needed only for the initial bootstrap.

With all four tools on the table, the selection logic compresses into one comparison:

Scenario: a fintech platform team inherits a raw Google Cloud organization. They apply Fabric FAST to stand up the hierarchy, shared networking, and guardrails; use Terraform with the Google provider (state in a versioned Cloud Storage bucket) for the GKE clusters and Cloud SQL instances each product needs; hand product teams namespaces where Config Connector manages their buckets and Pub/Sub topics through the same GitOps flow as their apps; and ship those apps as Helm charts stored in Artifact Registry. Four tools, zero overlap — each is doing the one job it is best at, which is precisely the judgment the exam tests.

Google Cloud wraps AI assistance around both planning and implementation, and the exam guide names four tools; a fifth, Gemini Code Assist, often appears beside them. The fastest way to tell them apart is where each one works and what it already knows.

Two traps follow from the table. Being able to run something without installing it does not separate Gemini CLI from Cloud Assist — Gemini CLI comes preinstalled in Cloud Shell. What separates Cloud Assist is its built-in project context and its troubleshooting investigations: you do not have to describe your resources to it. And an IDE assistant is not a console assistant: Gemini Code Assist helps you write code, not inspect a running project.

Gemini CLI in automation

Gemini CLI reads GEMINI.md context files from the project (and from your home directory) as persistent instructions, so team conventions — naming, labels, module standards — committed to the repository apply to every run without being repeated in each prompt. For unattended use, such as a CI step that reviews a Terraform merge request, the -p (prompt) flag runs it non-interactively: it processes the prompt, prints the result and exits instead of waiting for a person.

Google Antigravity

Antigravity is built for handing whole tasks to agents rather than getting suggestions line by line. An agent can implement a feature in the editor, run tests in a terminal and open the app in a browser to check the result, then present artifacts — task lists, implementation plans, screenshots and browser recordings — so you review what it did and why before accepting the work. Its agent manager lets one developer dispatch and supervise several agents working in parallel.

One rule for all of them

These tools assist; the review-and-apply discipline from the Terraform workflow does not change. AI-generated configuration goes through the same plan, review and approval gates as human-written code, and an agent's proposed commands deserve the same scrutiny as a colleague's.

Application Design Center turns an architecture diagram into a deployed, managed application. You compose an application on a canvas from Google Cloud components — Cloud Run services, Cloud SQL databases, load balancers, buckets — connect them, configure each component, and get infrastructure as code for the result without writing Terraform by hand. Gemini Cloud Assist can propose and refine a design from a natural-language description.

The pieces the console uses:

• Templates are reusable application designs. A platform team can publish approved templates so product teams start from a vetted architecture.
• Catalogs collect templates for sharing, and spaces are the shared workspaces where teams create, share and deploy templates and applications.
• Applications are what you deploy from a template, with environment-specific settings.

There are two ways to deploy, and they are not equivalent:

Know its scope, too. Application Design Center designs and deploys applications inside an existing Google Cloud environment. It does not build the organization foundation — the folder hierarchy, IAM baselines, shared networking, centralized logging and security guardrails. That is the job of a landing-zone framework such as Fabric FAST, or your own Terraform.