S3 backend configuration in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct S3 backend configuration for Terraform state

Which option correctly configures Terraform to use an S3 bucket named my-terraform-state in the us-west-2 region with encryption enabled and state locking using DynamoDB table terraform-lock?

A

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    region = "us-west-2"
    encryption = true
    dynamodb_table = "terraform-lock"
  }
}

B

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    region = "us-west-2"
    encrypt = true
    dynamodb_table = "terraform-lock"
  }
}

C

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    region = "us-west-2"
    encrypt = false
    dynamodb_table = "terraform-lock"
  }
}

D

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    region = "us-east-1"
    encrypt = true
    dynamodb_table = "terraform-lock"
  }
}

💡 Hint

Check the exact attribute names for encryption and region in the S3 backend block.

The correct attribute to enable encryption is encrypt = true. The region must match the bucket's region, which is us-west-2. Option B correctly sets these along with the DynamoDB table for state locking.

❓ service_behavior

intermediate

What happens if the DynamoDB table for state locking is missing?

If you configure Terraform to use an S3 backend with a DynamoDB table for state locking, but the DynamoDB table does not exist, what will happen when you run terraform init?

A Terraform will create the missing DynamoDB table automatically and proceed.

B Terraform will initialize successfully but will not perform state locking, risking concurrent state changes.

C Terraform will fail to initialize and return an error indicating the DynamoDB table is missing.

D Terraform will ignore the DynamoDB table setting and use local locking instead.

💡 Hint

Consider how Terraform enforces state locking with DynamoDB.

Terraform requires the DynamoDB table to exist before initialization. If the table is missing, terraform init will fail with an error to prevent unsafe concurrent state modifications.

❓ Architecture

advanced

Choose the best architecture for multi-region Terraform state storage

You want to store Terraform state files in S3 with high availability across multiple AWS regions. Which architecture best achieves this goal?

A Use a single S3 bucket in one region with cross-region replication enabled to replicate state files to other regions.

B Use a single S3 bucket in one region without replication and rely on AWS global infrastructure for availability.

C Create separate S3 buckets in each region and configure Terraform to switch backend buckets based on region.

D Store state files locally on each developer machine and sync manually across regions.

💡 Hint

Think about how S3 cross-region replication helps with availability and disaster recovery.

Using a single S3 bucket with cross-region replication ensures state files are available in multiple regions automatically, improving availability and disaster recovery. This is better than managing multiple buckets or local files.

❓ security

advanced

Identify the security best practice for S3 backend state encryption

Which option correctly describes the best practice to secure Terraform state files stored in an S3 backend?

A Enable server-side encryption with AWS KMS keys and restrict bucket access with IAM policies.

B Disable encryption to improve performance and rely on network security only.

C Use client-side encryption only and do not enable any server-side encryption.

D Make the S3 bucket public to allow easy access for all team members.

💡 Hint

Think about protecting sensitive state data at rest and controlling access.

Encrypting state files with AWS KMS keys ensures data is protected at rest. Restricting access with IAM policies limits who can read or modify the state, following security best practices.

✅ Best Practice

expert

Determine the impact of changing the S3 backend bucket after initial Terraform deployment

You initially configured Terraform to use an S3 backend bucket named bucket-a. After some deployments, you change the backend configuration to use bucket-b without migrating the state file. What will happen when you run terraform plan?

A Terraform will use the local state file and ignore the backend configuration.

B Terraform will automatically migrate the state file from <code>bucket-a</code> to <code>bucket-b</code> and continue normally.

C Terraform will fail with an error about missing state file in <code>bucket-b</code>.

D Terraform will treat the infrastructure as new and attempt to create all resources again.

💡 Hint

Consider how Terraform tracks resources using the state file location.

Changing the backend bucket without migrating the state causes Terraform to see no existing state in the new bucket. It assumes no resources exist and plans to create all resources anew.