The JSON form of a plan exposes structured resource actions, configuration and state for automation. It can also expose sensitive values in plaintext, so policy tooling must treat it as protected data.
Marking a value sensitive redacts normal CLI and UI output. It does not remove that value from Terraform state or saved plan files.
HashiCorp's 2026 Terraform Policy beta evaluates provider-aware infrastructure policies using HCL and a dedicated tfpolicy test workflow. It changes where platform teams can encode guardrails, but it is still beta.
A saved plan captures the exact actions Terraform intends to apply. In CI/CD it becomes the handoff between review and execution—and a sensitive artifact that must be protected.
State locking serializes writers against one state. It cannot tell whether a plan is destructive, credentials point at the right account, or force-unlock is safe.
validate checks syntax and internal consistency. terraform test can run plan/apply test cases and assertions, including real provider operations, so it belongs in a different CI risk class.
A moved block records that a resource address changed while the remote object did not. Removing it too early can make older module consumers see a destructive refactor.
count identities are numeric indexes; for_each identities are keys. Switching syntax without mapping addresses can make unchanged infrastructure look like replacement work.
Reading outputs from another Terraform state is convenient, but consumers generally need access to the full underlying state snapshot. That couples security and deployment boundaries.
The keys in for_each become part of resource addresses. Renaming a key can look like deleting one object and creating another even when the human thinks only a label changed.
Terraform has several validation primitives because not every rule should fail at the same time. Preconditions protect assumptions, postconditions protect guarantees, and check blocks report ongoing health without necessarily blocking a run.
Configuration-driven import turns existing infrastructure adoption into code that can be planned, reviewed, repeated, and paired with the resource configuration it will become.
Sometimes infrastructure is unhealthy in ways Terraform cannot infer from HCL. -replace makes that one-run replacement intent visible in the plan instead of mutating state ahead of review.
create_before_destroy changes replacement ordering to reduce downtime, but naming constraints, quotas, dependencies, and temporary double-capacity decide whether that strategy is actually safe.
State maps resource addresses in configuration to real remote objects. Treating it as disposable cache data is how infrastructure gets orphaned or recreated.
Provider configurations carry account, region and credential context. A reusable module that needs aliases is declaring runtime dependencies, not merely HCL syntax.
Resource targeting narrows Terraform to a selected subset plus dependencies. It is valuable for exceptional recovery but can leave the rest of the configuration unapplied.
state mv, state rm, state replace-provider, state pull and state push can change Terraform's ownership model without directly changing remote infrastructure.
A module-level depends_on creates a broad ordering relationship between groups of resources. It can make plans more conservative and hide the specific dependency the system actually has.
Terraform 1.10+ ephemeral values and 1.11+ write-only arguments let temporary values pass through a run without being persisted in state or plan artifacts when providers support them.
required_providers constrains acceptable versions; .terraform.lock.hcl records the exact provider selections and checksums Terraform should install. Committing one without understanding the other creates false confidence.
A provider defines resource schemas, planning behavior, defaults, import rules, and state upgrades. Changing its version can alter plans even when no HCL changes, so provider upgrades deserve infrastructure review.
ignore_changes tells Terraform that selected attributes may be controlled elsewhere after creation. Used casually, it can hide real drift and make configuration stop describing production.
A normal plan refreshes reality before calculating changes. Refresh-only mode updates Terraform's recorded view without changing infrastructure. The real decision is which side is authoritative.
A workspace manages one root module and one state. HCP Terraform Stacks coordinate multiple components and repeated deployments. The choice is about how many infrastructure lifecycles you need to compose, not which UI looks newer.