Terraform is HashiCorp/IBM's BSL-licensed tool with HCP Terraform's managed pipeline and Sentinel; OpenTofu is the Linux Foundation-governed, MPL 2.0 fork with its own newer features (state encryption, provider for_each). The HCL syntax and provider ecosystem are shared, so switching later is low-friction.

Because the address is the only key state and the dependency graph use — renaming a resource's local name creates a brand-new address with no relationship to the old one, which is why an unplanned rename triggers a destroy-and-recreate.

A resource is something Terraform creates, updates, and destroys. A data source only reads an existing object through a provider — no create/update/delete ever happens through it.

Before computing a diff, terraform plan queries the real, current state of every tracked resource through its provider, not just trusting the recorded state file — this is the actual mechanism behind drift detection.

for_each for anything with a natural key (a name, a region), since removing a middle item only affects that one instance. count is best reserved for disposable, order-independent, all-identical resources, since removing a middle index shifts every later index and can trigger unnecessary destroy/recreate churn.

It guarantees the applied plan is exactly the one that was reviewed — a bare apply re-plans internally immediately before applying, which can differ from what a human reviewed if anything changed in between.

~> ("pessimistic constraint") allows only the rightmost version segment to increment — ~> 5.60 allows up to but not including 6.0.0. >= is an open-ended lower bound with no automatic upper limit.

1 to add, 1 to destroy — Terraform sees two unrelated addresses, not a rename, because it has no concept of "rename" as a plan action on its own.

Whether the destroy-then-add sequence creates any window where a critical resource (a security group's rules, a load balancer's target group) is briefly absent or misconfigured — a config diff that looks harmless can still produce a genuinely destructive plan.

It only redacts the value from CLI/plan output — the state file itself still stores the raw value in plain JSON. State-level encryption and access control are the actual controls.

serial is a monotonic counter incremented on every write, used to detect concurrent/stale writes. lineage is a UUID identifying one state's history, generated once — a mismatch signals two unrelated state histories being treated as compatible.

Terraform 1.10+ uses S3's own conditional-write support (If-None-Match) to create a lock object directly in the bucket, removing the need for a second service (DynamoDB) purely to hold a lock record.

state mv is a one-time, local, unreviewed command run directly against the backend. A moved block lives in version control, is reviewable in a PR, and applies automatically and consistently across every environment that runs the configuration.

Every plan evaluates the entire file (slower), and the blast radius of any single mistake spans everything the file tracks — a typo in one service's config can produce a plan that touches unrelated shared infrastructure.

It creates an explicit, declared dependency on another Terraform configuration's own outputs, rather than an invisible, undeclared coupling based on a tag that could be renamed or reassigned with no warning.

The second apply fails immediately with a lock-held error — the conditional-write lock means only one client can hold it at a time.

A stale or copy-pasted backend block still pointing at production's actual state key, silently overriding what the directory name suggests — always read the plan's actual resource names, never trust the folder name alone.

terraform state mv (with -state-out to move resources into a new state), after a terraform state pull backup — this moves resources between state files without touching the real infrastructure.

A module's own provider block makes it incompatible with for_each, count, and depends_on — Terraform enforces this because providers aren't graph-ordered nodes the way resources are. Provider configuration belongs only in the root module.

The default (non-aliased) provider is inherited automatically by a child module. Any aliased provider must be passed explicitly via the providers = {} map — it's never inherited automatically.

Removing or renaming an output breaks any caller reading it — silently, and only at that caller's own next plan, not at the module's own point of change. Adding a new output is always safe.

It lets a caller omit an attribute and get a specified default, instead of being forced to specify every single attribute for every object in a collection — key to keeping a flexible module's interface ergonomic.

Too coarse: requires 15+ variables to configure, or two different callers only partially want it. Too granular: exactly one resource with no real logic, or pushes all composition burden onto every caller.

terraform plan fails with a "module does not support for_each" error — remove the provider block from the module and configure/pass the aliased provider from the root module instead.

A changed default value for a previously-unset argument, introduced somewhere in the 5.1–5.4 range. Reading the module's changelog before merging the version bump — not just the version-number diff — is what should have caught it.

Terraform 1.9+ — before that, cross-variable validation required a workaround using a precondition block inside a resource's lifecycle, since validation blocks couldn't reference other variables.

A CLI workspace is a named, isolated state file within the same backend/configuration — a free, built-in feature. An HCP Terraform workspace is an entire managed run environment in HashiCorp's SaaS product. They share a name but are otherwise unrelated concepts.

Switching CLI workspaces is a silent, local CLI state change — easy to forget which one is selected. A directory is explicit and visible in every terminal prompt and CI job's working directory, removing that class of mistake structurally.

It lets shared configuration (backend generation, provider generation, common variables) be defined once at a parent level and inherited automatically by every leaf deployment, removing the duplication plain directory-per-environment accumulates as environments multiply.

A credential/permissions mistake in one account has no path to another account at all — it's not a permissions boundary inside one shared account that a misconfiguration could erode, but a genuine, separate identity and API surface.

A central "hub" identity (a CI role or human SSO identity) calls AWS STS to assume a "spoke" role scoped to one target account, receiving short-lived, temporary credentials — no long-lived credential for the target account needs to exist outside that account.

CLI workspaces for the load-test environments (ephemeral, identical). A dedicated directory — and ideally its own AWS account — for production (permanent, structurally distinct, high stakes).

The backend (state location) is correct, but the ambient credentials actually in use (a stale AWS_PROFILE or session) point at a different account than the directory implies — the fix is an explicit account-ID assertion via a precondition, not just correct backend config.

The state bucket that would normally hold remote state is itself infrastructure that needs to be created first — there's nowhere "further down" to delegate that one bootstrap configuration's own state to, so it legitimately uses local state as a permanent, narrow exception.

Provider configurations aren't nodes in Terraform's dependency graph the way resources are — Terraform can't guarantee the cluster's API is actually reachable at the moment it configures the provider, producing a timing-dependent race. The fix is splitting cluster creation and in-cluster resources into two separate states.

Zero results is usually a typo or a resource that hasn't been created yet in this environment. Multiple results, without a tie-breaker like most_recent = true, fails the plan outright with an ambiguous-match error — arguably the safer of the two failure modes, since it surfaces immediately rather than silently.

A provider-native resource first, then user_data/cloud-init, then a Packer-built image, then a configuration-management tool — a provisioner is the last resort after all of these are genuinely exhausted.

It replaces the older null_resource pattern as the provider-agnostic, built-in resource for holding a provisioner or a triggers_replace value when there's no real cloud resource to attach it to.

It would create a dependency cycle — the resource would depend on its own completed creation to compute its own configuration. self.<attribute> refers to the current resource's own attributes without that cycle.

A timing race between the security group rule's API "success" response and its actual enforcement — production's tighter security group takes slightly longer to fully propagate than dev's more permissive one, and remote-exec's SSH attempt can land in that gap.

Filter on the most specific identifying attributes available — a fully-qualified, environment-and-service-prefixed name, or a combination of tag plus VPC scope — rather than a single loosely-shared tag that can match more than one real object.

Its rendered result is a plain, diffable string argument, fully visible in terraform plan output — a provisioner's effect is completely invisible to plan and untracked in state.

It updates Terraform's understanding of current reality and shows exactly what changed, without touching real infrastructure and without proposing any remediation — pure detection, fully separated from any fix decision.

Update .tf files to match reality (if the change was legitimate), apply -refresh-only then a normal apply to revert it (if the change was wrong), or ignore_changes/removed (if the resource shouldn't be Terraform's concern at all).

moved tells Terraform two addresses are the same real object, avoiding a destroy-and-recreate on a rename/refactor. removed tells Terraform to stop managing a resource entirely, with an explicit choice (destroy = true/false) about whether the real infrastructure should be deleted too.

Paired with an import block, it inspects a real resource and writes matching HCL automatically, instead of requiring hand-written configuration. It's still experimental, doesn't work for count/for_each-targeted resources that don't already exist in config, and doesn't reach into module-internal resources.

-replace is scoped to one specific apply invocation and leaves no persistent marker. taint persists in state until the next apply, which can surprise a completely unrelated later apply that nobody remembers the taint was there for.

The plan shows 1 to add, 1 to destroy — Terraform has no "rename" concept, only address identity. A moved block is what supplies the "these are the same object" information Terraform can't infer on its own.

The hand-written (or generated) .tf configuration doesn't yet exactly match the real bucket's attributes — the import itself already succeeded; re-running it doesn't help. The fix is adjusting the configuration to match what the plan diff shows, iterating until it's clean.

terraform apply -refresh-only first (to accept the current drifted state), then a normal terraform apply (to revert it back to the originally-declared, narrower rule) — never skip the refresh-only step first, or the revert plan can be confusing to read.

tflint catches provider-specific schema mistakes (invalid instance types, deprecated arguments). Checkov catches security/compliance misconfigurations (unencrypted storage, open ingress). Neither is a superset of the other — most teams run both.

Plan mode (command = plan) answers "would Terraform compute the right values" without touching real infrastructure — fast, often free. Apply mode (command = apply) answers "does the value match reality after real creation" — slower, needs real provider access unless mocked.

It fakes provider responses entirely, so even command = apply tests run fast and fully offline with no real credentials or infrastructure — useful for testing logic that only exists post-apply without paying real provisioning time/cost.

Go's defer guarantees the destroy call runs when the function returns, including on failure — but only if the defer statement was actually reached. Placing it first ensures cleanup happens even if InitAndApply itself panics.

It verifies each module's own internal correctness, not its effect on other configurations consuming its outputs, and it can't catch a genuinely novel misconfiguration outside any policy library's coverage — a green CI run narrows what a human reviewer needs to check, it doesn't eliminate the need for one.

Most checks probably don't actually need real, post-apply values — defaulting to the most expensive test mode rather than the cheapest one that answers the question. Converting logic-only checks to command = plan (or mocking) would likely cut most of that time.

It genuinely provisions real infrastructure and incurs real cost, and a crashed test run (never reaching its defer terraform.Destroy) can leave real, orphaned resources — a dedicated, isolated test account contains both the cost and the risk.

The apply stage must never re-run terraform plan — it must consume the exact plan artifact a human already reviewed, or the entire point of reviewing the plan is defeated.

CI requests a signed JWT from GitHub's OIDC provider, then exchanges it for short-lived STS credentials scoped by an IAM trust policy's conditions (repo, branch) — nothing long-lived is stored anywhere, and credentials expire automatically.

It only controls whether a specific job, as currently written, runs under normal circumstances — it provides no actual guarantee, since a different workflow run or a modified workflow file could bypass it. The IAM trust policy's own conditions are the real boundary.

It's Atlantis's built-in equivalent of a GitHub Environment approval gate — atlantis apply is refused unless the PR already has required approvals and is in a mergeable state.

A git revert of the offending commit, run through the exact same plan/apply pipeline as any other change — it produces a new, real plan to review, not an instant restoration of prior infrastructure.

Terraform's own state-serial check refuses to apply a plan whose expected starting state no longer matches reality. A concurrency group on the apply job (or Atlantis's native per-project locking) queues the second PR's apply instead of racing it.

A PR from a feature branch (potentially untrusted or compromised) could trigger a workflow run capable of assuming a production-capable role, entirely bypassing the "only merges to main apply" logic that exists only in workflow YAML, not in the actual IAM trust boundary.

The custom tooling read raw attribute values without checking each field's own sensitive marker in the JSON — sensitive = true only auto-redacts through Terraform's own built-in formatters; hand-rolled JSON-consuming tools must check and respect that marker themselves.

Sentinel is HCP Terraform/Enterprise-native, deeply integrated with the managed run pipeline, but doesn't work with OpenTofu at all. OPA/Conftest is vendor-neutral, evaluating plan JSON as an ordinary CI step, working identically with Terraform or OpenTofu.

A hard-mandatory policy with no override path can block a genuine, time-sensitive emergency change entirely. Soft-mandatory with an audited override preserves normal-operations enforcement while adding the escape valve a real incident needs.

The legacy unlimited-seat Free plan ended March 31, 2026; the new tiers bill per managed resource (Essentials/Standard/Premium). This is a real budget line item that makes self-hosted backends and third-party TACOS platforms genuine, not just academic, alternatives at scale.

A well-designed module bakes compliance in by default, making the compliant choice the easy choice structurally — policy as code only ever fires after someone has already written non-compliant configuration, catching what slipped past the module.

It's a false abstraction — the two services are structurally different enough that hiding them behind one interface accumulates ever-growing per-cloud conditionals, the same god-module anti-pattern from module design applied one level up.

Sentinel only runs inside HCP Terraform/Enterprise and has no OpenTofu integration — this is a direct mismatch with the OpenTofu decision. OPA/Conftest is the vendor-neutral, correct recommendation instead.

It should prompt investigating whether the check is miscalibrated specifically for dev's lower-stakes risk profile, likely followed by scoping its enforcement level per environment. It shouldn't automatically prompt tightening enforcement further, which would add friction without fixing a genuine environment-specific mismatch.

The pipeline's own existing artifacts — PR history with each plan, GitHub Environment required-reviewer approval records, and CI logs tied to short-lived OIDC identities — primary evidence generated automatically at the time each change happened, stronger than a separately-maintained log.