Drift, Refresh-Only Plans & Importing Existing Resources

1. 1

   Create some drift and look at it with refresh-only

   Simulate an on-call engineer who turned off versioning on the assets bucket from the console during an incident. Then look only at the drift: -refresh-only shows 'Objects have changed outside of Terraform' and proposes to update state, not infrastructure.

   terminalcopy cmd

   $ BUCKET=$(terraform output -raw assets_bucket_name)

   aws s3api put-bucket-versioning --bucket "$BUCKET" --versioning-configuration Status=Suspended

   terraform plan -refresh-only

   ── expected output ──

   aws_s3_bucket_versioning.assets: Refreshing state... [id=shoplite-dev-assets-3f9a]

    

   Note: Objects have changed outside of Terraform

    

   Terraform detected the following changes made outside of Terraform since the

   last "terraform apply" which may have affected this plan:

    

   # aws_s3_bucket_versioning.assets has changed

   ~ resource "aws_s3_bucket_versioning" "assets" {

   id = "shoplite-dev-assets-3f9a"

   ~ versioning_configuration {

   ~ status = "Enabled" -> "Suspended"

   # (1 unchanged attribute hidden)

   }

   }

    

   This is a refresh-only plan, so Terraform will not take any actions to undo

   these. If you were expecting these changes then you can apply this plan to

   record the updated values in the Terraform state without changing any remote

   objects.

2. 2

   Decide: revert the drift

   Suspending versioning on the assets bucket wasn't a change you want to keep. A normal plan shows the corrective update, and applying it puts the bucket back the way the code says. Whenever you see drift, first decide whether the code or reality is right; don't apply either way on autopilot.

   terminalcopy cmd

   $ terraform apply

   ── expected output ──

   # aws_s3_bucket_versioning.assets will be updated in-place

   ~ resource "aws_s3_bucket_versioning" "assets" {

   ~ versioning_configuration {

   ~ status = "Suspended" -> "Enabled"

   }

   }

    

   Plan: 0 to add, 1 to change, 0 to destroy.

   ...

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

3. 3

   Simulate a hand-made resource

   A teammate created ShopLite's API log group in the console last week, with no retention setting (logs kept forever, which is a classic cost leak). ECS will write to it in Stage 3, so Terraform should own it.

   terminalcopy cmd

   $ aws logs create-log-group --log-group-name /shoplite/dev/api

   aws logs describe-log-groups --log-group-name-prefix /shoplite --query 'logGroups[].[logGroupName,retentionInDays]'

   ── expected output ──

   [

   [

   "/shoplite/dev/api",

   null

   ]

   ]

4. 4

   Declare the import

   The import block says: 'the existing object with ID /shoplite/dev/api should be tracked at address aws_cloudwatch_log_group.api'. For log groups the import ID is the name. Other resources use other IDs, such as a VPC ID or an ARN, and each Registry page has an 'Import' section that tells you which.

   import {
     to = aws_cloudwatch_log_group.api
     id = "/shoplite/dev/api"
   }

5. 5

   Let Terraform draft the config

   There's no resource block yet. -generate-config-out writes one from the real object's attributes. Treat it as a draft: it includes every attribute, including defaults you'd never write by hand.

   terminalcopy cmd

   $ terraform plan -generate-config-out=generated.tf

   cat generated.tf

   ── expected output ──

   aws_cloudwatch_log_group.api: Preparing import... [id=/shoplite/dev/api]

   aws_cloudwatch_log_group.api: Refreshing state... [id=/shoplite/dev/api]

    

   # aws_cloudwatch_log_group.api will be imported

   # (config will be generated)

   resource "aws_cloudwatch_log_group" "api" {

   name = "/shoplite/dev/api"

   retention_in_days = 0

   ...

   }

    

   Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.

    

   # __generated__ by Terraform

   resource "aws_cloudwatch_log_group" "api" {

   kms_key_id = null

   log_group_class = "STANDARD"

   name = "/shoplite/dev/api"

   name_prefix = null

   retention_in_days = 0

   skip_destroy = false

   tags = {}

   tags_all = {}

   }

6. 6

   Clean it up into real code, with the fix you actually want

   Move it into logs.tf, keep only what matters, and set a 14-day retention. tags_all is computed and can't be set. Delete generated.tf. Now the plan says 1 to import, 1 to change: adopt the log group, then fix its retention, all in one reviewable plan.

   resource "aws_cloudwatch_log_group" "api" {
     name              = "/${var.project}/${var.environment}/api"
     retention_in_days = 14
   }

   terminalcopy cmd

   $ rm generated.tf

   terraform apply

   ── expected output ──

   # aws_cloudwatch_log_group.api will be updated in-place

   # (imported from "/shoplite/dev/api")

   ~ resource "aws_cloudwatch_log_group" "api" {

   name = "/shoplite/dev/api"

   ~ retention_in_days = 0 -> 14

   ~ tags = {} -> null

   ~ tags_all = {} -> {

   + "Environment" = "dev"

   + "ManagedBy" = "terraform"

   + "Project" = "shoplite"

   ...

   }

   }

    

   Plan: 1 to import, 0 to add, 1 to change, 0 to destroy.

   ...

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

7. 7

   Remove the import block

   After a successful apply, the import block has done its job; once the resource is in state, leaving it is harmless but clutters the code. Delete imports.tf and confirm a clean plan.

   terminalcopy cmd

   $ rm imports.tf && terraform plan

   ── expected output ──

   No changes. Your infrastructure matches the configuration.

Make each change, run the command, and read the error before revealing the diagnosis. Recognising these messages on sight is what makes you fast on a real team. Undo the change afterwards.