Team workflows and collaboration in Terraform - Mini Project: Build & Apply

Team workflows and collaboration

📖 Scenario: Your team is managing cloud infrastructure using Terraform. To work together smoothly, you need to set up a shared backend and organize your Terraform configuration files properly.

🎯 Goal: Build a Terraform configuration that uses a remote backend for state storage and defines a simple resource. This setup will help your team collaborate safely and avoid conflicts.

📋 What You'll Learn

Create a Terraform configuration file with a backend block for remote state storage

Define a variable for the storage bucket name

Add a simple AWS S3 bucket resource using the variable

Configure the backend with the bucket variable and region

💡 Why This Matters

🌍 Real World

Teams managing cloud infrastructure use Terraform remote backends to share state files safely and avoid conflicts during collaboration.

💼 Career

Understanding Terraform backend configuration and resource definition is essential for cloud engineers and DevOps professionals working in team environments.

1

Create the initial Terraform configuration with a variable

Create a Terraform configuration file named main.tf. Inside it, define a variable called bucket_name with type string and default value "team-terraform-state".

Terraform

# Define a variable called bucket_name with default "team-terraform-state"
# Your code here

Hint

Use the variable block to define bucket_name with type string and default value.

2

Add a backend configuration for remote state

In the same main.tf file, add a terraform block with a backend of type s3. Set the bucket to use the variable bucket_name and set region to "us-east-1".

Terraform

variable "bucket_name" {
  type    = string
  default = "team-terraform-state"
}

# Add terraform backend configuration here
# Your code here

Hint

Use the terraform block with backend "s3" and set bucket and region accordingly.

3

Define an AWS S3 bucket resource using the variable

Add a resource block in main.tf to create an AWS S3 bucket. Name the resource team_bucket of type aws_s3_bucket. Set the bucket attribute to the variable bucket_name.

Terraform

variable "bucket_name" {
  type    = string
  default = "team-terraform-state"
}

terraform {
  backend "s3" {
    bucket = "team-terraform-state"
    region = "us-east-1"
  }
}

# Add aws_s3_bucket resource named team_bucket here
# Your code here

Hint

Use a resource block with type aws_s3_bucket and name team_bucket. Set the bucket attribute to var.bucket_name.

4

Complete the configuration with provider setup

Add a provider block for AWS in main.tf with region set to "us-east-1".

Terraform

variable "bucket_name" {
  type    = string
  default = "team-terraform-state"
}

terraform {
  backend "s3" {
    bucket = "team-terraform-state"
    region = "us-east-1"
  }
}

resource "aws_s3_bucket" "team_bucket" {
  bucket = var.bucket_name
}

# Add AWS provider block here
# Your code here

Hint

Use a provider "aws" block and set region to "us-east-1".

Practice

1. What is the main purpose of using a remote backend in Terraform when working in a team?

easy

A. To create multiple copies of the state file on each team member's machine

B. To speed up Terraform plan and apply commands locally

C. To store the Terraform state file centrally and enable state locking

D. To automatically generate documentation for the infrastructure

Solution

1. Step 1: Understand remote backend role

   A remote backend stores the Terraform state file in a shared location accessible by the team.

2. Step 2: Recognize state locking benefit

   It also enables locking to prevent multiple people from changing infrastructure at the same time, avoiding conflicts.

3. Final Answer:

   To store the Terraform state file centrally and enable state locking -> Option C

4. Quick Check:

   Remote backend = central state + locking [OK]

Hint: Remote backend means shared state and locking [OK]

Common Mistakes:

• Thinking remote backend speeds up local commands
• Confusing remote backend with documentation tools
• Believing remote backend duplicates state locally

2. Which of the following is the correct syntax to configure an S3 remote backend in Terraform?

easy

A. backend "s3" { bucket: "my-bucket" key: "state.tfstate" region: "us-east-1" }

B. backend "s3" { bucket = "my-bucket" key = "state.tfstate" region = "us-east-1" }

C. backend s3 { bucket: "my-bucket", key: "state.tfstate", region: "us-east-1" }

D. backend "s3" (bucket = "my-bucket", key = "state.tfstate", region = "us-east-1")

Solution

1. Step 1: Recall Terraform backend block syntax

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

2. Step 2: Identify correct syntax for S3 backend

   backend "s3" { bucket = "my-bucket" key = "state.tfstate" region = "us-east-1" } correctly uses equals signs and quotes inside curly braces for bucket, key, and region.

3. Final Answer:

   backend "s3" { bucket = "my-bucket" key = "state.tfstate" region = "us-east-1" } -> Option B

4. Quick Check:

   Backend block uses equals and quotes [OK]

Hint: Backend blocks use equals signs and quotes inside braces [OK]

Common Mistakes:

• Using colons instead of equals signs
• Omitting quotes around strings
• Using parentheses instead of braces

3. Given this Terraform configuration snippet for a remote backend:

terraform {
  backend "s3" {
    bucket = "team-state"
    key    = "prod/terraform.tfstate"
    region = "us-west-2"
  }
}

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

medium

A. Terraform will lock the state for the first apply and block the second until the first finishes

B. Terraform will allow both applies to run simultaneously, risking state corruption

C. Terraform will merge both applies automatically without conflicts

D. Terraform will delete the state file before the second apply

Solution

1. Step 1: Understand state locking with S3 backend

   The S3 backend supports state locking using DynamoDB or built-in locking to prevent concurrent changes.

2. Step 2: Identify behavior on concurrent applies

   When one user runs apply, Terraform locks the state. The second user is blocked until the lock is released.

3. Final Answer:

   Terraform will lock the state for the first apply and block the second until the first finishes -> Option A

4. Quick Check:

   Remote backend locks state during apply [OK]

Hint: Remote backend locks state to prevent concurrent changes [OK]

Common Mistakes:

• Assuming Terraform merges concurrent changes automatically
• Thinking state file is deleted on concurrent apply
• Believing concurrent applies run without locking

4. A team member reports that after configuring a remote backend, Terraform shows this error when running terraform init:

Error: Backend configuration changed! Please run "terraform init" to reinitialize.

What is the most likely cause and fix?

medium

A. The Terraform version is outdated; upgrade Terraform to fix the error

B. The remote backend bucket does not exist; create the bucket manually

C. The state file is corrupted; delete it and run terraform apply again

D. The backend block was modified; re-run terraform init to reinitialize the backend

Solution

1. Step 1: Understand backend configuration change

   Terraform detects changes in backend settings and requires reinitialization to update local config.

2. Step 2: Apply the correct fix

   Running terraform init again reloads backend config and fixes the error.

3. Final Answer:

   The backend block was modified; re-run terraform init to reinitialize the backend -> Option D

4. Quick Check:

   Backend changes require reinit [OK]

Hint: Backend changes need terraform init re-run [OK]

Common Mistakes:

• Deleting state file unnecessarily
• Assuming Terraform version is the cause
• Ignoring the need to reinitialize backend

5. Your team wants to ensure that all Terraform changes are reviewed before applying to production. Which combination of practices best supports this goal?

hard

A. Use version control with pull requests and require code reviews before merging Terraform changes

B. Allow direct edits to the production state file and run Terraform apply manually

C. Store Terraform state locally on each developer's machine and share plans via email

D. Disable remote backend locking to speed up multiple applies

Solution

1. Step 1: Identify collaboration best practices

   Version control with pull requests enables team review and approval of changes before applying.

2. Step 2: Recognize risks of other options

   Direct edits, local state, or disabling locking risk conflicts and unreviewed changes.

3. Final Answer:

   Use version control with pull requests and require code reviews before merging Terraform changes -> Option A

4. Quick Check:

   Code reviews + version control = safe collaboration [OK]

Hint: Use pull requests and code reviews for safe Terraform changes [OK]

Common Mistakes:

• Editing state files directly
• Sharing state locally without central backend
• Disabling locking risking conflicts