A Guide to Deployment Manager & Terraform

magine it’s your first week on the job as a cloud engineer. Your manager gives you a task: “We need a new staging environment for our main application. Please create an exact replica of our production environment—the VPC, the subnets, the firewall rules, the GKE cluster, the Cloud SQL database, all of it.”

You say “Sure thing!” and open the Google Cloud Console. You start clicking. You create a VPC. You try to remember the exact CIDR range for the production subnet. You create the GKE cluster, trying to match the node pool settings from memory. Three days later, after a painful, error-filled process, you have something that looks like the production environment. But is it exactly the same? Probably not. And now your manager asks you to do it again for a new QA team.

This manual, click-based approach to building infrastructure—often called “ClickOps”—is slow, prone to human error, impossible to version control, and completely unscalable. There has to be a better way. There is. It’s called Infrastructure as Code (IaC).

The Infrastructure as Code Revolution

The core idea of IaC is to manage and provision your infrastructure using definition files—code—rather than through manual configuration. You write down a blueprint of what you want your cloud environment to look like, and an engine reads that blueprint and makes it a reality.

This simple idea is revolutionary. It brings all the benefits of modern software development to your infrastructure:

• Version Control: Your infrastructure’s blueprint can be stored in Git, just like your application code. You have a full history of every change ever made.
• Peer Review: A change to a firewall rule can be submitted as a pull request and reviewed by the team before it’s applied.
• Automation: You can integrate your IaC into a CI/CD pipeline to automatically build and tear down environments.
• Repeatability: You can use the same blueprint to deploy a dozen identical environments with the click of a button, eliminating configuration drift.

Google Cloud supports two primary tools for IaC.

Google’s Native Tool: Cloud Deployment Manager (CDM)

Cloud Deployment Manager is Google’s own native IaC service. It allows you to specify all the GCP resources you want in a declarative format using a YAML file.

• How it Works: You create a configuration file (e.g., my-deployment.yaml) that lists the resources you want to create—a compute.v1.instance, a sqladmin.v1beta4.database, etc.—and their desired properties. You then hand this file to the Deployment Manager service, which reads it and makes the necessary API calls to create, update, or delete resources until the reality in GCP matches your blueprint.
• Templates: To avoid writing a single, massive YAML file, you can create reusable templates using Jinja or Python. This allows you to create modular, reusable components, like a template for a “standard web server VM.”
• The Analogy: Think of CDM as giving a detailed, written set of instructions directly to Google’s construction foreman. The foreman knows how to build everything in-house perfectly, but they only know how to build with Google-approved materials.

Here’s a very simple CDM configuration to create a VPC network:

YAML

resources:
- name: my-vpc-network
  type: compute.v1.network
  properties:
    autoCreateSubnetworks: false

You would deploy this with a gcloud command:

Bash

gcloud deployment-manager deployments create my-first-deployment --config my-deployment.yaml

Industry Standard: HashiCorp Terraform

While CDM is a capable native tool, the undisputed industry standard for IaC is HashiCorp Terraform. It’s an open-source tool that is celebrated for its multi-cloud support and powerful workflow.

• How it Works: Terraform uses its own human-readable configuration language called HCL (HashiCorp Configuration Language). The workflow is a simple but powerful three-step process:
  1. Write: You define your desired infrastructure in .tf files. You specify a “provider” (in our case, google) and then declare the resources you want.
  2. Plan: This is Terraform’s killer feature. You run the command terraform plan. Terraform reads your code, inspects the current state of your GCP environment, and shows you a detailed execution plan of exactly what it’s going to do. It will tell you, “I will create 1 VPC, modify 2 firewall rules, and destroy 1 old VM.” This gives you a chance to review and approve the changes before anything actually happens.
  3. Apply: You run terraform apply. Terraform executes the plan you just reviewed and builds or modifies your infrastructure.
• State Management: Terraform keeps a “memory” of the infrastructure it has created in a special file called a state file. This file is crucial, as it’s how Terraform maps the resources in your code to the real resources in your cloud account.
• The Analogy: Think of Terraform as an expert, independent architect who has blueprints for buildings in every city (every cloud). Before the construction crew starts work, the architect presents you with a detailed plan and a scale model (terraform plan) so you can approve every single detail.

Here’s the same VPC network created with Terraform:

Terraform

provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
}

resource "google_compute_network" "vpc_network" {
  name                    = "my-terraform-vpc"
  auto_create_subnetworks = false
}

The Head-to-Head: CDM vs. Terraform

For the exam, you’ll need to know when to choose one over the other.

Feature	Cloud Deployment Manager	Terraform
Provider	Google Cloud (native)	HashiCorp (3rd party)
Language	YAML with Jinja/Python templates	HCL (HashiCorp Config Language)
Multi-Cloud	No, GCP only.	Yes, supports all major clouds.
State Management	Stateless (relies on GCP as the source of truth)	Stateful (maintains a state file)
Preview Feature	preview command exists	plan command is core to the workflow.
Ecosystem	Smaller, GCP-focused	Massive open-source community and module registry.

The simple takeaway:

• Choose Cloud Deployment Manager if your organization is 100% committed to Google Cloud and wants to use a native, agentless service.
• Choose Terraform if your organization uses multiple clouds, wants to leverage a larger community ecosystem, or considers the terraform plan workflow essential for safety and review. For most organizations today, Terraform is the standard choice.

Common Pitfalls & Best Practices

• Pitfall: “ClickOps Drift.” Making manual changes in the GCP Console to infrastructure that is managed by Terraform or CDM. The next time you run your IaC tool, it may try to revert your manual changes, causing unexpected behavior.
• Best Practice: Commit to IaC. Once a resource is managed by code, all future changes should be made through code and a proper review process.
• Pitfall: Storing the Terraform state file on your local laptop. If your laptop dies or a colleague needs to make a change, the state is lost or inaccessible.
• Best Practice: Use a remote backend for your Terraform state file, such as a Cloud Storage bucket. This provides a central, secure, and lockable location for your team’s state.
• Pitfall: Writing monolithic, giant configuration files for your entire infrastructure.
• Best Practice: Use modules (Terraform) or templates (CDM) to create reusable, composable components. This keeps your code DRY (Don’t Repeat Yourself) and manageable.
• Pitfall: Storing secret keys or passwords directly in your configuration files and committing them to Git.
• Best Practice: Use a secret management tool like Secret Manager and reference the secrets in your IaC code, rather than hardcoding them.

Quick Reference Command Center

Here are the essential commands for both tools.

Tool	Action	Command
CDM	Preview a deployment	gcloud deployment-manager deployments create my-deployment --config my-config.yaml --preview
CDM	Create or update a deployment	gcloud deployment-manager deployments update my-deployment --config my-config.yaml
CDM	Delete a deployment	gcloud deployment-manager deployments delete my-deployment
Terraform	Initialize the directory	terraform init
Terraform	Format the code	terraform fmt
Terraform	Show the execution plan	terraform plan
Terraform	Apply the changes	terraform apply
Terraform	Destroy the infrastructure	terraform destroy