Writing configuration for imported resources in Terraform - Step-by-Step Execution

Process Flow - Writing configuration for imported resources

Identify existing resource

↓

Import resource using CLI

↓

Write matching Terraform config

↓

Run terraform plan

↓

Verify no changes needed

↓

Manage resource with Terraform

This flow shows how to bring an existing resource under Terraform management by importing it, writing matching config, and verifying no changes.

Execution Sample

Terraform

terraform import aws_s3_bucket.mybucket my-existing-bucket

resource "aws_s3_bucket" "mybucket" {
  bucket = "my-existing-bucket"
  acl    = "private"
}

Import an existing S3 bucket and write Terraform config to match it.

Process Table

Step	Action	CLI/Config	Terraform State	Result
1	Identify existing resource	N/A	No resource in state	Ready to import
2	Import resource	terraform import aws_s3_bucket.mybucket my-existing-bucket	State updated with resource	Resource tracked by Terraform
3	Write config	resource "aws_s3_bucket" "mybucket" { bucket = "my-existing-bucket" acl = "private" }	Config matches resource	Terraform knows resource details
4	Run terraform plan	terraform plan	State and config compared	No changes detected
5	Manage resource	terraform apply	State updated if needed	Resource managed by Terraform
6	Exit	N/A	State and config synced	Process complete

💡 No changes detected after plan, resource is fully managed

Status Tracker

Variable	Start	After Import	After Config Write	After Plan	Final
terraform_state	empty	contains aws_s3_bucket.mybucket	unchanged	unchanged	unchanged
configuration	empty	empty	contains aws_s3_bucket.mybucket config	unchanged	unchanged

Key Moments - 3 Insights

Why do I need to write the Terraform config after importing a resource?

Importing only adds the resource to Terraform state; without matching config, Terraform will try to delete or recreate it. See execution_table step 3 and 4.

What happens if the config does not match the imported resource?

Terraform plan will show changes to apply, possibly deleting or modifying the resource unexpectedly. See execution_table step 4.

Can I import multiple resources at once?

You must import each resource individually with its own import command and write matching config for each. See execution_table steps 2 and 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the Terraform state after step 2?

A Contains the imported resource

B Empty, no resources tracked

C Matches the written config

D Shows planned changes

💡 Hint

Check the 'Terraform State' column in row for step 2

At which step does Terraform detect no changes needed?

A Step 2 - Import resource

B Step 3 - Write config

C Step 4 - Run terraform plan

D Step 5 - Manage resource

💡 Hint

Look at the 'Result' column for step 4 in execution_table

If the config does not match the imported resource, what will terraform plan show?

A No changes needed

B Planned changes to update or replace resource

C Errors and stops

D Resource removed from state

💡 Hint

Refer to key_moments about mismatched config and step 4 in execution_table

Concept Snapshot

Terraform import brings existing resources into state.
You must write matching config to avoid unwanted changes.
Run terraform plan to verify no changes.
Then manage resource normally with Terraform.

Full Transcript

To manage an existing cloud resource with Terraform, first identify the resource you want to import. Use the terraform import command to add it to Terraform's state file. This does not create configuration files, so you must write Terraform configuration that matches the imported resource's settings. After writing the config, run terraform plan to compare the state and config. If they match, no changes will be planned, meaning Terraform now fully manages the resource. This process prevents Terraform from trying to recreate or delete the resource. Always verify with terraform plan before applying changes.

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