certifications 20 Oct 2026

GCP ACE: Terraform on Google Cloud

gcpacecertificationterraforminfrastructure-as-codemarketplace

Terraform is the infrastructure-as-code tool the ACE exam expects you to recognize, even though it isn’t a Google product. Google co-develops the google provider with HashiCorp, ships Terraform preinstalled in Cloud Shell, and builds several of its own tools — bulk export, policy validation, Marketplace CLI deployment — directly on top of it. This post covers the provider, the core workflow, where state lives, how to bring existing resources under management, and the two places the exam guide ties Terraform to Google Cloud Marketplace.

The Google provider

Every Terraform configuration targeting Google Cloud starts with a provider block:

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 6.0"
    }
  }
}

provider "google" {
  project = "my-project-id"
  region  = "europe-southwest1"
  zone    = "europe-southwest1-a"
}

There are two variants:

Provider	Scope
`google`	Generally available (GA) resources only.
`google-beta`	GA resources plus beta/preview resources and beta-only fields on GA resources.

A resource block picks which one it uses with provider = google-beta; most configurations declare both providers and use google-beta only for the specific resources that need it, rather than switching the whole file.

Authentication

By default the provider authenticates with Application Default Credentials (ADC). On a workstation that means running:

gcloud auth application-default login

Cloud Shell comes with Terraform preinstalled and pre-authenticated — no setup step needed, which is why it’s the environment Google’s own tutorials default to. On a Compute Engine VM or other Google-managed compute, attaching a service account to the instance gives Terraform credentials without a key file at all. Outside Google Cloud (a CI runner, your laptop without gcloud), you fall back to a service account key and GOOGLE_APPLICATION_CREDENTIALS, or — the exam-preferred pattern — service account impersonation, which avoids a long-lived key entirely.

Core workflow: init, plan, apply, destroy

Command	What it does
`terraform init`	Downloads providers/modules, sets up the backend.
`terraform fmt`	Rewrites `.tf` files to the canonical style.
`terraform validate`	Checks syntax and internal consistency, without talking to Google Cloud.
`terraform plan`	Compares config against state and real infrastructure, prints the proposed diff.
`terraform apply`	Executes the plan (or a saved plan file) and updates state.
`terraform destroy`	Removes every resource the configuration manages.

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Saving the plan with -out and applying that exact file is the safer pattern for anything beyond solo experimentation: it guarantees the plan you reviewed is the plan that runs, with nothing drifting in between.

Remote state in Cloud Storage

Local state (a terraform.tfstate file on disk) doesn’t survive a team, a CI pipeline, or losing the laptop. The standard remote backend on Google Cloud is a Cloud Storage bucket:

terraform {
  backend "gcs" {
    bucket = "my-terraform-state-bucket"
    prefix = "terraform/state"
  }
}

Cloud Storage supports state locking natively — there’s no second component to provision for it, unlike backends that need a separate lock table. Moving an existing local state file into the bucket is one command:

terraform init -migrate-state

Terraform detects the existing local state and prompts you to confirm the migration.

Bringing existing resources under Terraform

Two different problems come up here, and the exam guide treats them separately.

Importing one resource you already have a config block for:

terraform import google_compute_instance.default \
  projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

Bulk-exporting resources you have no config for yet, generating both the .tf files and the import statements in one pass:

gcloud services enable cloudasset.googleapis.com

gcloud beta resource-config bulk-export \
  --project=PROJECT_ID \
  --resource-format=terraform \
  --path=OUTPUT_DIRECTORY

gcloud beta resource-config terraform generate-import OUTPUT_DIRECTORY

The first command writes HCL for every supported resource in the project (or folder/organization, with --folder/--organization) to OUTPUT_DIRECTORY; the second turns that output into an import script you run against it. gcloud beta resource-config list-resource-types tells you which resource types bulk export currently supports — it isn’t every resource type the google provider itself supports.

Validating plans against policy: terraform vet

gcloud beta terraform vet checks a rendered Terraform plan against a policy library before you apply it — a guardrail for things like “no public IPs on this project” that you want enforced regardless of who writes the config.

terraform plan -out=tfplan
terraform show -json tfplan > tfplan.json

gcloud beta terraform vet tfplan.json \
  --policy-library=./policy-library \
  --project=PROJECT_ID

It takes the JSON export of a plan, not the .tf source — hence the terraform show -json step first. --policy-library is a required flag pointing at a directory of policies (Google’s Cloud Foundation Toolkit ships a reference library you can start from rather than writing one from scratch).

Terraform on Google Cloud Marketplace

This is the part that connects Terraform back to Marketplace in the exam guide. Some VM-based Marketplace products support a Terraform deployment path in addition to the normal console click-through:

Method	What happens
Console deploy	Standard point-and-click flow on the product page; no Terraform involved.
Command-line (CLI) deployment	On the product page, Deploy with CLI gives you either a downloadable Terraform module or a generated code snippet; you run `terraform init` / `terraform apply` yourself.
Terraform-based UI deployment	For products that support it, the console deployment page itself is backed by Infrastructure Manager — you configure the solution in the UI, and it applies the Terraform under the hood. You can switch to CLI mid-flow or download the module for your own CI/CD pipeline.

Not every Marketplace listing offers this — Google started with a limited set of frequently deployed VM images and has been expanding it. The thing worth remembering for the exam: when a Marketplace product does support it, “Deploy with CLI” is where you find the module, and the flow is still the ordinary terraform init → terraform apply sequence, just with a vendor-supplied configuration instead of one you wrote.

Exam Takeaways

google provider: GA resources only. google-beta: GA plus beta resources/fields — set per-resource with provider = google-beta.
Default auth is Application Default Credentials; Cloud Shell comes with Terraform preinstalled and pre-authenticated, which is why Google’s tutorials default to it.
Core workflow: init → plan → apply; destroy tears down everything the config manages. Saving a plan with -out and applying that file is the safer pattern.
Cloud Storage is the standard remote backend and supports state locking natively — no extra locking component needed. terraform init -migrate-state moves local state into it.
terraform import brings in one resource at a time against an existing config block. gcloud beta resource-config bulk-export + gcloud beta resource-config terraform generate-import bulk-generates config and import statements for resources you don’t have config for yet.
gcloud beta terraform vet validates a JSON-exported plan (terraform show -json) against a --policy-library directory — it checks the plan before apply, not the raw .tf source.
Google Cloud Marketplace offers Terraform deployment for select VM products via Deploy with CLI (module or code snippet) or a Terraform-based console UI backed by Infrastructure Manager — not every listing supports it.

Sources

↗ LinkedIn