GCS backend configuration in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct GCS backend configuration block

Which Terraform backend configuration block correctly sets up Google Cloud Storage (GCS) as the backend with bucket name my-terraform-state and prefix env/prod?

A

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

B

terraform {
  backend "gcs" {
    bucket_name = "my-terraform-state"
    prefix = "env/prod"
  }
}

C

terraform {
  backend "gcs" {
    bucket = "my-terraform-state"
    path = "env/prod"
  }
}

D

terraform {
  backend "gcs" {
    bucket = "my-terraform-state"
    prefix_path = "env/prod"
  }
}

💡 Hint

The GCS backend requires the bucket name under the key 'bucket' and the state file path prefix under 'prefix'.

The correct keys for GCS backend are 'bucket' for the bucket name and 'prefix' for the folder path inside the bucket. Other keys like 'bucket_name', 'path', or 'prefix_path' are invalid and cause errors.

❓ service_behavior

intermediate

What happens if the GCS backend bucket does not exist?

When Terraform initializes with a GCS backend configuration pointing to a non-existent bucket, what is the expected behavior?

A Terraform creates a new bucket with a default name and continues.

B Terraform creates the bucket automatically and proceeds with initialization.

C Terraform ignores the missing bucket and uses local state instead.

D Terraform throws an error indicating the bucket does not exist and stops initialization.

💡 Hint

Terraform requires the backend storage bucket to exist before initialization.

Terraform does not create GCS buckets automatically. If the bucket does not exist, initialization fails with an error indicating the missing bucket.

❓ security

advanced

Which IAM role is required for Terraform to write state to a GCS backend?

To allow Terraform to store and update state files in a GCS bucket, which minimum IAM role should be granted to the service account used by Terraform?

A roles/storage.objectAdmin

B roles/storage.objectViewer

C roles/storage.admin

D roles/storage.objectCreator

💡 Hint

Terraform needs permissions to read, write, and delete objects in the bucket.

The 'roles/storage.objectAdmin' role allows full control over objects in the bucket, including creating, updating, and deleting state files. 'objectViewer' is read-only, 'objectCreator' cannot delete or overwrite, and 'storage.admin' is broader than needed.

❓ Architecture

advanced

How to configure Terraform backend for multiple environments using GCS?

You want to manage separate Terraform states for 'dev' and 'prod' environments using the same GCS bucket named tf-states. Which backend configuration correctly isolates the states?

A

terraform {
  backend "gcs" {
    bucket = "tf-states"
    prefix = "dev"
  }
}

terraform {
  backend "gcs" {
    bucket = "tf-states"
    prefix = "prod"
  }
}

B

terraform {
  backend "gcs" {
    bucket = "tf-states"
    prefix = "env/dev"
  }
}

terraform {
  backend "gcs" {
    bucket = "tf-states"
    prefix = "env/prod"
  }
}

C Use one backend block with prefix = "dev,prod" to manage both environments.

D Create separate buckets named tf-states-dev and tf-states-prod instead of using prefixes.

💡 Hint

Use different prefixes inside the same bucket to separate state files per environment.

Terraform backend configuration supports one backend block per configuration. To manage multiple environments, use different prefixes inside the same bucket. Option B is invalid because you cannot have two backend blocks in one config. Option B is invalid syntax. Option B is a valid approach but not a backend configuration example.

✅ Best Practice

expert

What is the recommended way to secure Terraform state files in GCS?

Which practice best secures Terraform state files stored in a GCS bucket?

A Disable bucket versioning and allow full storage admin access to all team members.

B Use default Google-managed encryption and grant all users read access for transparency.

C Enable bucket versioning, restrict IAM roles to least privilege, and enable CMEK (Customer Managed Encryption Keys).

D Make the bucket public for easy access and enable lifecycle rules to delete old states.

💡 Hint

Protect state files by controlling access, encrypting data, and keeping history.

Best practice is to enable versioning to keep history, restrict IAM roles to only those who need access, and use CMEK for stronger encryption control. Public access or overly broad permissions expose sensitive data and risk state corruption.

Practice

1. What is the main purpose of configuring a GCS backend in Terraform?

easy

A. To create a Google Cloud Storage bucket

B. To store Terraform state files securely in Google Cloud Storage

C. To deploy virtual machines automatically

D. To run Terraform commands faster

Solution

1. Step 1: Understand Terraform state management

   Terraform uses state files to keep track of resources it manages.

2. Step 2: Role of GCS backend

   Configuring GCS backend stores these state files safely in Google Cloud Storage, enabling sharing and locking.

3. Final Answer:

   To store Terraform state files securely in Google Cloud Storage -> Option B

4. Quick Check:

   GCS backend = state storage [OK]

Hint: Remember: backend stores state files remotely [OK]

Common Mistakes:

• Confusing backend with resource deployment
• Thinking backend creates buckets automatically
• Assuming backend speeds up Terraform commands

2. Which of the following is the correct syntax to specify the GCS backend in Terraform?

easy

A. backend "gcs" { bucket: "my-bucket" prefix: "terraform/state" }

B. backend gcs { bucket: "my-bucket", prefix: "terraform/state" }

C. backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" }

D. backend "gcs" ( bucket = "my-bucket", prefix: "terraform/state" )

Solution

1. Step 1: Review Terraform backend block syntax

   The backend block uses the format backend "type" { key = value } with equals signs and no commas.

2. Step 2: Identify correct syntax for GCS backend

   backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" } uses correct quotes, equals signs, and braces without commas, matching Terraform syntax.

3. Final Answer:

   backend "gcs" { bucket = "my-bucket" prefix = "terraform/state" } -> Option C

4. Quick Check:

   Correct syntax uses equals and braces [OK]

Hint: Use equals signs and braces, no commas in backend block [OK]

Common Mistakes:

• Using colons instead of equals signs
• Adding commas between lines
• Using parentheses instead of braces

3. Given this backend configuration:

terraform {
  backend "gcs" {
    bucket = "my-terraform-state"
    prefix = "env/prod"
    project = "my-gcp-project"
  }
}

Where will Terraform store the state file?

medium

A. In the bucket "env/prod" under the path "my-terraform-state/terraform.tfstate"

B. Locally on the machine running Terraform

C. In the default bucket of the project "my-gcp-project" without prefix

D. In the bucket "my-terraform-state" under the path "env/prod/terraform.tfstate" in project "my-gcp-project"

Solution

1. Step 1: Understand bucket and prefix usage

   The bucket is "my-terraform-state" and prefix "env/prod" means state files go under that path inside the bucket.

2. Step 2: Confirm project usage

   The project "my-gcp-project" specifies which GCP project owns the bucket, confirming location.

3. Final Answer:

   In the bucket "my-terraform-state" under the path "env/prod/terraform.tfstate" in project "my-gcp-project" -> Option D

4. Quick Check:

   Bucket + prefix + project = state location [OK]

Hint: Bucket + prefix = path for state file [OK]

Common Mistakes:

• Mixing bucket and prefix names
• Assuming local storage instead of remote
• Ignoring the project field

4. You wrote this backend block:

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

What is the error and how to fix it?

medium

A. Missing quotes around bucket name; add quotes like "my-bucket"

B. Prefix should be a number, not a string

C. Backend type should be "google" instead of "gcs"

D. Bucket name cannot contain dashes

Solution

1. Step 1: Identify syntax error in bucket value

   The bucket name must be a string, so it needs quotes around it.

2. Step 2: Correct the bucket value

   Adding quotes fixes the syntax: bucket = "my-bucket".

3. Final Answer:

   Missing quotes around bucket name; add quotes like "my-bucket" -> Option A

4. Quick Check:

   Strings need quotes in Terraform config [OK]

Hint: Always quote string values in backend config [OK]

Common Mistakes:

• Leaving string values unquoted
• Confusing backend type names
• Thinking bucket names cannot have dashes

5. You want to share Terraform state safely among your team using GCS backend. Which combination of settings ensures state locking and avoids conflicts?

hard

A. Use bucket with versioning enabled, set prefix, and enable project with IAM permissions

B. Use bucket without versioning, no prefix, and no project specified

C. Use local backend with manual file sharing

D. Use bucket with public access and no prefix

Solution

1. Step 1: Enable bucket versioning and set prefix

   Versioning keeps history of state files; prefix organizes states per environment.

2. Step 2: Specify project and IAM permissions

   Project and permissions ensure team members can access and lock the state to avoid conflicts.

3. Final Answer:

   Use bucket with versioning enabled, set prefix, and enable project with IAM permissions -> Option A

4. Quick Check:

   Versioning + prefix + permissions = safe shared state [OK]

Hint: Enable versioning and IAM for safe shared state [OK]

Common Mistakes:

• Not enabling versioning on bucket
• Omitting prefix causing state overwrites
• Using public buckets risking security