Deployment Manager and Terraform on GCP

Infrastructure as Code (IaC) is the practice of managing cloud resources through machine-readable definition files rather than manual CLI or GUI operations. On GCP, two primary IaC tools exist: Google Cloud Deployment Manager (native) and Terraform by HashiCorp (third-party but deeply integrated). Both allow you to define, deploy, and manage resources declaratively, but they differ in architecture, state management, and ecosystem.

Deployment Manager is a Google-managed service that interprets YAML configuration files, optionally augmented with Python or Jinja templates, to create and manage GCP resources. It is tightly coupled with GCP APIs and requires no external state storage — Google maintains the state internally. However, it only supports GCP resources (not multi-cloud) and lacks built-in drift detection.

Terraform is a CLI-based tool that uses HashiCorp Configuration Language (HCL) to define infrastructure. It stores state in a local or remote backend (e.g., Cloud Storage) and supports hundreds of providers (GCP, AWS, Azure, etc.). Terraform performs drift detection by comparing the state file with real-world resources during planning. The ACE exam tests your ability to choose between these tools based on requirements like multi-cloud, state management, and advanced provisioning logic.

When you submit a Deployment Manager config, the following sequence occurs:

Key components: - Config file (YAML): defines resources array, each with name, type, and properties. - Templates (Python/Jinja): reusable building blocks that accept input variables and output resource definitions. - Schema files (YAML): define input parameters and their constraints for templates. - Type providers: allow Deployment Manager to manage non-Google resources (e.g., external APIs) via REST endpoints.

Default values and timers: Deployment Manager uses a default timeout of 60 minutes per deployment operation. If an operation exceeds this, it fails. You can set a custom timeout using the --timeout flag (in seconds).

Terraform follows a distinct workflow:

State management is central to Terraform. The state file (terraform.tfstate) maps resources to their real-world IDs and attributes. By default, it is stored locally, but for teams, you must use a remote backend like Google Cloud Storage (GCS) with versioning enabled. The ACE exam emphasizes that state files contain sensitive data (e.g., VM passwords) and must be secured with encryption and access controls.

Drift detection: When you run terraform plan, Terraform refreshes the state by querying the GCP API for each resource. If someone manually modified a resource (e.g., changed a VM's machine type via the Console), Terraform detects the drift and proposes a change to revert it (or you can import the change with terraform import). This is a key difference from Deployment Manager, which does not automatically detect drift.

Both tools handle resource dependencies. In Deployment Manager, you can set metadata.dependsOn with a list of resource names, or use implicit references (e.g., referencing a network name in a VM's networkInterfaces). In Terraform, dependencies are inferred from references (e.g., google_compute_instance.my_vm.network_interface[0].network = google_compute_network.my_net.self_link), or you can use depends_on meta-argument.

Deployment Manager supports preview mode via --preview flag, which shows what will change without actually applying it. Terraform's terraform plan serves the same purpose. However, Deployment Manager's preview does not show the full diff for complex templates; Terraform's plan is more detailed.

Deployment Manager YAML:

resources:
- name: my-vm
  type: compute.v1.instance
  properties:
    zone: us-central1-a
    machineType: zones/us-central1-a/machineTypes/n1-standard-1
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: projects/debian-cloud/global/images/family/debian-11
    networkInterfaces:
    - network: global/networks/default

Terraform HCL:

resource "google_compute_instance" "my_vm" {
  name         = "my-vm"
  machine_type = "n1-standard-1"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
  }
}

Deployment Manager templates allow looping and conditionals via Python or Jinja. For example, a Python template can generate multiple VMs based on a list of names:

resources = []
for i in range(3):
    resources.append({
        'name': f'vm-{i}',
        'type': 'compute.v1.instance',
        'properties': { ... }
    })

Terraform modules provide reusable infrastructure components. You can call a module from the registry or a local path:

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 4.0"
  network_name = "my-vpc"
  project_id   = var.project_id
}

Both tools integrate with Cloud IAM for permissions. Deployment Manager uses the service account associated with the deployment (by default the Google APIs service account). Terraform uses the credentials configured in the provider block (e.g., a service account key file). Both can leverage Cloud Audit Logs to track changes.

For secrets, Terraform can reference Cloud Secret Manager via data.google_secret_manager_secret_version. Deployment Manager can use type: gcp-types/secretmanager-v1:projects.locations.secrets.versions.access but requires more effort.

Deployment Manager:

gcloud deployment-manager deployments create my-deployment --config config.yaml
gcloud deployment-manager deployments update my-deployment --config new-config.yaml
gcloud deployment-manager deployments delete my-deployment
gcloud deployment-manager deployments list
gcloud deployment-manager deployments describe my-deployment

Terraform:

terraform init
terraform plan -out=tfplan
terraform apply tfplan
gsutil versioning set on gs://my-bucket  # Enable for remote state
gcloud storage buckets create gs://my-bucket --location=us-central1 --uniform-bucket-level-access
gsutil iam ch serviceAccount:terraform-sa@project.iam.gserviceaccount.com:objectAdmin gs://my-bucket

A fintech startup wants to deploy a hybrid infrastructure across GCP and AWS. They choose Terraform because its multi-cloud provider architecture allows them to manage both clouds from a single codebase. They store state in a GCS bucket with versioning and use a remote backend configuration in main.tf:

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

They encounter a common issue: when two engineers run terraform apply simultaneously, the state file can become corrupted. To prevent this, they enable state locking using GCS object lease (Terraform's built-in locking mechanism). The team also uses Terraform Cloud workspaces to separate dev, staging, and prod environments. A mistake they made early on was storing state locally — after a laptop crash, they lost the state and had to manually import 50+ resources. Now they mandate remote state with versioning and enforce access controls via IAM.

A large enterprise running exclusively on GCP uses Deployment Manager for its simplicity and tight integration with Google Cloud Console. They deploy a standard three-tier web application (load balancer, managed instance group, Cloud SQL) using a Python template that accepts environment variables. The template generates a config with 20+ resources. They use the --preview flag in CI/CD to validate changes before merging. A challenge they face is that Deployment Manager does not support complex conditionals in YAML alone — they must use Python templates, which require additional testing. They also discovered that Deployment Manager does not automatically detect when a resource is manually deleted; the deployment remains in a 'deployed' state but the resource is gone. To recover, they must run an update with the same config, which recreates the missing resource.

A DevOps team uses Terraform for core infrastructure (VPCs, subnets, firewall rules) because of its drift detection and modularity. For application-specific resources that change frequently (e.g., Cloud Functions, Pub/Sub topics), they use Deployment Manager with YAML configs that are generated by their CI/CD pipeline. This hybrid approach leverages the strengths of each tool. The key pitfall is that Terraform state and Deployment Manager state are separate — if both tools manage the same resource, conflicts occur. They mitigate this by clearly dividing resource ownership. For example, Terraform owns networking, Deployment Manager owns serverless resources. They use import commands to bring existing resources under management if needed.