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.