Terraform vs Deployment Manager decision in GCP - Visual Side-by-Side Comparison

Process Flow - Terraform vs Deployment Manager decision

Start: Need Infrastructure as Code

↓

Choose Tool: Terraform or Deployment Manager

↓

Terraform: Multi-cloud, Community

↓

Write Config in HCL

↓

Plan & Apply Changes

↓

Manage State File

↓

Supports Many Providers

↓

Decision: Based on needs & preferences

This flow shows the decision process between Terraform and Deployment Manager based on features and use cases.

Execution Sample

GCP

# Pseudocode for decision
if need_multi_cloud:
    use = "Terraform"
else:
    use = "Deployment Manager"

This simple decision checks if multi-cloud support is needed to choose the tool.

Process Table

Step	Condition Checked	Result	Tool Chosen	Reason
1	Need multi-cloud support?	Yes	Terraform	Terraform supports many clouds
2	Need GCP native integration?	No	Terraform	Terraform can integrate but is not native
3	Prefer YAML/JSON configs?	Yes	Deployment Manager	Deployment Manager uses YAML/JSON
4	Need state management by GCP?	Yes	Deployment Manager	Deployment Manager manages state automatically
5	Require community modules?	Yes	Terraform	Terraform has large community modules
6	Need only GCP resources?	Yes	Deployment Manager	Deployment Manager focuses on GCP
7	Decision based on above	N/A	Depends on needs	Choose tool matching requirements

💡 Decision ends when tool matches user needs and preferences

Status Tracker

Variable	Start	After Step 1	After Step 3	Final
need_multi_cloud	undefined	true	true	true
prefer_yaml_json	undefined	undefined	true	true
state_managed_by_gcp	undefined	undefined	true	true
tool_chosen	undefined	Terraform	Deployment Manager	Depends on needs

Key Moments - 3 Insights

Why choose Terraform if Deployment Manager is native to GCP?

Terraform supports multiple clouds and has a large community, so if you plan to manage resources beyond GCP or want reusable modules, Terraform is better (see execution_table steps 1 and 5).

Does Deployment Manager require manual state management?

No, Deployment Manager manages state automatically within GCP, unlike Terraform which requires you to manage state files (see execution_table step 4).

Can you use YAML/JSON with Terraform?

Terraform primarily uses HCL, not YAML/JSON, so if you prefer YAML/JSON configs, Deployment Manager fits better (see execution_table step 3).

Visual Quiz - 3 Questions

Look at the execution_table, which tool is chosen when multi-cloud support is needed?

A Deployment Manager

B Terraform

C Both

D Neither

💡 Hint

Check step 1 in execution_table where multi-cloud support leads to Terraform

At which step does the decision consider automatic state management by GCP?

A Step 4

B Step 5

C Step 2

D Step 6

💡 Hint

Look at execution_table step 4 about state management

If you prefer YAML/JSON configs, which tool does the execution_table suggest?

A Either tool

B Terraform

C Deployment Manager

D None

💡 Hint

See execution_table step 3 about config format preference

Concept Snapshot

Terraform vs Deployment Manager decision:
- Terraform: uses HCL, multi-cloud, community modules, manual state management
- Deployment Manager: uses YAML/JSON, GCP native, automatic state management
- Choose Terraform for multi-cloud or community support
- Choose Deployment Manager for GCP-only and native integration
- Decision depends on your project needs and preferences

Full Transcript

This visual execution shows how to decide between Terraform and Deployment Manager for infrastructure as code on Google Cloud. The flow starts by identifying if multi-cloud support is needed. If yes, Terraform is chosen because it supports many clouds and has a large community. If the preference is for YAML or JSON configuration files and automatic state management by GCP, Deployment Manager is preferred. The execution table traces decision steps checking conditions like multi-cloud need, config format preference, and state management. Variables track these conditions and the chosen tool. Key moments clarify common confusions such as why Terraform is chosen despite Deployment Manager being native, and how state management differs. The quiz tests understanding of which tool fits which condition. The snapshot summarizes key differences and decision points. This helps beginners visually understand the decision process for choosing infrastructure as code tools on GCP.

Practice

1. Which tool is best described as Google Cloud's native infrastructure management service?

easy

A. Deployment Manager

B. Terraform

C. Ansible

D. Chef

Solution

1. Step 1: Understand native tools in GCP

   Deployment Manager is built by Google specifically for managing GCP resources.

2. Step 2: Compare with other tools

   Terraform is multi-cloud and not native to GCP, while Ansible and Chef are configuration management tools, not native GCP infrastructure managers.

3. Final Answer:

   Deployment Manager -> Option A

4. Quick Check:

   Native GCP tool = Deployment Manager [OK]

Hint: Native GCP tool means Deployment Manager [OK]

Common Mistakes:

• Confusing Terraform as native to GCP
• Mixing configuration tools with infrastructure tools
• Assuming multi-cloud tools are native

2. Which syntax snippet correctly initializes a Terraform configuration for Google Cloud?

easy

A. resource "gcp_project" { name = "my-project" }

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

C. deployment "my-deployment" { config: "config.yaml" }

D. service "google" { project = "my-project" }

Solution

1. Step 1: Identify Terraform provider syntax

   Terraform uses the keyword 'provider' with the provider name and configuration inside curly braces.

2. Step 2: Check other options

   resource "gcp_project" { name = "my-project" } uses incorrect resource type, C is Deployment Manager style, D uses invalid keyword 'service'.

3. Final Answer:

   provider "google" { project = "my-project" region = "us-central1" } -> Option B

4. Quick Check:

   Terraform provider block = provider "google" { project = "my-project" region = "us-central1" } [OK]

Hint: Terraform uses 'provider' block for cloud setup [OK]

Common Mistakes:

• Confusing Deployment Manager syntax with Terraform
• Using wrong keywords like 'service' instead of 'provider'
• Incorrect resource types for Terraform

3. Given this Terraform snippet:

resource "google_compute_instance" "vm" {
  name         = "test-vm"
  machine_type = "e2-medium"
  zone         = "us-central1-a"
  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-10"
    }
  }
  network_interface {
    network = "default"
  }
}

What will happen when you run terraform apply?

medium

A. A new VM instance named 'test-vm' will be created in us-central1-a zone.

B. Terraform will throw a syntax error due to missing provider block.

C. The VM will be created but without a boot disk.

D. Terraform will delete all existing instances in the default network.

Solution

1. Step 1: Analyze resource block

   The resource defines a Google Compute VM named 'test-vm' with specified machine type, zone, boot disk image, and network interface.

2. Step 2: Understand Terraform apply behavior

   Terraform will create the VM as described if the provider is configured elsewhere; missing provider block causes error only if not configured.

3. Final Answer:

   A new VM instance named 'test-vm' will be created in us-central1-a zone. -> Option A

4. Quick Check:

   Terraform creates resources as defined [OK]

Hint: Terraform creates resources exactly as defined [OK]

Common Mistakes:

• Assuming missing provider block always causes error
• Thinking boot disk is optional and missing
• Believing Terraform deletes unrelated resources

4. You wrote a Deployment Manager config but get an error: Invalid resource type. What is the most likely cause?

medium

A. Missing project ID in the config file

B. Not enabling the Compute Engine API

C. Incorrect indentation in YAML file

D. Using a Terraform resource type in Deployment Manager config

Solution

1. Step 1: Understand resource types in Deployment Manager

   Deployment Manager requires resource types specific to GCP and its own syntax, not Terraform resource types.

2. Step 2: Identify error cause

   Using Terraform resource types in Deployment Manager config causes 'Invalid resource type' error.

3. Final Answer:

   Using a Terraform resource type in Deployment Manager config -> Option D

4. Quick Check:

   Resource types must match tool syntax [OK]

Hint: Use correct resource types per tool [OK]

Common Mistakes:

• Confusing Terraform and Deployment Manager resource types
• Ignoring API enablement errors
• Assuming YAML indentation causes resource type errors

5. Your team needs to manage infrastructure across multiple clouds with a single tool and prefers simple, readable syntax. Which tool should you choose?

hard

A. Deployment Manager because it is native to GCP

B. Use Deployment Manager with custom scripts for multi-cloud

C. Terraform because it supports multiple clouds and has simple syntax

D. Manual scripting with gcloud CLI for flexibility

Solution

1. Step 1: Analyze multi-cloud support

   Deployment Manager only supports GCP, so it cannot manage multiple clouds.

2. Step 2: Consider syntax and team preference

   Terraform supports multiple clouds and uses simple, readable syntax, fitting team needs.

3. Step 3: Evaluate other options

   Manual scripting is error-prone and less maintainable; Deployment Manager with scripts is complex and limited to GCP.

4. Final Answer:

   Terraform because it supports multiple clouds and has simple syntax -> Option C

5. Quick Check:

   Multi-cloud + simple syntax = Terraform [OK]

Hint: Multi-cloud needs point to Terraform [OK]

Common Mistakes:

• Choosing Deployment Manager for multi-cloud
• Thinking manual scripts are simpler
• Assuming Deployment Manager can be extended easily for other clouds