This article covers Cloud Deployment Manager and Terraform as the two infrastructure-as-code (IaC) options for Google Cloud, why Terraform has become the dominant tool in practice, when Deployment Manager still makes sense, and what the Associate Cloud Engineer exam expects you to know about each.
It does not cover Terraform's full feature set, the specifics of state management, or how to write idiomatic HCL. Those are deep topics in their own right. The goal here is the comparison and the exam framing.
Both Cloud Deployment Manager and Terraform are infrastructure-as-code tools. You write a configuration file that describes the cloud resources you want. You run a command. The tool creates, updates, or deletes resources to match the configuration. The result is reproducible infrastructure that lives in version control instead of being clicked together in the console.
The IaC philosophy is the same in both. Treat infrastructure like software. Review it. Test it. Roll it back. Both tools deliver on that.
Deployment Manager is GCP-native. It is a Google service that lives inside the Cloud Console. Configurations can be written in YAML, Jinja2, or Python. YAML is declarative ("I want these resources"). Jinja and Python are templated, with variables, loops, and conditional logic.
It uses templates to scale and repeat deployments. You can preview changes before applying them. You can update an existing deployment without taking everything down.
The catch is that Deployment Manager only manages GCP resources. It does not do AWS, Azure, or anything else. And in practice, the GCP community and Google itself have been steering teams toward Terraform for years.
Terraform is from HashiCorp, not Google. It is the de facto standard for cloud infrastructure as code, and it works against every major cloud (AWS, Azure, GCP) plus hundreds of other providers (DNS providers, monitoring services, source control, almost anything with an API).
For GCP specifically, Terraform uses the Google provider, which exposes the same resource types Deployment Manager manages. You write HCL (HashiCorp Configuration Language) instead of YAML or Python. You run terraform plan to preview changes and terraform apply to make them.
A few reasons, in rough order of importance.
Multi-cloud and multi-provider support. Most real organizations run on more than just GCP. They have an AWS account somewhere, or a Cloudflare zone, or a PagerDuty integration. Terraform manages all of that with the same tool. Deployment Manager only does GCP.
Larger community and ecosystem. The Terraform Registry has thousands of community modules. The Google provider for Terraform has more active development than Deployment Manager. Stack Overflow has more answers about Terraform.
Google's own posture. Google's own documentation increasingly defaults to Terraform examples, and many GCP teams I have worked with do not use Deployment Manager at all in production.
The result is that Terraform has become the standard, and Deployment Manager is the legacy option. That said, Deployment Manager still exists, still works, and still shows up on the ACE exam.
Deployment Manager makes sense if you are committed to a GCP-only environment, want to stay inside Google-managed services, and prefer YAML or Python over HCL. It also has tighter integration with Cloud Build pipelines if you are using Google's full stack end to end.
For a GCP-only shop building straightforward infrastructure with minimal cross-cloud needs, Deployment Manager is fine. For most other cases, Terraform is the better answer.
This is the part that catches people. Even though Terraform has won in practice, the Associate Cloud Engineer exam still tests Cloud Deployment Manager directly. The exam covers Deployment Manager in detail, and exam questions reference it by name.
The patterns are these. If a question asks about a GCP-native infrastructure as code tool, the answer is Cloud Deployment Manager. If a question shows a YAML, Jinja, or Python configuration file targeting GCP resources, that is Deployment Manager. If a question mentions the --preview flag, that is Deployment Manager (preview is its term for a dry run).
If a question mentions Terraform by name, the exam usually frames it alongside Deployment Manager as the third-party equivalent, and the answer often hinges on something specific to one or the other (the --preview flag, the YAML format, the multi-cloud capability).
If you see in the question infrastructure as code on GCP, configuration files in YAML or Python, the --preview flag, or templates for repeatable deployments, think Deployment Manager. If the question explicitly mentions multi-cloud or HashiCorp, think Terraform.
Cloud Deployment Manager is GCP's native infrastructure-as-code service. It uses YAML, Jinja, or Python. Terraform is the third-party industry standard, multi-cloud, and now the de facto choice for most teams. The ACE exam still tests Deployment Manager because it is GCP-native, even though Terraform is what most teams actually use.
For the Associate Cloud Engineer exam, learn Deployment Manager's basic structure and the --preview flag. Recognize Terraform when it shows up but do not spend extra time on it because the exam coverage is light.
My Associate Cloud Engineer course covers Cloud Deployment Manager in the IaC section alongside Cloud Build, with the practical context for how the ACE exam frames each tool.
