State management in GCP - Commands & Configuration

Introduction

When you create cloud resources, you need to keep track of what exists and how it is configured. State management helps you remember the current setup so you can update or delete resources safely without losing track.

When you want to deploy a virtual machine and later update its settings without recreating it.

When you manage multiple cloud resources and want to keep their configurations consistent.

When you need to share the current setup with your team to avoid conflicts.

When you want to roll back changes if something goes wrong during deployment.

When you automate cloud infrastructure updates and need to know what changed.

Commands

This command creates a deployment in Google Cloud using the specified configuration file. It saves the state of the deployed resources so you can manage them later.

Terminal

gcloud deployment-manager deployments create example-deployment --config example-config.yaml

Expected Output

Create operation operation-1234567890abcdef started...

→

--config - Specifies the configuration file describing the resources to deploy

This command shows the current state of the deployment, including what resources exist and their status.

Terminal

gcloud deployment-manager deployments describe example-deployment

Expected Output

name: example-deployment

id: 1234567890123456789

operation:

  status: DONE

  operationType: insert

  targetLink: https://www.googleapis.com/compute/v1/projects/my-project/zones/us-central1-a/instances/example-instance

  ...

This command updates the existing deployment with changes from the configuration file, using the saved state to apply only necessary changes.

Terminal

gcloud deployment-manager deployments update example-deployment --config example-config.yaml

Expected Output

Update operation operation-abcdef1234567890 started...

→

--config - Specifies the updated configuration file

This command deletes the deployment and all its resources, cleaning up the state so nothing is left behind.

Terminal

gcloud deployment-manager deployments delete example-deployment

Expected Output

Delete operation operation-0987654321fedcba started...

Key Concept

If you remember nothing else from this pattern, remember: state management keeps track of your cloud resources so updates and deletions happen safely and correctly.

Common Mistakes

Trying to update a deployment without saving or using the correct configuration file.

The deployment manager cannot know what changed and may fail or overwrite resources incorrectly.

Always use the latest configuration file that matches the current state before updating.

Deleting resources manually without deleting the deployment.

The deployment state still thinks the resources exist, causing errors in future operations.

Delete resources through the deployment manager to keep state consistent.

Summary

Create a deployment with a configuration file to save the state of your cloud resources.

Check the deployment state to see what resources exist and their status.

Update the deployment using the saved state to apply only necessary changes.

Delete the deployment to remove all resources and clear the state.

Practice

1. What is the main purpose of state management in cloud infrastructure?

easy

A. To reduce the cost of cloud services

B. To increase the speed of cloud resource creation

C. To automatically fix errors in cloud resources

D. To keep track of the current setup of cloud resources

Solution

1. Step 1: Understand what state management means

   State management records the current status and configuration of cloud resources.

2. Step 2: Identify the main goal of state management

   Its main goal is to keep track of resources so changes can be managed safely and consistently.

3. Final Answer:

   To keep track of the current setup of cloud resources -> Option D

4. Quick Check:

   State management = tracking resource setup [OK]

Hint: State management means tracking resource setup [OK]

Common Mistakes:

• Thinking it speeds up resource creation
• Believing it fixes errors automatically
• Assuming it reduces cloud costs directly

2. Which of the following is the correct way to configure a remote backend in Terraform using Google Cloud Storage?

easy

A. backend "gcs" { bucket = "my-bucket" path = "terraform/state" }

B. backend "gcp" { bucket = "my-bucket" path = "terraform/state" }

C. backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" credentials = "path/to/key.json" }

D. backend "google" { bucket = "my-bucket" prefix = "terraform/state" }

Solution

1. Step 1: Identify the correct backend type for Google Cloud Storage

   The correct backend type is "gcs" for Google Cloud Storage in Terraform.

2. Step 2: Check required configuration keys

   Bucket name and prefix are required; credentials path is optional but recommended for authentication.

3. Final Answer:

   backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" credentials = "path/to/key.json" } -> Option C

4. Quick Check:

   Use "gcs" backend with bucket, prefix, and credentials [OK]

Hint: Use backend "gcs" with bucket and prefix keys [OK]

Common Mistakes:

• Using wrong backend type like "gcp" or "google"
• Missing credentials for authentication
• Using incorrect keys like 'path' instead of 'prefix'

3. Given this Terraform snippet using a remote backend:

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

resource "google_storage_bucket" "example" {
  name     = "example-bucket"
  location = "US"
}

What happens when two team members run terraform apply at the same time?

medium

A. Terraform will lock the state file to prevent simultaneous changes

B. Terraform will merge both changes automatically without conflicts

C. Terraform will overwrite the state file causing loss of data

D. Terraform will create duplicate resources in Google Cloud Storage

Solution

1. Step 1: Understand remote backend behavior with GCS

   Terraform uses state locking with remote backends like GCS to prevent concurrent changes.

2. Step 2: Identify what happens on simultaneous apply

   When two users run apply simultaneously, Terraform locks the state file so only one can proceed at a time.

3. Final Answer:

   Terraform will lock the state file to prevent simultaneous changes -> Option A

4. Quick Check:

   Remote backend locks state to avoid conflicts [OK]

Hint: Remote backends lock state to avoid conflicts [OK]

Common Mistakes:

• Thinking Terraform merges changes automatically
• Assuming state file is overwritten without warning
• Believing duplicate resources are created automatically

4. You configured Terraform with a remote backend on GCS, but when running terraform apply, you get an error saying the state file is locked indefinitely. What is the best way to fix this?

medium

A. Delete the state file from the GCS bucket manually

B. Run terraform force-unlock with the lock ID

C. Change the backend configuration to local state

D. Restart your computer and try again

Solution

1. Step 1: Understand the cause of indefinite lock

   State file locks can remain if a previous operation was interrupted or crashed.

2. Step 2: Use Terraform's force-unlock command

   The correct fix is to run terraform force-unlock with the lock ID to safely remove the lock.

3. Final Answer:

   Run terraform force-unlock with the lock ID -> Option B

4. Quick Check:

   Use force-unlock to clear stuck state locks [OK]

Hint: Use terraform force-unlock to clear stuck locks [OK]

Common Mistakes:

• Deleting state file manually causing data loss
• Switching to local state without fixing lock
• Restarting computer does not clear remote locks

5. Your team wants to manage multiple environments (dev, staging, prod) using Terraform with GCS backend. Which approach best ensures isolated state files and safe collaboration?

hard

A. Use one GCS bucket with different prefixes for each environment

B. Use separate GCS buckets for each environment with the same prefix

C. Use local state files stored on each developer's machine

D. Use one GCS bucket and store all environments in the same prefix

Solution

1. Step 1: Understand environment isolation needs

   Each environment should have its own state to avoid conflicts and accidental changes.

2. Step 2: Choose backend configuration for isolation and collaboration

   Using one bucket with different prefixes (folders) isolates states while keeping management simple and collaborative.

3. Final Answer:

   Use one GCS bucket with different prefixes for each environment -> Option A

4. Quick Check:

   Different prefixes isolate environments in one bucket [OK]

Hint: Use prefixes in one bucket to separate environments [OK]

Common Mistakes:

• Using same prefix causes state conflicts
• Using local state prevents team collaboration
• Using multiple buckets complicates management unnecessarily