Terraform vs Deployment Manager decision in GCP - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Choosing Infrastructure as Code Tool for Multi-Cloud

You want to manage infrastructure across Google Cloud and AWS with a single tool. Which option best supports this goal?

A Use Terraform because it supports multiple cloud providers including Google Cloud and AWS.

B Use Deployment Manager because it is native to Google Cloud and supports AWS as well.

C Use Deployment Manager because it has built-in multi-cloud orchestration features.

D Use Terraform only for AWS and Deployment Manager only for Google Cloud, managing them separately.

💡 Hint

Think about which tool supports multiple clouds natively.

Terraform supports many cloud providers including Google Cloud and AWS, making it suitable for multi-cloud management. Deployment Manager is specific to Google Cloud only.

❓ Architecture

intermediate

Infrastructure State Management in Terraform vs Deployment Manager

You want to keep track of your infrastructure changes and state securely. Which tool automatically manages state remotely by default?

A Deployment Manager, which stores state files automatically in Google Cloud Storage.

B Terraform, which supports remote state storage in Google Cloud Storage or other backends.

C Terraform, which stores state only locally and requires manual backup.

D Deployment Manager, which does not track state and requires manual state management.

💡 Hint

Consider how each tool handles the record of deployed resources.

Terraform uses state files to track infrastructure and supports remote backends like Google Cloud Storage for secure state management. Deployment Manager does not use state files in the same way.

❓ security

advanced

Managing Secrets in Terraform vs Deployment Manager

You need to securely manage sensitive data like API keys in your infrastructure code. Which option correctly describes the best practice?

A Use Deployment Manager with inline secrets encrypted by default.

B Store secrets in Terraform variables files checked into version control.

C Use Terraform with integration to Google Secret Manager to reference secrets without hardcoding them.

D Embed secrets directly in Deployment Manager YAML files for simplicity.

💡 Hint

Think about how to avoid exposing secrets in code repositories.

Terraform can integrate with Google Secret Manager to securely reference secrets without exposing them in code. Deployment Manager does not provide built-in secret management and embedding secrets in YAML is insecure.

✅ Best Practice

advanced

Modular Infrastructure Code in Terraform vs Deployment Manager

You want to reuse infrastructure code components across projects. Which tool provides better support for modular and reusable code?

A Terraform, which supports modules to package and reuse infrastructure code easily.

B Deployment Manager, which uses templates but lacks a strong module system.

C Deployment Manager, which encourages copy-pasting YAML files for reuse.

D Terraform, which requires duplicating code for each project without modules.

💡 Hint

Consider which tool has built-in features for code reuse and sharing.

Terraform has a robust module system that allows packaging infrastructure code for reuse and sharing. Deployment Manager uses templates but its reuse capabilities are limited compared to Terraform modules.

❓ service_behavior

expert

Handling Drift Detection in Terraform vs Deployment Manager

You want to detect when infrastructure changes outside your code happen (drift). Which tool provides built-in drift detection and how does it behave?

A Deployment Manager automatically detects drift and reverts changes without user intervention.

B Deployment Manager requires manual scripts to detect drift as it has no built-in support.

C Terraform does not detect drift and blindly applies changes without comparison.

D Terraform detects drift during plan/apply by comparing real infrastructure state with the state file and shows differences.

💡 Hint

Think about how each tool compares actual resources to declared code.

Terraform compares the current infrastructure state with the saved state file during planning and alerts users to drift. Deployment Manager lacks automatic drift detection and requires manual checks.

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