Writing configuration for imported resources in Terraform - Commands & Configuration

Introduction

Sometimes you have existing cloud resources created outside Terraform. To manage them with Terraform, you import them and then write configuration that matches their current state. This lets Terraform track and update those resources safely.

When you want to start managing an existing cloud server with Terraform without recreating it

When a resource was created manually or by another tool and you want to bring it under Terraform control

When migrating infrastructure to Terraform step-by-step without downtime

When you need to fix drift by importing resources that got out of sync

When collaborating with a team that created resources outside Terraform but you want a single source of truth

Config File - main.tf

main.tf

provider "aws" {
  region = "us-east-1"
}

resource "aws_instance" "example" {
  # The configuration must match the imported resource's current state
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
  tags = {
    Name = "example-instance"
  }
}

This file defines the AWS provider and a resource block for an EC2 instance.

The resource block must match the existing instance you imported, including AMI, instance type, and tags.

This configuration allows Terraform to manage the imported instance without changing it unexpectedly.

Commands

Initializes the Terraform working directory and downloads necessary provider plugins.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding latest version of hashicorp/aws...

- Installing hashicorp/aws v4.0.0...

- Installed hashicorp/aws v4.0.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see any changes.

Imports the existing AWS EC2 instance with ID i-0abcd1234efgh5678 into Terraform state under the resource aws_instance.example.

Terminal

terraform import aws_instance.example i-0abcd1234efgh5678

Expected Output

aws_instance.example: Importing from ID "i-0abcd1234efgh5678"...

aws_instance.example: Import prepared!

  Prepared aws_instance for import

aws_instance.example: Refreshing state... [id=i-0abcd1234efgh5678]



Import successful!



The resources that were imported are now in your Terraform state and will be managed by Terraform.

Shows the difference between the imported resource's current state and the written configuration to verify no changes will be made.

Terminal

terraform plan

Expected Output

No changes. Infrastructure is up-to-date.



This means that your configuration matches the imported resource exactly.

Applies the configuration to ensure Terraform manages the resource without changes, confirming the import and configuration are correct.

Terminal

terraform apply -auto-approve

Expected Output

aws_instance.example: Refreshing state... [id=i-0abcd1234efgh5678]



No changes. Your infrastructure matches the configuration.



Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approves the apply without interactive confirmation

Key Concept

If you remember nothing else from this pattern, remember: after importing a resource, you must write matching configuration so Terraform can manage it safely.

Common Mistakes

Importing a resource but not writing matching configuration in the Terraform files

Terraform will see the resource as unmanaged or try to recreate it, causing errors or resource duplication

Write a resource block in your configuration that matches the imported resource's current settings exactly

Writing configuration that differs from the imported resource's actual state before running terraform plan

Terraform will plan to change or destroy the resource unexpectedly, risking downtime or data loss

Check the resource's current settings in the cloud console and replicate them exactly in the Terraform configuration before planning

Summary

Initialize Terraform with terraform init to prepare the working directory.

Import the existing resource into Terraform state using terraform import with the resource ID.

Write Terraform configuration that matches the imported resource's current state exactly.

Run terraform plan to verify no changes will be made.

Apply the configuration with terraform apply to confirm Terraform manages the resource safely.

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