Terraform on Google Cloud

1. State: the backend and the bucket

terraform {
  backend "gcs" {
    bucket = "BUCKET_NAME"
  }
}

The backend is named gcs and bucket is the field the documented example requires. The tutorial's order matters: create the bucket first, then move local state with

terraform init -migrate-state

Enable object versioning on the state bucket. The page's reason, verbatim-ish: versioning is enabled "to ensure that earlier versions of the state are preserved in the bucket". A corrupted or truncated state write with no versioning is unrecoverable, and it is the single worst failure in a Terraform estate.

The page's own emphasis for protecting state is IAM permissions and public access prevention on the bucket — see reference/storage/cloud-storage-access-control.md. Recorded as an absence: the page does not carry an explicit warning that state files contain sensitive values. That warning is true of Terraform generally and is not made here on this page's authority.

2. Blueprints

Google publishes Blueprints: "deployable, reusable Terraform modules". Use one before writing a module for a problem Google has already modelled — a landing zone, a network, a GKE cluster.

3. Infrastructure Manager — running Terraform as a Google Cloud service

Infra Manager "simplifies and automates the deployment and management of your Google Cloud infrastructure resources" from Terraform configurations. Its three objects:

Object	What it is
deployment	the managed unit: one configuration, applied
revision	one applied version of that deployment
preview	a plan, without applying

Per revision it keeps the logs, the configuration, the resource list and the state file, and it creates a Cloud Storage bucket for the deployment's metadata. A Terraform version is chosen per deployment.

Two readings an estimate needs:

• Infra Manager is the answer to "who runs terraform apply, and where does state live" **without a CI

system**. It removes the runner and the state bucket from the design.

• It is the named migration target for Deployment Manager (reference/iac/deployment-manager-status.md),

which is no longer supported, so an estate still on Deployment Manager has a decision already overdue.

Absences recorded rather than filled in: the overview page does not state which Terraform versions are supported, which identity Infra Manager runs as by default, its API name, or any limits or location restrictions. Check the product's own reference before committing a design to any of those.

4. What the overview deliberately does not say

The Terraform-on-Google-Cloud overview makes no recommendation about provider version pinning and none about which authentication method to use. That is an absence, not a permission: this hub's own rule still applies — keyless, identity-based authentication first (reference/identity/workload-identity-federation.md), and a pinned provider version, because an unpinned provider is the commonest cause of a plan that differs between two runs of the same configuration.

Next: the error catalogue at reference/iac/errors.md, the first-apply walkthrough at guides/iac/terraform-first-apply.md, and the cross-cloud comparison — including the fact that Google Cloud's first-party IaC language is Terraform itself, where AWS and Azure each have a native one — at guides/parity/iac.md.