Writing configuration for imported resources in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Configuration

intermediate

Identify the correct Terraform resource configuration after import

You imported an existing AWS S3 bucket named my-bucket using Terraform import. Which configuration correctly represents the imported resource to avoid drift?

Terraform

terraform import aws_s3_bucket.my_bucket my-bucket

A

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  acl    = "private"
}

B

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  region = "us-east-1"
}

C

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  acl  = "private"
}

D

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"
  versioning = {
    enabled = true
  }
}

💡 Hint

Check the correct attribute name for the bucket identifier and minimal required attributes.

The correct attribute to specify the bucket name is bucket. The acl attribute is often required to match the existing bucket's access control. The region attribute is not valid inside the resource block. The attribute name is invalid for aws_s3_bucket resource. Versioning is optional and may not match the imported bucket's state.

❓ Architecture

intermediate

Determine the correct Terraform import command for an existing resource

You want to manage an existing AWS EC2 instance with Terraform. The instance ID is i-0abcd1234efgh5678. Which import command correctly imports this resource?

A terraform import aws_instance.my_instance my_instance

B terraform import aws_ec2_instance.my_instance i-0abcd1234efgh5678

C terraform import aws_instance.my_instance i-0abcd1234efgh5678

D terraform import aws_ec2.my_instance i-0abcd1234efgh5678

💡 Hint

Check the correct Terraform resource type name for EC2 instances.

The correct resource type for an EC2 instance in Terraform AWS provider is aws_instance. The import command requires the resource type and name, followed by the instance ID. Options B and D use invalid resource types. Option C uses the resource name instead of the instance ID.

❓ service_behavior

advanced

Predict the behavior of Terraform after importing a resource without configuration

You imported an existing AWS RDS instance using Terraform import but did not add any resource block in your configuration files. What will happen when you run terraform plan?

A Terraform will show the resource as to be destroyed because it is not in configuration.

B Terraform will show the resource as to be created because it is missing in configuration.

C Terraform will raise an error about missing resource configuration.

D Terraform will show no changes because the resource is imported.

💡 Hint

Think about how Terraform treats imported resources without configuration.

Terraform tracks resources defined in configuration. If a resource is imported but not declared in configuration, Terraform considers it unmanaged and plans to destroy it if it was previously managed. Since the resource is not in configuration, Terraform plans to destroy it.

❓ security

advanced

Identify the security risk when importing resources without state locking

You imported several AWS IAM roles into Terraform but did not enable state locking on your backend. What is the main security risk of this setup?

A Imported IAM roles will be publicly accessible by default.

B Terraform will automatically delete IAM roles without confirmation.

C Terraform will encrypt the state file causing access issues.

D Multiple users can overwrite the Terraform state causing inconsistent IAM role permissions.

💡 Hint

Consider what happens when multiple users modify state files simultaneously.

Without state locking, concurrent Terraform runs can overwrite the state file, causing loss of changes or inconsistent resource states. This can lead to incorrect IAM role permissions or unintended deletions. Options B, C, and D are incorrect because they describe behaviors unrelated to state locking.

✅ Best Practice

expert

Choose the best practice for managing imported resources in Terraform

After importing a complex AWS VPC with many sub-resources, what is the best practice to ensure your Terraform configuration matches the actual infrastructure?

A Only import the main VPC resource and ignore sub-resources to reduce configuration complexity.

B Manually write the full Terraform configuration matching the imported resources and run <code>terraform plan</code> to detect drift.

C Delete the imported resources and recreate them with Terraform to ensure configuration accuracy.

D Use <code>terraform refresh</code> to update the state without adding configuration.

💡 Hint

Think about how Terraform tracks resources and detects changes.

Best practice after importing is to write configuration that fully represents the imported resources. This allows Terraform to track and manage them properly and detect any drift. Ignoring sub-resources or deleting imported resources defeats the purpose of import. terraform refresh updates state but does not add configuration, so it cannot manage resources fully.

Practice

1. What is the main purpose of writing Terraform configuration for an imported resource?

easy

A. To delete the resource automatically

B. To create a new resource from scratch

C. To match the existing resource so Terraform can manage it

D. To backup the resource data externally

Solution

1. Step 1: Understand Terraform import

   Terraform import links an existing resource to Terraform state but requires matching configuration to manage it.

2. Step 2: Purpose of configuration

   Writing configuration that matches the existing resource allows Terraform to track and manage it properly.

3. Final Answer:

   To match the existing resource so Terraform can manage it -> Option C

4. Quick Check:

   Import needs matching config = A [OK]

Hint: Import needs matching config to manage resource [OK]

Common Mistakes:

• Thinking import creates new resources
• Assuming import deletes resources
• Believing import backs up data

2. Which Terraform block is required before importing an existing AWS S3 bucket named my-bucket?

easy

A. resource "aws_s3_bucket" "my_bucket" { bucket_name = "my-bucket" }

B. resource "aws_s3_bucket" "my_bucket" { bucket = "my-bucket" }

C. resource "aws_s3_bucket" "my_bucket" { name = "my-bucket" }

D. resource "aws_s3_bucket" "my_bucket" { id = "my-bucket" }

Solution

1. Step 1: Identify correct attribute for S3 bucket

   The correct attribute to specify the bucket name in Terraform AWS provider is bucket.

2. Step 2: Match syntax for resource block

   The resource block must use resource "aws_s3_bucket" "my_bucket" { bucket = "my-bucket" } to match the existing bucket.

3. Final Answer:

   resource "aws_s3_bucket" "my_bucket" { bucket = "my-bucket" } -> Option B

4. Quick Check:

   Correct attribute is bucket = name [OK]

Hint: Use 'bucket' attribute for S3 bucket name [OK]

Common Mistakes:

• Using 'name' instead of 'bucket' attribute
• Using 'bucket_name' which is invalid
• Using 'id' attribute in config

3. Given this Terraform configuration for an imported AWS EC2 instance:

resource "aws_instance" "web" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}

What happens if you run terraform import aws_instance.web i-0abcd1234efgh5678?

medium

A. Terraform state links to the existing instance without changing it

B. Terraform creates a new instance with the given AMI

C. Terraform deletes the existing instance and creates a new one

D. Terraform throws an error because AMI does not match

Solution

1. Step 1: Understand import behavior

   Terraform import links the existing resource ID to the resource block in state without changing the actual resource.

2. Step 2: Effect of running import

   Running import with the instance ID associates the existing EC2 instance with the Terraform resource, no creation or deletion occurs.

3. Final Answer:

   Terraform state links to the existing instance without changing it -> Option A

4. Quick Check:

   Import links state, no resource change [OK]

Hint: Import links existing resource to state, no creation [OK]

Common Mistakes:

• Thinking import creates or deletes resources
• Assuming import validates AMI matches
• Expecting import to modify resource

4. You wrote this Terraform configuration for an imported AWS VPC:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
}

After running terraform import aws_vpc.main vpc-1234abcd, Terraform plan shows it wants to change the CIDR block. What is the likely cause?

medium

A. The actual VPC CIDR block differs from the configured one

B. Terraform import failed and did not link the resource

C. The resource name in config does not match the import command

D. Terraform requires a different syntax for VPC import

Solution

1. Step 1: Analyze import and plan behavior

   Import links the existing VPC to Terraform state, but if the configuration CIDR block differs from the actual VPC, Terraform plans to update it.

2. Step 2: Identify cause of plan changes

   The difference in CIDR block values causes Terraform to want to change the resource to match config, which is not allowed for VPC CIDR.

3. Final Answer:

   The actual VPC CIDR block differs from the configured one -> Option A

4. Quick Check:

   Config mismatch causes plan changes [OK]

Hint: Check config matches actual resource attributes exactly [OK]

Common Mistakes:

• Assuming import failed without checking state
• Confusing resource name with import ID
• Thinking import syntax is wrong

5. You have an existing Azure resource group named rg-prod created outside Terraform. You want to import it and manage it with Terraform. Which steps correctly describe the process?

hard

A. Create a new resource group in Terraform, then delete the existing one manually.

B. Run 'terraform import' first without any resource block, then write the resource block after.

C. Write a resource block with any name, run 'terraform import' with resource group name only, then apply.

D. Write a resource block with name 'rg-prod', run 'terraform import azurerm_resource_group.prod /subscriptions/0000/resourceGroups/rg-prod', then run 'terraform plan' to verify.

Solution

1. Step 1: Write matching resource block

   Before importing, write a resource block with the correct resource type and name matching the existing resource group.

2. Step 2: Run terraform import with full resource ID

   Use the full Azure resource ID to import the existing resource group into Terraform state.

3. Step 3: Verify with terraform plan

   Run 'terraform plan' to confirm Terraform recognizes the imported resource and no unexpected changes are planned.

4. Final Answer:

   Write a resource block with name 'rg-prod', run 'terraform import azurerm_resource_group.prod /subscriptions/0000/resourceGroups/rg-prod', then run 'terraform plan' to verify. -> Option D

5. Quick Check:

   Config first, import with full ID, then plan [OK]

Hint: Write config first, import with full ID, then plan [OK]

Common Mistakes:

• Importing without resource block
• Using partial resource ID in import
• Creating duplicate resources instead of importing