Terraform file organization - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Identify the correct Terraform file organization for a multi-environment setup

You have a Terraform project that manages infrastructure for two environments: production and staging. Which file organization below best separates environment-specific configurations while reusing common modules?

A Separate folders for each environment (prod/, staging/) each containing main.tf, variables.tf, and backend.tf files, plus a modules/ folder for reusable modules.

B A single main.tf file with all resources and variables for both environments mixed together.

C One folder with main.tf and variables.tf files, and environment variables set externally to switch environments.

D Multiple .tf files in the root folder named prod.tf, staging.tf, and modules.tf without folders.

💡 Hint

Think about how to isolate environment settings while sharing common code.

Option A is best because it uses separate folders per environment to isolate configs and a modules folder for shared code. This keeps environments clean and reusable.

✅ Best Practice

intermediate

Choose the best practice for Terraform state file management

Which Terraform file organization practice helps prevent state file conflicts when multiple team members work on the same infrastructure?

A Store the state file locally on each developer's machine.

B Use a remote backend like S3 or Terraform Cloud with locking enabled, and organize state files per environment.

C Keep all environment states in a single shared state file in the root folder.

D Commit the state file to the version control system along with .tf files.

💡 Hint

Think about collaboration and avoiding overwriting each other's work.

Option B is best because remote backends with locking prevent conflicts and organizing state per environment keeps states isolated.

❓ service_behavior

advanced

What happens if you mix provider configurations in multiple Terraform files without explicit aliasing?

Consider a Terraform project with two .tf files: one configures AWS provider with region us-east-1, and another configures AWS provider with region us-west-2, both without aliases. What is the expected behavior when running terraform apply?

A Terraform will merge both provider configurations and apply resources in both regions automatically.

B Terraform will use the last declared provider configuration and ignore the first one.

C Terraform will throw a configuration error due to multiple provider blocks without aliases.

D Terraform will create duplicate resources in both regions without error.

💡 Hint

Think about how Terraform handles multiple provider blocks of the same type.

Terraform requires multiple provider configurations of the same type to use aliases. Without aliases, it throws an error to avoid ambiguity.

❓ security

advanced

Identify the security risk in Terraform file organization

Which Terraform file organization practice can lead to accidental exposure of sensitive data like secrets or passwords?

A Using <code>terraform.tfvars</code> files committed to version control containing secrets in plain text.

B Storing sensitive variables in a separate <code>variables.tf</code> file with no special handling.

C Referencing sensitive data from environment variables during Terraform runs.

D Using remote state backends with encryption enabled.

💡 Hint

Consider what happens if secret values are stored in files tracked by Git.

Committing terraform.tfvars files with secrets in plain text to version control risks exposing sensitive data publicly or to unauthorized users.

🧠 Conceptual

expert

Determine the number of Terraform state files in a recommended multi-module, multi-environment setup

You have a Terraform project organized with a modules/ folder containing reusable modules, and separate folders for dev/, qa/, and prod/ environments. Each environment folder has its own Terraform configuration files and remote backend configured. How many distinct Terraform state files will exist after applying all environments?

A One state file per module per environment.

B One state file per module, shared across all environments.

C One single state file for all environments and modules combined.

D One state file per environment, encompassing all modules used in that environment.

💡 Hint

Think about how Terraform state files track resources per configuration and environment.

Each environment folder has its own configuration and backend, so each environment has one state file that includes all modules used in that environment.

Practice

1. What is the main purpose of organizing Terraform files into separate files like main.tf, variables.tf, and outputs.tf?

easy

A. To avoid using variables in the configuration

B. To reduce the number of resources created

C. To speed up Terraform apply operations

D. To make the code easier to read and maintain

Solution

1. Step 1: Understand file separation purpose

   Separating files by purpose helps organize code logically, making it easier to find and update parts.

2. Step 2: Recognize benefits of organization

   This organization improves readability and maintainability but does not affect resource count or speed directly.

3. Final Answer:

   To make the code easier to read and maintain -> Option D

4. Quick Check:

   File organization = easier maintenance [OK]

Hint: Think about how folders help organize papers [OK]

Common Mistakes:

• Confusing file organization with resource optimization
• Thinking it speeds up Terraform operations
• Believing variables are avoided by file separation

2. Which of the following is the correct way to declare a variable in a separate variables.tf file?

easy

A. variable "instance_type" { default = "t2.micro" }

B. var instance_type = "t2.micro"

C. variable instance_type = "t2.micro"

D. var "instance_type" { default = "t2.micro" }

Solution

1. Step 1: Recall Terraform variable syntax

   Terraform variables are declared with the keyword variable followed by the variable name in quotes and a block with attributes.

2. Step 2: Match correct syntax

   variable "instance_type" { default = "t2.micro" } matches the correct syntax: variable "name" { default = "value" }. Other options use invalid syntax.

3. Final Answer:

   variable "instance_type" { default = "t2.micro" } -> Option A

4. Quick Check:

   Correct variable syntax = variable "instance_type" { default = "t2.micro" } [OK]

Hint: Variables use 'variable' keyword with quotes and braces [OK]

Common Mistakes:

• Omitting quotes around variable name
• Using 'var' instead of 'variable' keyword
• Assigning variable like a normal programming variable

3. Given these files:

main.tf:
resource "aws_instance" "web" {
  ami           = var.ami_id
  instance_type = var.instance_type
}

variables.tf:
variable "ami_id" {}
variable "instance_type" {}

outputs.tf:
output "instance_id" {
  value = aws_instance.web.id
}

What will Terraform output after apply if the instance ID is i-1234567890abcdef0?

medium

A. "instance_id" = "i-1234567890abcdef0"

B. "instance_type" = "i-1234567890abcdef0"

C. "ami_id" = "i-1234567890abcdef0"

D. No output will be shown

Solution

1. Step 1: Identify output block purpose

   The outputs.tf file defines an output named instance_id that returns the ID of the AWS instance resource.

2. Step 2: Match output value with resource ID

   After apply, Terraform shows outputs with their names and values. The output will show instance_id with the instance's actual ID.

3. Final Answer:

   "instance_id" = "i-1234567890abcdef0" -> Option A

4. Quick Check:

   Output name matches resource ID [OK]

Hint: Outputs show resource values by their output names [OK]

Common Mistakes:

• Confusing variable names with output names
• Expecting variables to show as outputs automatically
• Thinking no output is shown without explicit output block

4. You have a variables.tf file with:

variable "region" {
  default = "us-east-1"
}

But Terraform apply fails with an error about missing provider configuration. What is the likely cause?

medium

A. Variables cannot have default values

B. The variable region must be declared in main.tf

C. The provider block is missing or not configured

D. Terraform requires region to be set in outputs.tf

Solution

1. Step 1: Understand provider role

   Terraform needs a provider block to know which cloud and region to use. Variables alone do not configure providers.

2. Step 2: Identify missing provider configuration

   If the provider block is missing or lacks region setting, Terraform cannot connect to the cloud, causing errors.

3. Final Answer:

   The provider block is missing or not configured -> Option C

4. Quick Check:

   Provider block required for cloud access [OK]

Hint: Always check provider block for cloud setup [OK]

Common Mistakes:

• Assuming variables configure providers automatically
• Placing variables in wrong files to fix provider errors
• Expecting outputs to fix provider configuration

5. You want to organize a Terraform project with multiple environments (dev, prod). Which file organization approach is best practice?

hard

A. Use one main.tf and switch environment by changing variable defaults

B. Create separate folders for each environment, each with its own main.tf, variables.tf, and outputs.tf

C. Put all environments in one folder using different variable names

D. Store environment configs only in terraform.tfvars without separate folders

Solution

1. Step 1: Understand environment isolation

   Separate folders per environment keep configurations isolated, avoiding accidental resource overlap.

2. Step 2: Recognize best practice for clarity and safety

   Each folder having its own files allows independent management and clear separation of dev and prod.

3. Final Answer:

   Create separate folders for each environment, each with its own main.tf, variables.tf, and outputs.tf -> Option B

4. Quick Check:

   Separate folders = safer multi-env management [OK]

Hint: Use folders to separate environments clearly [OK]

Common Mistakes:

• Mixing environments in one folder causing conflicts
• Relying only on variable changes without folder separation
• Not isolating state files per environment