Terraform Import, State Inspection, and Debug Logging

The terraform import command records an existing real-world object in Terraform state so Terraform manages it from then on. Its syntax is terraform import ADDRESS ID, where ADDRESS is the resource address in your configuration (for example aws_s3_bucket.logs) and ID is the provider-specific identifier of the real object - an instance ID for aws_instance, a bucket name for aws_s3_bucket, a self-link style path for many Google resources. Each provider's documentation lists the ID format each resource type expects.

The rule the exam loves: you must write the resource block before you import. The CLI command refuses to import to an address that does not exist in configuration, and it updates state only - it never writes or edits your .tf files. The workflow is therefore: write the block, import, then run terraform plan and adjust the block's arguments until the plan is clean.

resource "aws_s3_bucket" "logs" {
  bucket = "acme-log-archive"
}

terraform import aws_s3_bucket.logs acme-log-archive
terraform plan   # reconcile config with the imported attributes

The command imports one resource per invocation, needs provider credentials configured (it reads the real object through the provider), and acquires the state lock like any state-writing operation. If the plan after import still shows changes, your configuration does not yet match reality - keep editing the block, not the state.

The import block, available since Terraform 1.5 and the recommended approach in 1.12, turns import into part of the normal plan/apply cycle instead of a one-off CLI action. You declare in configuration what should be imported to where, and the import happens - visibly - when the plan is applied:

import {
  to = aws_instance.web
  id = "i-0a1b2c3d4e5f67890"
}

resource "aws_instance" "web" {
  ami           = "ami-0abcd1234example"
  instance_type = "t3.micro"
}

This buys you three things over terraform import. It is plannable: terraform plan shows the resource will be imported (and whether the configuration matches), so the operation gets code review like any other change. It is repeatable and bulk-capable: import blocks can use for_each and expressions in id, so one block can import a whole set of objects. And it is CI-friendly - no human running ad-hoc commands against production state.

After a successful apply the resource is in state and the import block has done its job; you can delete the block (leaving it is harmless - a completed import is a no-op). Like the CLI command, an import block never changes the real object; it only records it in state.

The -generate-config-out flag solves the tedious half of importing: writing configuration that matches an object you did not create. When a plan contains import blocks whose target resources have no corresponding resource block, Terraform can generate that HCL for you:

import {
  to = google_compute_instance.legacy
  id = "projects/acme-prod/zones/us-central1-a/instances/legacy-vm"
}

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

Terraform reads the real object through the provider and writes a best-effort resource block for each configless import target into the named file, which must not already exist. The generated code is a starting point, not a finished product: review it, prune computed or redundant attributes, replace hard-coded values with variables and references, then run plan again until it is clean and apply to complete the import.

Keep the division of labor straight for the exam: terraform import requires hand-written configuration and touches only state; the import block plus -generate-config-out is the only path where Terraform writes configuration for you, and it only generates for import targets that lack a resource block.

Four commands cover state inspection, and the exam expects you to pick the right one for a scenario:

terraform state list answers the narrow question of what exists in state - addresses only, no attributes - and can be filtered by address or with -id=. terraform state show zooms into a single resource:

terraform state list
terraform state list module.network
terraform state show google_compute_instance.vm

All of these read state through the configured backend, so they work the same against local or remote state, and none of them modify anything - they are safe to run at any time.

terraform show renders the current state - or a saved plan file - in human-readable form, and with -json emits a machine-readable document that tooling (policy checks, CI gates, diff viewers) can consume. Pointing it at a plan artifact is the standard way to inspect exactly what an apply would do:

terraform plan -out=tfplan
terraform show tfplan          # human-readable review of the saved plan
terraform show -json tfplan    # machine-readable, for automation

terraform output prints the root module's output values from state. On its own it lists all non-sensitive outputs; name one to print just that value, add -raw for an unquoted string suitable for shell substitution, or -json for structured consumption:

terraform output
terraform output instance_ip
terraform output -raw instance_ip
terraform output -json

One nuance worth knowing: outputs marked sensitive = true are redacted in apply summaries and in the bare terraform output listing, but requesting the output by name (or using -json) prints the real value - sensitivity controls display by default, it is not encryption. The values still live in plain text inside the state file, which is part of why state storage must be protected.

Verbose logging is enabled with the TF_LOG environment variable - there is no CLI flag for it. Unset, logging is off; set it to a level and Terraform writes detailed logs to stderr. The levels, from most to least verbose:

export TF_LOG=DEBUG
terraform apply

TF_LOG=TRACE terraform plan   # one-off, without exporting

Two details show up in questions. TRACE is the most verbose and the most reliable level - and if TF_LOG is set to anything that is not a recognized level name, Terraform treats it as TRACE. And because TRACE logs include provider API traffic, log output can contain sensitive values: enable verbose logging while reproducing a bug (it is invaluable evidence for provider bug reports), then turn it off and handle the captured logs carefully.

TF_LOG_PATH persists log output by appending it to the file you name, instead of only streaming it to stderr. The catch the exam checks: TF_LOG_PATH does nothing by itself - logging must also be enabled with TF_LOG (or one of the scoped variables below).

export TF_LOG=TRACE
export TF_LOG_PATH=./terraform.log
terraform apply   # full trace appended to ./terraform.log

When a TRACE log is overwhelming, scope it. TF_LOG_CORE sets a level for Terraform core only (graph building, state handling, plan logic), and TF_LOG_PROVIDER sets a level for provider plugins only (API calls to AWS, Google Cloud, Azure, and so on). Each accepts the same level names and overrides TF_LOG for its half of the system, so you can silence one side while turning the other up:

TF_LOG_CORE=ERROR TF_LOG_PROVIDER=TRACE terraform plan   # suspect a provider/API issue
TF_LOG_CORE=TRACE TF_LOG_PROVIDER=ERROR terraform plan   # suspect core plan/state logic

Choosing between them is the practical skill: a resource failing with an opaque API error is a provider-side question (TF_LOG_PROVIDER=TRACE shows the actual requests and responses), while confusion about dependency ordering or state handling is core-side. When filing a bug against Terraform or a provider, a TRACE log captured via TF_LOG_PATH is the standard supporting evidence.