Infrastructure as Code in GCP

What is Infrastructure as Code?

When you create a Cloud Storage bucket in the Console, GCP creates it immediately, but there is no permanent record of what you configured or why. A new team member cannot reproduce it. You cannot compare it to another environment. If someone changes the settings six months later, that change is invisible.

Infrastructure as Code solves this by treating your cloud resources the same way you treat application code. You write a configuration file that describes the bucket, the IAM bindings, the network, or whatever resource you need. That file goes into version control. Terraform reads it, figures out what needs to change in GCP, shows you a plan, and makes the change when you approve it.

The result is infrastructure that is auditable, reviewable, and reproducible. A junior engineer can read your Terraform code and understand what exists in production. A new staging environment takes minutes to create. Mistakes get caught in code review before they reach production.

Why Infrastructure as Code matters in GCP

GCP makes it very easy to create resources through the Console. That ease is also its risk. A few clicks and you have a new VPC, a service account with broad permissions, or a Cloud SQL instance with public IP enabled. Undoing a bad click, or understanding what someone else clicked three months ago, requires digging through audit logs.

IaC changes the model. Any resource you want to create, you define in code first. The code is the proposal. A teammate reviews it. Terraform shows you exactly what will be created before you run anything. The change lands in git with a commit message explaining why. If something breaks, you revert the commit.

This matters especially in GCP because so much of what you manage has security implications: IAM roles and bindings, service accounts, firewall rules, network configurations. When those change through the Console, there is no built-in review step. When they change through Terraform, a pull request is that review step.

How Infrastructure as Code works

Terraform operates on the concept of desired state. You write HCL (HashiCorp Configuration Language) files that describe what you want to exist: a bucket named my-app-prod-assets in europe-west1, a service account named app-deployer, a Cloud Run service with specific memory and CPU settings. That is your desired state.

Terraform maintains a state file that records what it has already created. When you run terraform plan, Terraform compares three things: your code, the state file, and the actual resources in GCP. If there is a gap between what your code says should exist and what actually exists, Terraform tells you what it plans to do about it.

That plan is the output you review before making any change. A resource marked with + will be created. One marked with - will be destroyed. One marked with ~ will be updated in place. A resource marked with -/+ will be destroyed and recreated, which can cause downtime or data loss. Reading the plan carefully is one of the most important skills in the Terraform workflow.

Drift happens when someone makes a change outside Terraform: resizing a Cloud SQL instance in the Console, manually deleting a firewall rule, tweaking a service account binding. The next time you run terraform plan, Terraform sees that real infrastructure no longer matches your code and flags the difference. That is drift detection, and it is one of the most practically useful things Terraform gives you.

IaC tools for GCP

GCP works with several IaC tools. For most teams, Terraform is the right default. The others serve narrower purposes.

Terraform

Terraform is the industry standard for GCP infrastructure. The hashicorp/google provider covers nearly every GCP resource and is actively maintained. Terraform uses HCL to declare desired state, and the plan/apply workflow means changes are reviewable before anything touches production. It integrates naturally with Cloud Build and CI/CD pipelines, and has a large ecosystem of modules and community documentation.

Config Connector

Config Connector is a Kubernetes add-on that lets you manage GCP resources through Kubernetes custom resource definitions. If your team already runs GKE and wants to manage cloud infrastructure through the same GitOps toolchain as your application manifests, Config Connector is a reasonable fit. It is not a general-purpose IaC tool. Do not adopt it unless you are already operating Kubernetes and want to avoid maintaining a separate Terraform workflow.

Google Deployment Manager (legacy)

Deployment Manager is Google’s original IaC tool, using YAML or Python templates. Google no longer recommends it for new projects. Resource coverage is incomplete, the tool has not kept pace with GCP growth, and the community is a fraction of the size of Terraform’s. If you encounter Deployment Manager in existing infrastructure, treat it as technical debt and plan a migration to Terraform when the opportunity arises.

gcloud scripts

Shell scripts using gcloud commands are useful for one-time migrations, bootstrapping, and quick automation tasks. They are not IaC in the full sense because they are imperative: they tell GCP what to do rather than describing what should exist. They cannot detect drift and cannot show you a plan before making changes. For persistent infrastructure, use Terraform.

Quick comparison

When to use Infrastructure as Code

IaC pays off quickly on anything you intend to keep, anything you need to replicate, and anything that touches security. Here are the situations where it clearly belongs:

• Setting up environments. Defining dev, staging, and production as Terraform configurations means those environments are consistent and created the same way every time. The dev vs staging vs production guide covers how to structure this.
• Managing IAM and service accounts. IAM policy changes are high-risk. Putting them through Terraform means they are reviewed and tracked before anything is applied. See managing IAM with Terraform for a practical walkthrough.
• Networking. VPCs, subnets, firewall rules, and peering configurations are exactly the kind of thing that should never be hand-crafted on a real project.
• Standardising Cloud Run, GKE, and Cloud SQL infrastructure. If you run the same type of workload across multiple projects or environments, Terraform modules let you define it once and reuse it consistently.
• Infrastructure changes through pull requests. A PR gives your team a review step, a history, and the ability to revert. This connects naturally with managing environments in CI/CD.
• Disaster recovery. If a project is deleted or corrupted, a full terraform apply recreates the infrastructure from known-good code. Without IaC, this means piecing it back together from memory.

Getting started with Terraform on GCP

Terraform authenticates to GCP using Application Default Credentials. Run the login command once on your workstation and Terraform picks up your credentials automatically, with no configuration needed in the provider block.

# Step 1: Authenticate Terraform to GCP using ADC
gcloud auth application-default login

# Step 2: Initialise a new Terraform working directory
# Downloads the google provider and sets up local state
terraform init

# Step 3: Preview what will change before touching anything
terraform plan

# Step 4: Apply the changes after reviewing the plan
terraform apply

The most important step is reading the plan. Before you type yes at the apply prompt, scan for any resource marked -/+ (destroy and recreate) or any unexpected deletion. A few seconds here prevents outages.

For CI/CD pipelines, authentication works differently. Running gcloud auth application-default login only works on a developer workstation. For Cloud Build and automated pipelines, use Workload Identity Federation to authenticate without service account keys.

Bringing existing resources under management

Most projects do not start from a blank slate. If you have resources already created through the Console, you can bring them under Terraform management using terraform import. This adds the resource to your state file without recreating it.

# Import an existing Cloud Storage bucket into Terraform state
terraform import google_storage_bucket.assets my-app-prod-assets

After importing, run terraform plan. If the HCL you wrote accurately describes the existing resource, the plan should show no changes. If it shows changes, your configuration does not match reality. Fix the HCL until the plan is clean before moving on to the next resource.

Best practices for teams

IaC only delivers its full value when the whole team follows it consistently. Here is what that looks like in practice.

All long-lived infrastructure is in code. No exceptions. If a resource is going to be there next week, it belongs in Terraform. Establish this as a team norm before resources accumulate outside version control.

Changes go through pull requests. A pull request is your review step. Another engineer reads the plan output, checks the configuration, and approves before anything reaches production. This catches the kinds of mistakes that are easy to make alone.

Use remote state. Store Terraform state in a GCS bucket with versioning and locking enabled. This prevents state corruption when multiple people or pipelines run Terraform concurrently. See Terraform state management for the configuration.

Organise the repository clearly. A well-structured Terraform repo is easier to review and maintain as infrastructure grows. The Terraform project structure guide covers environment directories, modules, and file conventions that scale well.

Separate environments cleanly. Dev, staging, and production should use separate state files and separate variable files. Changes should flow through environments in sequence, not be applied directly to production.

Limit direct production access. Use IAM to restrict who can make changes directly in production. Routing all changes through your pipeline keeps your Terraform state accurate and reduces the chance of unreviewed changes landing in production.

Lock your Terraform and provider versions. Agree on a Terraform version and a provider version across the team. Lock these in a .terraform-version file and a required_providers block. Version drift between team members causes subtle bugs that are hard to diagnose.

You can also enforce infrastructure guardrails across your organisation using Policy as Code, which lets you write rules that prevent misconfigured resources from being applied at all.