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.

Beyond raw resources, Google publishes Terraform blueprints and modules — packaged, reusable configurations for common patterns like a landing zone network or a CMEK-encrypted bucket. Prefer an existing module over hand-writing hundreds of lines; that is also the philosophy Fabric FAST takes to its extreme, as you will see below.

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 Google provider and any modules, and configures the state backend. It is the first command in any new or freshly cloned configuration. 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 that plan after a confirmation. terraform destroy tears down everything the configuration manages.

The plan step is the safety mechanism, not a formality. In a team setting the plan output is what gets reviewed in a merge request, and CI pipelines typically run plan on every proposed change and gate apply behind approval. 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.

A workflow gotcha worth internalizing: Terraform only manages what it created or was explicitly told about. If a teammate edits a Terraform-managed resource in the console, the next plan flags the difference as drift and proposes reverting it. If a resource was created outside Terraform entirely, terraform import can bring it under management. The discipline that makes IaC work is social as much as technical: once a resource is managed by Terraform, nobody changes it by hand.

Terraform records everything it manages in a state file — a JSON mapping from your resource blocks to the real resource identifiers in Google Cloud. 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. State is therefore the operational heart of a Terraform deployment, and the exam probes whether you know how to protect it.

By default state lives in a local terraform.tfstate file, which is unacceptable for teams: it is unbacked-up, invisible to colleagues, and two simultaneous applies will race each other. The standard fix on Google Cloud is the Cloud Storage backend:

terraform {
  backend gcs {
    bucket = my-org-tf-state
    prefix = prod/network
  }
}

The gcs backend gives every collaborator the same state, supports state locking so concurrent runs cannot corrupt it, and pairs with Object Versioning on the bucket so a bad write can be rolled back. Lock down the bucket with IAM, because state can contain sensitive values — resource IDs, IP addresses, sometimes generated secrets — and anyone who can read it can map your infrastructure.

Exam framing: a question describing multiple engineers overwriting each other's infrastructure changes, or a lost laptop taking the infrastructure inventory with it, is pointing you at remote state in Cloud Storage with versioning and locking.

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.

Config Connector authenticates to Google Cloud as a Google service account, best wired up through Workload Identity Federation for GKE rather than exported keys, and resources are organized per Kubernetes namespace — which maps neatly onto giving each team a namespace that manages its own project's resources.

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 can be stored and shared through Artifact Registry, which supports Helm charts as OCI artifacts alongside your container images.

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.

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 now wraps AI assistance around both the planning and the implementation halves of this lesson, and the exam guide names four tools. Gemini Cloud Assist is the assistant embedded in the Google Cloud console: it helps you design architectures from natural-language descriptions of your requirements, explains and drafts gcloud commands, surfaces cost-optimization opportunities, and helps investigate operational issues — all grounded in the context of your own project and resources.

Gemini CLI is an open-source AI agent that brings Gemini into your terminal. For infrastructure work that means generating and refactoring Terraform or Kubernetes manifests, explaining unfamiliar configuration, and scripting multi-step tasks conversationally, right where the rest of your IaC workflow already lives. Google Antigravity is Google's agentic development platform — an environment where AI agents take on larger, multi-step development tasks, operating across the editor, terminal, and browser with the developer supervising and reviewing the agents' work.

Application Design Center closes the loop between designing and provisioning: it gives you a visual canvas for composing application architectures from Google Cloud components, lets you iterate on the design — with Gemini Cloud Assist able to suggest and refine it — and then generates infrastructure-as-code from the result, so the diagram and the deployed reality come from the same definition. It is the tool a question is describing when a team wants to go from a whiteboard-style architecture to deployable Terraform without hand-translating.

Two grounding rules for the exam and for practice. First, these tools assist — the review-and-apply discipline from the Terraform workflow does not change; AI-generated plans and code go through the same plan, review, and approval gates as human-written code. Second, match the tool to its surface: console assistance is Gemini Cloud Assist, terminal agent is Gemini CLI, agentic development platform is Antigravity, and visual design-to-IaC is Application Design Center.