Terraform on GCP
Provision Google Cloud with Terraform's google provider and GCS remote state.
Terraform manages GCP via the google provider. You set a default project
and region, and authenticate with Application Default Credentials (gcloud auth application-default login) locally or Workload Identity Federation in CI
(no key files).
Store remote state in a Google Cloud Storage bucket — GCS provides object
versioning and automatic locking, so a separate lock table isn’t needed (unlike
AWS’s S3+DynamoDB). The workflow is the universal init → plan → apply.
terraform {
backend "gcs" {
bucket = "my-tfstate"
prefix = "prod"
}
}
provider "google" {
project = "my-project"
region = "europe-west1"
}
resource "google_storage_bucket" "uploads" {
name = "my-app-uploads-12345"
location = "EU"
}terraform init && terraform plan && terraform apply- Configure the google provider with a project and region.
- Set up a GCS backend for remote state.
- Explain why GCS doesn’t need a separate lock table like AWS does.
- Add a resource for a storage bucket and run
terraform plan.
Cheat Sheet▾
| Item | Detail |
|---|---|
| Provider | provider "google" { project, region } |
| Local auth | ADC (gcloud auth application-default login) |
| CI auth | Workload Identity Federation |
| Remote state | backend "gcs" |
| Locking | Native to GCS (no lock table) |
| Workflow | init → plan → apply |
Common Interview Questions▾
Where do you store Terraform state on GCP?
In a Google Cloud Storage bucket using the gcs backend, which provides native object versioning and locking — no separate lock table is required.
How should Terraform authenticate to GCP in CI without key files?
Use Workload Identity Federation so the CI runner exchanges its identity for short-lived GCP credentials — no downloaded service account key to leak.