{"dataset":{"id":"00000000-0000-0000-0000-000000000017","slug":"terraform-best-practices","name":"Terraform best practices","description":"Source-linked guidance on Terraform core workflows: state and remote backends, modules, variables and outputs, plan and apply, and resource dependencies. Scoped to Terraform language and CLI fundamentals; not a provider-specific corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Resource dependencies and depends_on","sourceUrl":"https://developer.hashicorp.com/terraform/language/meta-arguments/depends_on","text":"Terraform automatically infers dependencies when one resource's arguments reference another resource's data, so most ordering needs no annotation. Reserve the depends_on meta-argument for hidden dependencies: when a resource or module relies on another resource's behavior but does not access any of that resource's data, such as an EC2 instance whose software needs an IAM role policy that Terraform cannot infer. depends_on is valid in resource, module, data, output, check, and ephemeral blocks; it takes a list of references to resources or child modules in the same calling module and cannot contain arbitrary expressions, because dependencies must be known before Terraform can safely evaluate expressions. It instructs Terraform to complete all actions on the dependency object, including read operations, before operating on the dependent object; applied to a module, it orders all of that module's resources and data sources. Use depends_on only as a last resort, because it produces more conservative plans that replace more resources than necessary and treats more values as unknown \"(known after apply)\". Prefer expression references, which let Terraform skip planning changes when the referenced value has not changed. Scope: Terraform. Reviewed October 4, 2026.","id":"terraform-best-practices:Resource dependencies and depends_on","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Plan and apply workflow","sourceUrl":"https://developer.hashicorp.com/terraform/cli/commands/plan","text":"terraform plan creates an execution plan that previews changes: it reads the current state of existing remote objects to bring state up to date, compares the configuration to the prior state, and proposes the change actions needed to make remote objects match, without carrying them out. If nothing needs to change, plan reports that no actions need to be taken. Running plan without -out creates a speculative plan for review; the -out=FILE option saves a plan you later pass to terraform apply, a two-step workflow intended for automation. Running terraform apply without a saved plan automatically generates a new plan and prompts for approval; -auto-approve skips the prompt, and HashiCorp recommends it only when you ensure nobody can change infrastructure outside the Terraform workflow. Applying a saved plan file skips prompting and accepts no additional planning modes or options; inspect it first with terraform show. Always re-check the final non-speculative plan before applying, because interim changes to the target system can make the result differ from what an earlier speculative plan indicated. Scope: Terraform. Reviewed October 4, 2026.","id":"terraform-best-practices:Plan and apply workflow","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Input variables and outputs","sourceUrl":"https://developer.hashicorp.com/terraform/language/values/variables","text":"variable blocks define a module's input interface, letting consumers customize behavior at runtime without altering module source code; hardcoded values make a module inflexible and hard to reuse. Reference variables with var.<NAME> syntax. A variable without a default makes Terraform prompt for a value before it generates a plan, and an optional validation block enforces that input values meet module requirements. output blocks expose infrastructure data: child modules expose resource attributes to parent modules, which reference them as module.<CHILD_MODULE_NAME>.<OUTPUT_NAME>; root module outputs print in the CLI after apply; and other configurations can read root module outputs through the terraform_remote_state data source. Mark sensitive variables and outputs with sensitive = true to redact CLI display, but note that Terraform still stores sensitive output values in state, and terraform output with the -json or -raw flags prints them in plain text. Adding the ephemeral argument to an output omits its value from state and plan files, at the cost of restrictions on assignable values. Scope: Terraform. Reviewed October 4, 2026.","id":"terraform-best-practices:Input variables and outputs","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Modules for reusable infrastructure","sourceUrl":"https://developer.hashicorp.com/terraform/language/modules","text":"A module is a collection of resources that Terraform manages together. When you repeatedly provision similar collections of resources, such as networking resources for new development environments, write reusable modules to codify them; modularizing standardizes how you provision infrastructure. Every workspace's root directory configuration is the root module, and modules called through module blocks are child modules. The root module can call the same child module multiple times, and a child module can call its own nested child modules. Terraform loads modules from the local file system, a Terraform registry, and VCS repositories. The public Terraform registry hosts free modules from HashiCorp, partners, and the community that Terraform downloads automatically when you specify the appropriate source and version in a module block; HCP Terraform and Terraform Enterprise add a private module registry for sharing modules inside an organization. The module workflow has three phases: develop (collect resource configurations into a standard structure with documentation), distribute (publish to a public or private registry, S3 bucket, or GitHub repository), and provision (consumers call the module with a module block). Scope: Terraform. Reviewed October 4, 2026.","id":"terraform-best-practices:Modules for reusable infrastructure","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"State storage and remote backends","sourceUrl":"https://developer.hashicorp.com/terraform/language/state","text":"Terraform must store state to map real-world resources to your configuration, track metadata, and improve performance; prior to any operation it refreshes state against the real infrastructure to decide which changes to make. By default each workspace's state lives in a local terraform.tfstate file with a terraform.tfstate.backup copy of the previous state, but local storage limits collaboration and risks losing state. HashiCorp recommends storing state in HCP Terraform or a remote backend, and warns against version control or any storage without state locking and secure access control, because state can contain secrets. Configure a single backend block nested in the top-level terraform block; it cannot reference input variables or other named values, and the default backend is local while some remote backends lock state during operations. Supply backend credentials through environment variables rather than -backend-config or hardcoded values, which Terraform writes into the .terraform subdirectory and plan files. Never edit the JSON state directly; use the terraform state CLI command for modifications. Scope: Terraform. Reviewed October 4, 2026.","id":"terraform-best-practices:State storage and remote backends","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}