Terraform vs GCP's Native IaC
Google Cloud has shipped four different ways to manage infrastructure as code over the years, and a new engineer needs to know which are alive, which are dead, and why Terraform is the one this course teaches. The short version: Deployment Manager is deprecated and scheduled to shut down, Config Connector and Config Controller manage GCP resources through Kubernetes, Infrastructure Manager is Google running Terraform on your behalf, and plain gcloud is imperative and not IaC at all.
Knowing the landscape matters because every one of these still appears in internal wikis, Stack Overflow answers, and old runbooks — and three of the four are the wrong place to start a new project today. This topic walks each option, says plainly where it stands, and lands on why standard Terraform is the default for the Hatch pipeline and everything after it.
Deployment Manager, Deprecated
Deployment Manager was Google's original IaC service: you described resources in YAML, with Jinja or Python templates for anything dynamic, and Google's control plane created them. It only ever managed Google Cloud — there was no path to AWS, Cloudflare, or anything off-platform — and it never grew a real module ecosystem or community around it.
Google has deprecated Deployment Manager — it reached end of support on March 31, 2026 — and steers customers to Infrastructure Manager and Terraform instead. The practical instruction is short: do not start anything new on it. If you inherit a Deployment Manager stack, plan a migration to Terraform rather than extending the dead tool one more resource — every line you add is a line you will rewrite under a deadline later.
Config Connector and Config Controller
Config Connector expresses Google Cloud resources as Kubernetes objects. A StorageBucket becomes a Kubernetes custom resource, and a controller running in your cluster reconciles it against the real Cloud Storage API continuously — if someone deletes the bucket by hand, the controller recreates it within seconds, with no apply to run. Config Controller is the managed, Google-hosted flavor of the same idea, so you do not run the cluster yourself.
That continuous reconciliation is the genuine draw, and it is a strong fit for an org already all-in on Kubernetes that wants drift corrected automatically rather than caught at the next plan. The cost is that you take on a cluster and the Kubernetes Resource Model — every resource is now YAML reconciled by a controller you operate. For a team that is not already living in Kubernetes, that is a large bill to solve a problem Terraform solves with a single binary.
Infrastructure Manager
Infrastructure Manager is the option people most often misread. It is not a new language or a different tool — it is a Google-managed service that runs standard Terraform HCL on your behalf, stores the state for you, and ties runs into Google Cloud IAM. The configuration you feed it is the exact same .tf files the local CLI runs; only where Terraform executes and where state lives change.
In other words, Infrastructure Manager is to GCP roughly what HCP Terraform is to HashiCorp: a managed runner and state host, not a competing engine. It is the right pick when you want managed runs without standing up your own state bucket and CI runners, and it is covered fully in the collaboration chapter. Learning Terraform first loses you nothing — Infrastructure Manager is one of several places that same Terraform can run.
gcloud Is Not IaC
The gcloud CLI and the Console are imperative: each command makes one change right now, with no record of desired state and no diff against reality. They are genuinely useful for exploration, one-off inspection, and break-glass fixes — but a pile of gcloud commands in a shell script is not infrastructure as code, because nothing tracks what should exist or reconciles toward it.
The trap specific to GCP is mixing the two. Run a gcloud mutation against a project Terraform manages and you have created drift: the manual change is now something the next terraform plan sees as a difference it wants to revert. Keep gcloud for reads and emergencies, and make every change to managed resources through Terraform.
Why Terraform Is the Default
Terraform wins on the things that compound. It has the largest provider ecosystem of any IaC tool, so the same workflow that manages your GCP project also manages Cloudflare DNS and a GitHub repo. It is multi-cloud, it has by far the biggest hiring pool, and — the strongest signal — Google's own published infrastructure modules, the Cloud Foundation Toolkit, are written in Terraform.
When the platform vendor ships its reference modules in a third-party tool rather than its own native one, that tells you where the vendor expects serious customers to be. Default to Terraform unless you have a concrete, stated reason to pick Config Connector (a Kubernetes-native org) or Infrastructure Manager (you want Google to host the runs and state) — and the rest of this course assumes that default.
Terraform — the portable CLI you run anywhere: your laptop, CI, HCP Terraform, or Infrastructure Manager. The largest ecosystem and the multi-cloud default. Choose it unless a specific constraint pushes you to one of the other two.
Config Connector — reconciles GCP resources continuously through a Kubernetes controller, correcting drift within seconds with no apply to run. Choose it when you are already all-in on Kubernetes and want automatic drift correction, accepting the cluster and KRM model it brings.
Infrastructure Manager — Google running the same Terraform HCL for you, hosting state and tying into GCP IAM. Choose it to get managed runs without operating your own state bucket and runners; it is a runner, not a new language.
- Starting a new project on Deployment Manager because an old internal doc references it — it is deprecated with a shutdown announced, so you will migrate it to Terraform under duress later instead of starting there now.
- Reaching for Config Connector without already running Kubernetes — you take on a cluster and the KRM mental model to solve a drift problem Terraform handles with a single binary and a periodic plan.
- Assuming Infrastructure Manager is a different language you must learn — it runs the same HCL; treating it as a new tool wastes weeks relearning what you already know.
- Mixing
gcloudmutations into a Terraform-managed project — the manual change becomes drift the next plan wants to revert, and you fight your own tooling. - Picking an IaC tool because it is GCP-native rather than because it fits your team — native is not a reason when the vendor itself ships its reference modules in Terraform.
- Default to Terraform unless you have a concrete, stated reason to choose Config Connector (a Kubernetes-native org) or Infrastructure Manager (managed runs).
- Keep
gcloudfor read-only inspection and break-glass access, never for changes to Terraform-managed resources. - If you inherit a Deployment Manager stack, schedule a migration to Terraform rather than adding one more resource to a deprecated tool.
- Adopt Google's Cloud Foundation Toolkit modules, which are written in Terraform — a direct signal of where Google points serious customers.
- Reach for Infrastructure Manager when you want managed runs, knowing it executes the identical HCL and asks you to learn nothing new.
Knowledge Check
Among GCP's native IaC options, which is deprecated and scheduled to shut down?
- Infrastructure Manager
- Deployment Manager
- Config Connector
- Config Controller
When is Config Connector the justified choice over plain Terraform?
- When your org already runs Kubernetes and wants continuous drift correction reconciled by a controller
- When you want the smallest possible tooling footprint with no extra cluster to install and operate yourself
- When you need to manage AWS, Cloudflare, and GCP together from one shared configuration
- When you want Google to host your state file and run the apply on managed runners
What is Infrastructure Manager, precisely?
- A Google-managed service that runs standard Terraform HCL for you and hosts the state
- A new GCP-only configuration language that fully replaces Terraform and its HCL
- A Kubernetes controller that reconciles GCP resources continuously as cluster objects
- The offline disconnected mode of the local Terraform CLI binary
Why is a shell script of gcloud commands not infrastructure as code?
- It is imperative — nothing tracks desired state or diffs against reality, so each command is a one-off
- The
gcloudtool cannot create or update any resources, it can only read existing ones back from the API - A shell script of commands cannot be committed to version control at all
- The
gcloudtool only ever works against a single GCP project at a time
You got correct