Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

A Terraform destroy count is a proposed plan result, not proof that Terraform is deleting the right things. Review the resource addresses and actions, confirm the workspace and configuration/state context, and approve only when the proposed target set matches your intent. If generated Terraform has a misplaced comment, first establish whether the file is native .tf or JSON-based .tf.json: their comment rules differ.

Why a Terraform destroy count needs a plan review

Terraform’s plan describes proposed actions. In plan output, + means create, - means destroy, ~ means update in place, and -/+ means replacement. A replacement includes destruction, so do not check only the headline destroy total; inspect each planned address and action.

terraform plan -destroy previews a destroy-mode plan. The terraform destroy command is a convenience form of applying in destroy mode. Destroy mode aims to destroy managed objects represented by the selected configuration, but an unseen plan cannot be validated from its count alone. Terraform plan command and Terraform destroy command document these behaviors.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Check scope before approving

  • Compare every planned address with the resources you intend to remove, including numeric count indexes or for_each keys.
  • Confirm the active workspace, input values, configuration, and state context are the ones you expect; these determine which instances Terraform plans against.
  • Pause if unexpected addresses appear. Investigate why Terraform considers those instances managed or why they are absent from the active configuration before applying.

The plan approval prompt is a consequential checkpoint, not a formality. HashiCorp’s plan tutorial demonstrates reviewing a plan and requesting approval before applying it.

Inspect machine-readable output carefully

For automation, terraform show -json emits JSON representations of a plan, including configuration and planned changes. Consumers should account for the documented format and version behavior in the Terraform JSON output format. Plan files and their JSON output can contain sensitive values; do not commit them to version control.

Choose between count and for_each by instance identity

Both meta-arguments create multiple instances from one resource or module block, but they identify those instances differently. Use the model that fits the data and the references you need to maintain.

Choice Instance identity Best fit Important constraint
count Zero-based numeric index, such as resource.example[0] Nearly identical instances when position is an adequate identity The count must be a whole number known before Terraform performs remote resource operations.
for_each Map key or set member, such as resource.example["api"] Instances with meaningful names or arguments associated with distinct keys or values Accepts a map or a set of strings; expressions use each.key and each.value.

The two arguments are mutually exclusive within a block. Terraform’s count reference and for_each reference describe their accepted values and instance-address behavior.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Review addresses when changing the repetition model

With count, instances are addressed by position; with for_each, they are addressed by key. If you change how a block is expanded, inspect the resulting addresses and full plan rather than assuming a change in the destroy total is harmless. A planned action against an unexpected index or key is a reason to stop and check the configuration and state relationship.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Put comments in the right Terraform file and location

Terraform configuration can use native syntax in .tf files or JSON syntax in .tf.json files. The JSON form is primarily intended for programmatic generation and consumption, rather than hand editing. Terraform JSON configuration syntax explains the distinction and the limited comment convention.

In generated .tf.json, use the special property only in supported objects

Terraform ignores a property named "//" when it appears in an object representing a block body, and it also permits the property at the configuration root. It is not a general JSON comment syntax: inside an object interpreted as an expression, "//" is an ordinary attribute name. Whether a misplaced property is treated as a comment therefore depends on the kind of object containing it.

{
  "resource": {
    "aws_instance": {
      "example": {
        "//": "Generated resource for scheduled tasks",
        "instance_type": "t2.micro",
        "ami": "ami-abc123"
      }
    }
  }
}

Here, the comment property is within the resource block body. If your generated file behaves differently, inspect the surrounding JSON nesting and determine whether that object is a block body or an expression; without the file, it is not possible to identify a specific parse error.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

In native .tf, use HCL comment syntax

Native Terraform files accept # and // line comments, as well as /* ... */ block comments. The style guide recommends # as the default idiom. See Terraform language style.

Validate generated configuration and inspect the plan

  1. Identify the file format. Check whether the generated artifact ends in .tf or .tf.json and use the corresponding syntax rules.
  2. Inspect comment nesting. In JSON configuration, verify that each "//" property is at the root or in a block-body object, not an expression object.
  3. Check instance identity. Determine whether the block uses count or for_each, then review references and planned addresses against the intended indexes or keys.
  4. Run the appropriate checks. Use terraform fmt and terraform validate as applicable to the configuration. These checks do not replace review of the proposed plan. See the fmt command and validate command.
  5. Review the complete plan before applying. Confirm every destroy and replacement action, along with the workspace and configuration/state context, before approving.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.