Infrastructure Manager

Infrastructure Manager is Google's managed Terraform service. You hand it your HCL — from a Cloud Storage object or a connected Git repo — and Google hosts the state, runs the apply on Cloud Build under the hood, and ties the whole thing into GCP IAM. It is the GCP-native counterpart to HCP Terraform: the answer when you want managed Terraform runs without standing up your own state bucket, runners, and CI plumbing.

The pitch is that it removes the operational surface the previous topics built by hand. No hatch-tfstate bucket to provision and secure, no cloudbuild.yaml to maintain, no WIF trust to wire — Google owns the state and the runner. What you give up in exchange is control over the pipeline, and that tradeoff is the whole decision this topic helps you make.

The Deployment as the Unit

Infrastructure Manager wraps a config in a deployment resource. You point the deployment at your Terraform source, it runs plan and apply, and it tracks the result. The deployment — not a state file you manage — is the thing you interact with: you create it, update it when the source changes, and read its status. The object model is one level up from raw Terraform.

This matters because your mental model shifts from "a directory with state" to "a deployment Google operates." You no longer reach for the state file or the lock object; you operate the deployment through its API and IAM, and Google handles the Terraform mechanics underneath.

Google Hosts the State

There is no hatch-tfstate bucket to provision or secure for an Infra Manager deployment. Google stores and locks the state for you, which removes the entire backend-bootstrapping problem from Topic 69 — no bucket to create in a hatch-admin project, no bootstrap config on local state, no versioning lifecycle rule to tune. The chicken-and-egg of the bucket that cannot store its own state simply does not arise.

The flip side is that you operate through the deployment, not the raw state. You cannot edit an Infra Manager deployment's state as a GCS object the way you would a self-managed backend; it is Google's, and your interface is the deployment API. That is fine until you hit a situation that wants a hand terraform state mv, which the managed surface constrains.

Runs on Cloud Build Under the Hood

Infra Manager executes the Terraform on Cloud Build using a service account you specify. Its permissions and blast radius are governed by that SA exactly as in Topic 70 — it is managed Cloud Build, not a separate engine. The same rule applies: scope the deployment's service account to least privilege, because Infra Manager applies as that SA and its grants are the deployment's reach.

Reading it as "managed Cloud Build" keeps the security model familiar. Everything you learned about the build SA defining the blast radius carries over unchanged; Google has just taken over operating the runner and the state around it.

IAM-Native Access Control

Who can create, view, or apply a deployment is governed by GCP IAM roles — roles/config.admin to manage deployments, roles/config.agent for the service account that runs them. Deployment permissions live in the same IAM model as the rest of the org, rather than in a separate SaaS with its own user and team management. For a GCP-centric org this is the real draw: one identity model for infrastructure and for the tool that provisions it.

When to Choose It and the Tradeoff

Pick Infra Manager over self-hosted CI when you want Google to own state and runners and keep everything inside GCP IAM. Pick it over HCP Terraform when you want to avoid a separate vendor and stay GCP-native. Stay on self-hosted CI — Cloud Build or GitHub Actions plus WIF — when you need rich pull-request automation, multi-cloud runs, or policy-as-code that Infra Manager does not yet match. The choice is about how much of the pipeline you want to own.

The tradeoff is real on both sides. Infra Manager removes operational burden but gives less control over the run pipeline than a hand-built Cloud Build or GitHub Actions flow, and its feature surface trails HCP Terraform's — no built-in cost estimation, narrower policy tooling. It runs standard Terraform HCL, so there is nothing to rewrite; it is a runner and state host, not a new language, and assuming otherwise leads people to "port" configs that already run as-is.