Installing Terraform and the CLI

Working with Terraform on Google Cloud from your laptop needs two command-line tools, not one: Terraform itself, and the Google Cloud SDK that provides the gcloud command. Terraform reads your HCL and calls the GCP APIs; gcloud supplies the local credentials those API calls authenticate with, plus a handful of operations Terraform leans on. Skip the second tool and your first plan fails with no credentials.

Getting both installed, pinned to known versions, and authenticated is the five-minute setup everything else in this course assumes. None of it is hard, but two of the steps have a trap that costs newcomers an afternoon — the difference between two gcloud auth commands that look interchangeable and are not.

Installing Terraform

Terraform is a single static binary. You can download it from HashiCorp's releases page and drop it on your PATH, or install it through a package manager — brew install terraform on macOS, the HashiCorp apt repository on Debian and Ubuntu. On a team, prefer a version manager like tfenv or mise that switches the Terraform version per project, because the version is something you want to control deliberately rather than inherit from whatever the package manager last pulled.

Whichever route you take, verify it with terraform version. That command prints the installed version and, once you are inside a configured directory, flags when the binary is older than what the configuration requires. If it prints a version, Terraform is on your path and you are done with the first tool.

Installing the Google Cloud SDK

The Google Cloud SDK ships the gcloud CLI, and Terraform depends on it for two things. It writes Application Default Credentials — the credentials the google provider reads automatically — and it holds your active account and project context. Install it from Google's installer, through brew install --cask google-cloud-sdk, or your distribution's package, then run gcloud init once to log in and pick a project.

Verify with gcloud version. The provider does not call gcloud for every resource — it talks to the GCP REST APIs directly — but it reads the credentials gcloud wrote, so the SDK has to be present and authenticated before Terraform can do anything against your account.

Pinning Versions

Two Terraform versions that differ only in a minor release can produce different plans for the same configuration, and on a shared team that turns into noisy, confusing diffs nobody asked for. Pin the version two ways: a required_version constraint inside the terraform block so Terraform refuses to run under an unexpected version, and a version-manager file committed to the repo so everyone — and CI — installs the same one.

terraform {
  required_version = "~> 1.9.0"   # 1.9.x patches yes, 1.10 no
}

The ~> 1.9.0 constraint allows 1.9.x patch releases but blocks an accidental jump to 1.10, so a teammate on a newer minor gets a clear error instead of a silently different plan. (The looser ~> 1.9 would allow the whole 1.x line from 1.9 up — fine if you only want to block the 2.0 major.) Running "latest" everywhere is the opposite of this — it guarantees that sooner or later two machines disagree about what your infrastructure should look like.

First Authentication

For local development, you authenticate once with gcloud auth application-default login. That opens a browser, you consent, and gcloud writes a credentials file to a well-known path that the google provider discovers on its own — you do not point Terraform at it, configure a key, or set a variable. The authentication chapter goes deep on credentials, impersonation, and federation; this is the one command that gets you running today.

# Writes ADC that the google provider reads automatically
gcloud auth application-default login

Confirm it worked before writing any real resources by running a trivial plan against a data source — a read-only lookup that needs valid credentials but creates nothing. If the plan returns data, your ADC is in place and the provider can reach your project.

Editor and Workflow Setup

Two small things compound across thousands of edits. Install the Terraform language server so your editor surfaces syntax errors, undefined references, and bad arguments as you type rather than at plan time. And wire terraform fmt to run on save, so every file lands in canonical style and formatting never shows up as noise in a code review.

Shell completion for both terraform and gcloud is worth the two minutes it takes to enable. None of this is required to run Terraform, but a new engineer who copies the exact two-CLI setup from a documented repo README is productive in minutes instead of debugging a credentials error on their first afternoon.