State management in GCP - Step-by-Step Execution

Process Flow - State management

Start Infrastructure Deployment

↓

Check Current State

↓

Compare Desired vs Current

↓

No Changes

↓

End Process

↓

Update State Storage

↓

End Process

This flow shows how GCP manages infrastructure state by checking current state, comparing with desired, applying changes if needed, and updating the stored state.

Execution Sample

GCP

terraform init
terraform plan
terraform apply

These commands initialize, plan, and apply infrastructure changes while managing state.

Process Table

Step	Action	State Checked	Changes Detected	Result
1	terraform init	No state yet	N/A	Backend configured, ready
2	terraform plan	Current state read	Yes	Shows changes to apply
3	terraform apply	Current state read	Yes	Applies changes
4	Update state storage	State updated	N/A	State saved for next run
5	terraform plan (next run)	Updated state read	No	No changes needed

💡 No changes detected after state update, deployment is stable

Status Tracker

Variable	Start	After Init	After Plan	After Apply	Final
State Storage	Empty	Configured backend	Read current state	Updated with changes	Saved updated state

Key Moments - 2 Insights

Why does terraform plan show changes before apply?

Because terraform compares the desired configuration with the current state (see execution_table step 2) and detects differences to apply.

What happens if state storage is lost?

Terraform cannot track existing resources properly, leading to potential re-creation or errors. State storage is critical (see variable_tracker).

Visual Quiz - 3 Questions

Look at the execution_table, what is the state storage status after 'terraform apply'?

A Configured backend

B Empty

C Updated with changes

D No state

💡 Hint

Check the 'State Checked' and 'Result' columns at step 4 in execution_table

At which step does terraform detect no changes needed?

A Step 2

B Step 5

C Step 3

D Step 1

💡 Hint

Look for 'No changes needed' in the 'Result' column in execution_table

If the state storage was lost after apply, what would happen on next plan?

A Terraform would re-create all resources

B Terraform would fail to run

C Terraform would detect no changes

D Terraform would skip plan

💡 Hint

Refer to key_moments about importance of state storage

Concept Snapshot

State management in GCP infrastructure tools like Terraform:
- Stores current resource info in state files
- Compares desired config with stored state
- Plans changes before applying
- Updates state after apply
- Critical to keep state safe and consistent

Full Transcript

State management in cloud infrastructure means keeping track of what resources exist and their settings. Tools like Terraform use a state file to remember current resources. When you run 'terraform plan', it reads this state and compares it to your desired setup. If differences exist, it shows what will change. Then 'terraform apply' makes those changes and updates the state file. This process ensures your cloud matches your configuration. Losing the state file can cause problems because the tool forgets what it created. So managing state carefully is key to smooth cloud deployments.

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