HashiCorp Terraform Associate
Last reviewed: May 2026
A scannable reference of architectural patterns the 004 exam tests. Read top-to-bottom, or jump to a section.
A team manually clicks through cloud consoles; nobody knows what production was supposed to look like.
Adopt IaC. Configurations live in version-controlled files — the files are the authoritative source of truth, not the cloud console.
Why: Audit trail, peer review, rollback, and replication all flow from version control. Manual provisioning has none of these.
Choose between describing the desired end state versus scripting the steps to reach it.
Terraform is declarative. You describe the target; Terraform figures out the API calls. Ansible, Bash scripts, custom SDKs are imperative.
Why: Declarative configs are idempotent and converge regardless of starting state. Imperative scripts must reason about every transition.
Engineer wants the same `terraform apply` to be safe to re-run without doubling resources.
Idempotent by design. Applying the same configuration repeatedly converges on the same state — no duplicates, no drift.
Detect when reality diverged from what configuration says (someone clicked in the console).
`terraform plan -refresh-only` reads current cloud state and reports differences against state without proposing changes.
Distinguish initial provisioning from ongoing operations.
Day 0 = design and planning. Day 1 = initial provisioning (first apply). Day 2 = ongoing operations: patching, scaling, certificate rotation, drift remediation.
Why: Most production work is Day 2. IaC tooling must support iteration, not just first-deploy.
Reduce risk of console drift; require all infra changes go through review.
GitOps with IaC: git is the source of truth, PRs trigger plans, merges trigger applies. Block direct console access via SCP/IAM.
Workload spans AWS and GCP; team wants one tool, one workflow.
Terraform with multiple providers in one configuration: `hashicorp/aws` + `hashicorp/google`. Outputs from one provider feed inputs of another.
Why: Provider-agnostic core; per-cloud SDKs live in pluggable providers. CloudFormation/ARM are single-cloud.
Standard Terraform lifecycle steps.
`init` (download providers + backend) → `plan` (preview) → `apply` (execute) → `destroy` (tear down). `plan` is read-only and safe.
Why does Terraform need a state file instead of querying the cloud each run?
State maps configuration addresses (`aws_instance.web`) to real resource IDs, tracks dependencies, and caches metadata. Without it, Terraform cannot know which cloud resources it manages vs. which were created elsewhere.
Choose between open-source CLI and HCP Terraform.
Solo / small team / no policy enforcement → OSS CLI with remote backend. Multiple teams / Sentinel/OPA policies / VCS-driven runs / dynamic credentials → HCP Terraform.
Why: Both run the same Terraform binary; HCP adds collaboration, governance, and remote-runner infrastructure.
Provision VMs vs configure software inside them.
Terraform provisions cloud resources (VMs, networks, IAM). Ansible/Chef/Puppet configure software inside the VMs. They're complementary, not competitors.
AWS-only shop debating CloudFormation vs Terraform.
CloudFormation has tighter AWS integration, native rollback, and zero state-file management. Terraform wins on multi-cloud, larger module ecosystem, and HCL ergonomics. Pick CFN if AWS-only and rollback matters most; Terraform otherwise.
Pin provider source and version for reproducible installs.
Declare in `terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
Why: Without explicit `required_providers`, Terraform assumes legacy registry namespaces and may pick incompatible versions.
Configuration has `required_providers` for AWS but no `provider "aws"` block.
Terraform creates a default empty provider configuration. AWS provider then reads `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS in its standard precedence.
Why: An explicit `provider` block is optional; it's only needed to override defaults or alias multiple instances.
Decide which version-constraint operator to use.
`~> 5.0` allows `>= 5.0, < 6.0` (any 5.x). `~> 5.0.1` allows `>= 5.0.1, < 5.1.0` (only patch updates). `>= 5.0` no upper bound. `= 5.2.0` exact. `!= 5.3.0` exclusion.
Why: The pessimistic operator `~>` only allows the rightmost version component to grow.
What does `terraform init` actually do?
Downloads providers per `required_providers`, initializes the backend, downloads module sources, and writes `.terraform/` plus `.terraform.lock.hcl`. Required before `plan` or `apply`.
A `.terraform.lock.hcl` file appeared after `init`. Commit it or gitignore?
Commit it. Lock file records exact provider versions + cryptographic checksums. Ensures every collaborator and CI runner installs identical providers.
Why: Without it, `terraform init` may pick a newer compatible version on a different machine, introducing surprise diffs.
Standardize whitespace, alignment, and indentation across `.tf` files.
`terraform fmt` rewrites `.tf` files in place to canonical style. Run in pre-commit hooks and CI.
Catch syntax errors and type mismatches without hitting cloud APIs.
`terraform validate` checks HCL syntax, type consistency, required arguments, and internal references. Local-only, no provider auth needed.
Why: Doesn't catch provider-side issues (auth, missing resources) — those surface only at `plan`.
CI runs `terraform init` repeatedly across many projects, each downloading the same providers from scratch.
Set `TF_PLUGIN_CACHE_DIR` (or `plugin_cache_dir` in CLI config). Providers are downloaded once and symlinked into per-project `.terraform/` directories.
Provider source addresses follow what format?
`<hostname>/<namespace>/<type>` — e.g. `registry.terraform.io/hashicorp/aws`. Hostname omitted defaults to public Terraform Registry. Namespace = vendor. Type = provider name.
Prevent collaborators from running an incompatible Terraform CLI version.
`terraform { required_version = ">= 1.5, < 2.0" }`. CLI refuses to operate if the running version doesn't match.
Pick provider authentication for a CI/CD runner.
Best: short-lived dynamic credentials (OIDC trust to AWS/Azure/GCP, HCP Terraform dynamic provider creds). Acceptable: env vars (`AWS_ACCESS_KEY_ID`). Avoid: hardcoded `provider` block credentials.
Why: Static long-lived secrets in config are the leading cause of leaked-credential incidents.
Where do top-level settings live?
A `terraform { ... }` block holds `required_version`, `required_providers`, `backend`, `cloud`, and experiments. Multiple `terraform` blocks across files are merged.
Resource exists in state but should no longer be Terraform-managed; the cloud resource must keep running.
`terraform state rm <addr>`. Removes from state without destroying the cloud resource.
Refactored a resource's name or moved it into a module; want to avoid destroy/recreate.
`terraform state mv <old> <new>`. Updates the state mapping without touching cloud resources.
Why: In Terraform 1.1+, prefer the `moved` block in HCL — it's reviewable, version-controlled, and works in PR plans.
Internal provider registry URL changed; existing state still references the old source address.
`terraform state replace-provider <old-source> <new-source>`. Rewrites provider references in state.
Apply crashed mid-run; DynamoDB lock is stuck and other engineers are blocked.
`terraform force-unlock <LOCK_ID>` (lock ID is in the error message). Verify nobody else is running before unlocking.
Why: Locks aren't auto-released on crash because the cleanup phase never executed.
Existing manually-created S3 bucket needs to come under Terraform management without recreation.
Write the resource block, then `terraform import aws_s3_bucket.legacy legacy-bucket-name`. State now records the existing bucket; subsequent plans show only drift.
Need to import many resources reproducibly through CI rather than ad-hoc CLI commands.
Use the `import` block (Terraform 1.5+): `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. Imports happen during `apply`, are version-controlled, and work in plan output.
Debug a cryptic provider error; need full HTTP traces.
`TF_LOG=TRACE` (most verbose). `TF_LOG_PATH=./tf.log` writes to a file. Other levels: DEBUG, INFO, WARN, ERROR.
Test an expression like `merge()` or `cidrsubnet()` against current state without applying.
`terraform console` opens an interactive REPL with the current configuration + state in scope. Useful for prototyping locals and outputs.
Visualize the dependency DAG of a complex configuration.
`terraform graph | dot -Tsvg > graph.svg` produces a Graphviz visualization of resource dependencies.
Read a Terraform output from a CI script.
`terraform output -json <name>` emits JSON safe for `jq` parsing. Plain `terraform output` is human-formatted and not script-safe.
Force a single resource to be recreated next apply.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). The legacy `terraform taint` is deprecated.
Why: `-replace` is reviewable in plan output; `taint` mutated state silently before the next plan.
Inspect what's currently tracked in state.
`terraform state list` shows all resource addresses. `terraform state show <addr>` shows attributes for one resource. For indexed resources use quotes: `terraform state show 'aws_instance.web[0]'`.
Pick a module source.
Local path → `./modules/vpc`. Public registry → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial also supported.
Pin a registry module to allow only patch updates.
`version = "~> 3.5.2"` allows `>= 3.5.2, < 3.6.0`. For minor-update tolerance, use `~> 3.0` (any 3.x). Local path modules don't support `version`.
Internal-only modules with org-wide visibility.
HCP Terraform Private Module Registry. Address: `app.terraform.io/<org>/<name>/<provider>`. Versions detected from Git tags following semver (`v1.2.0`).
Both public registry and HCP Terraform private registry detect module versions via what mechanism?
Git tags following semantic versioning (`v1.2.0` or `1.2.0`). Push a new tag → new version available.
Expose a created bucket's ARN to the calling configuration.
Inside the module: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. Caller reads it as `module.<name>.bucket_arn`.
Parameterize a module so callers can supply CIDR, name, tags.
`variable` blocks at the module root define inputs. Callers pass them inline: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
Module receives a database password as input; the value should never appear in CLI output.
Mark the variable `sensitive = true`. Apply/plan output shows `(sensitive value)`. Note: still stored plaintext in state.
Build a "platform" module that internally calls VPC + EKS + RDS modules.
A module can call other modules. Wire outputs from one as inputs to the next: `eks_subnet_ids = module.vpc.private_subnet_ids`.
Instantiate the same module N times with different inputs (e.g. one per region).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. Reference via `module.regional["us-east-1"].output_name`.
Module needs an aliased provider (e.g. for a non-default region).
Caller passes `providers = { aws = aws.us_west }` block in the `module` invocation. Module declares `configuration_aliases = [aws.us_west]` in `required_providers`.
Address a public registry module.
`<NAMESPACE>/<NAME>/<PROVIDER>` — e.g. `terraform-aws-modules/vpc/aws`. Git tags drive versions.
Reuse the same module across dev/staging/prod.
Two patterns: (1) Workspaces with one root config + per-workspace `*.tfvars`. (2) Per-environment root configs (`envs/dev/main.tf`, `envs/prod/main.tf`) each calling shared modules. Pattern 2 is more common for multi-team isolation.
Ensure CI applies exactly what was reviewed in plan, with no drift between steps.
`terraform plan -out=tfplan` saves the plan. Then `terraform apply tfplan` applies that exact plan. Refusing to re-plan eliminates time-of-check/time-of-use risk.
Decode plan output symbols: `+`, `-`, `~`, `-/+`, `<=`.
`+` create. `-` destroy. `~` update in place. `-/+` destroy then create (replace). `<=` read (data source). The replace symbol means a `forces replacement` attribute changed.
Quickly fix one broken resource without touching the rest of the config.
`terraform apply -target=aws_instance.web`. Use sparingly — bypasses dependency tracking and can leave state inconsistent. Document why each `-target` was used.
Why: HashiCorp explicitly says `-target` is for exceptional troubleshooting, not normal workflow.
Force a specific resource to be recreated.
`terraform apply -replace=aws_instance.web`. Replaces the deprecated `terraform taint` workflow.
Tear down everything in the current configuration.
`terraform destroy` (or `terraform apply -destroy`). Plans the inverse of the configuration. Requires confirmation unless `-auto-approve`.
Destroy one resource without affecting others.
`terraform destroy -target=aws_instance.web`. Same `-target` caveats as apply — use sparingly.
Detect drift without proposing changes.
`terraform plan -refresh-only`. Refreshes state from real resources and reports differences but generates no resource-modifying plan.
Why: Replaces the deprecated standalone `terraform refresh` command.
Resource A must exist before Resource B, but B doesn't reference A's attributes.
Add `depends_on = [resource_a.name]` to B. Use only when implicit attribute references can't express the dependency (e.g. IAM policy must propagate before EC2 uses it).
Replace a resource without downtime.
`lifecycle { create_before_destroy = true }`. Terraform creates the new resource first, redirects references, then destroys the old one.
Why: Default is destroy-then-create which causes downtime. Note: dependent resources must also support the change.
Prevent accidental `terraform destroy` of the production database.
`lifecycle { prevent_destroy = true }`. Causes `terraform plan` to fail if a destroy is proposed for that resource.
Why: Last-line guardrail — does not protect against `terraform state rm` followed by destroy.
Application sets a tag at runtime that Terraform keeps reverting.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. Terraform ignores drift on those attributes.
Replace an EC2 instance whenever a related launch template changes (without modifying the EC2 directly).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). The instance is replaced when any listed value changes.
CI/CD pipeline applies after a successful plan job; no human at the keyboard.
`terraform apply -auto-approve` skips the interactive confirmation. Combine with a saved plan file (`terraform apply tfplan`) to make CI deterministic.
Cloud provider rate-limits Terraform; many resource creations are failing intermittently.
`terraform apply -parallelism=5` (default 10) caps concurrent resource operations.
Two resources have no dependencies on each other.
Terraform creates them in parallel. The DAG enforces sequencing only along reference edges.
Why: Resources at the same DAG depth run concurrently up to `-parallelism`.
Variable defined in `terraform.tfvars`, `TF_VAR_region` env, AND `-var=region=...` CLI flag.
Highest wins: CLI `-var` / `-var-file` > `*.auto.tfvars` (lexical order) > `terraform.tfvars` > `TF_VAR_*` env > variable default.
Pass environment-specific variable values without checking secrets into git.
`terraform apply -var-file=prod.tfvars`. `*.auto.tfvars` files load automatically. `terraform.tfvars` loads automatically too.
Refactor a resource's name/path in HCL without destroy/recreate.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). Reviewable in PR plan; replaces ad-hoc `terraform state mv`.
Why: Lives in HCL, version-controlled, idempotent across collaborators. `state mv` is a one-shot CLI side effect.
Remove a resource from configuration without destroying it.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). Replaces ad-hoc `terraform state rm`. Set `destroy = true` to also destroy.
CI needs to know whether a plan has changes without parsing text.
`terraform plan -detailed-exitcode`. 0 = no changes, 1 = error, 2 = changes present. Drives "plan-only" PR jobs.
What does state actually contain?
Resource address → cloud resource ID mapping, attribute snapshots, dependency graph metadata, and module/provider references. Used to plan diffs and detect drift.
Single engineer prototyping locally — is local state OK?
Yes for solo throwaway work. Terraform writes `terraform.tfstate` next to the config. Switch to a remote backend the moment a second person, CI runner, or production environment is involved.
Team needs shared state across engineers, with locking + versioning, AWS-hosted.
S3 backend. Configure `bucket`, `key`, `region`. Add `dynamodb_table` for state locking. Enable bucket versioning + SSE-KMS server-side encryption.
Why: S3 + DynamoDB is the canonical AWS-hosted remote backend. Versioning recovers from corrupt or accidentally-overwritten state.
Azure-hosted shared state with no static credentials in CI.
Backend type `azurerm`. Set `use_msi = true` (Managed Identity) or `use_oidc = true` so the runner authenticates via its identity. Native blob lease handles locking.
GCP-hosted shared state with object versioning.
Backend type `gcs`. Configure `bucket` + `prefix`. GCS has built-in object generations (versioning); locking via GCS object lock.
Two engineers run apply simultaneously against the same S3-backed state.
DynamoDB lock table prevents concurrent writes. The first acquires the lock, the second sees a `state lock failed` error and must wait or `force-unlock` if stale.
Why: Without DynamoDB, concurrent applies can corrupt the S3 state file.
HCP Terraform — do I configure DynamoDB?
No. HCP Terraform handles state, locking, and encryption natively. You just declare `cloud { ... }` instead of a backend.
Migrate from local state to S3 backend.
Add the `backend "s3"` block. Run `terraform init -migrate-state`. Terraform copies the local state to S3 and prompts for confirmation.
Backend config changed (e.g. new bucket) but you don't want to migrate existing state.
`terraform init -reconfigure`. Reinitializes the backend and ignores the existing local cache. Use when you intentionally start fresh.
Manage dev / staging / prod with one root configuration.
Workspaces — `terraform workspace new staging`, `terraform workspace select prod`. Each has its own state file. Reference via `terraform.workspace` in HCL.
Why: Lightweight option. For real isolation (different IAM, separate accounts), prefer per-environment root configs.
Where does the local backend store workspace state?
`default` workspace → `terraform.tfstate` in project root. Other workspaces → `terraform.tfstate.d/<NAME>/terraform.tfstate`.
Run `terraform workspace select prod` while staging resources exist.
Staging resources are unaffected. Switching workspaces only changes which state file Terraform reads next — it's a local pointer change.
See available workspaces and the active one.
`terraform workspace list` (asterisk marks the current). `terraform workspace show` prints the current name only.
Security team asks how Terraform handles RDS passwords in state.
Sensitive values are stored **plaintext** in state. Mitigations: encrypt the backend at rest (S3 SSE-KMS, HCP native), restrict IAM access to the state bucket, and avoid putting secrets in Terraform when possible.
Why: The `sensitive = true` flag only hides values from CLI output, not state.
Compliance requires encryption-at-rest on state.
S3: enable SSE-KMS on the bucket. Azure: storage account encryption (default ON). GCS: customer-managed encryption keys. HCP Terraform: encrypted natively at rest.
Engineer ran `terraform destroy` against prod by mistake. State now empty.
Restore the previous version of the state file from S3 versioning, then run `terraform plan` to see what Terraform now thinks needs to be created/imported. Combine with cloud-side restore (snapshots, `aws backup`) for the destroyed resources.
State file looks wrong; tempted to edit it directly.
Don't. Use `terraform state` subcommands (`mv`, `rm`, `replace-provider`, `pull`, `push`). Manual JSON edits skip integrity checks and corrupt the lineage.
Inspect raw remote state JSON, or push a recovered state file.
`terraform state pull` writes current remote state to stdout. `terraform state push <file>` overwrites remote with the given file. Push is destructive — back up first.
Pass a temporary API token through Terraform without it landing in state.
Mark variable `ephemeral = true` (Terraform 1.10+). Ephemeral values are never persisted to state or plan files. To export through a module output, also mark the output `ephemeral = true`.
Why: `sensitive` is hidden in CLI but stored in state plaintext. `ephemeral` is genuinely never stored.
Difference between a `sensitive` argument and a write-only argument (e.g. `password_wo`).
`sensitive` is stored in state plaintext, only redacted in CLI. Write-only is **never** stored in state. To detect changes on write-only attrs, Terraform uses a companion version field (e.g. `password_wo_version`).
Show one element of a `count` resource in state.
Quote the address: `terraform state show 'aws_instance.web[0]'`. Without quotes, the shell may interpret the brackets.
Different teams need to operate independently without stepping on each other's state.
One state file per team (or per environment per team). Separate backends/buckets. Use `terraform_remote_state` data source to read another state read-only.
Network team manages VPC; app team needs the VPC ID.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. Reference outputs as `data.terraform_remote_state.network.outputs.vpc_id`.
Why: Read-only — the network team's state isn't locked or modified.
Configuration written against Terraform 0.13; want to use 1.x.
State files are forward-compatible: 1.x reads 0.13 state. HashiCorp recommends incremental upgrades (0.13 → 0.14 → … → 1.x) running each version against the state.
Someone modified a security group via console; want Terraform to either re-assert or accept the new state.
Re-assert: `terraform apply` — Terraform reverts to configuration. Accept: update HCL to match reality, then apply (no diff). Detect first via `terraform plan -refresh-only`.
Strongly-type a variable.
Primitives: `string`, `number`, `bool`. Collections: `list(<type>)`, `set(<type>)`, `map(<type>)`. Structural: `object({...})`, `tuple([...])`. Use `any` only when truly polymorphic.
Restrict `environment` to dev/staging/prod.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. Multiple `validation` blocks allowed; all must pass.
Output a database password without it appearing in `terraform output`.
`output "db_password" { value = ...; sensitive = true }`. CLI shows `(sensitive value)`. Still readable via `terraform output db_password` or `-json` (intentionally — for scripts).
Compute a value once and reuse it across many resources.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. Reference as `local.common_tags`. Not overridable from outside the module.
Look up an existing AMI without managing it.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. Read-only. Reference attributes as `data.aws_ami.ubuntu.id`.
Create N similar resources — pick `count` or `for_each`.
`for_each` (with map or set) when items have stable identity (region names, environment keys). `count` for "I need N copies, order doesn't matter, identity is just an index". Adding/removing in the middle of `count` causes destroy/recreate; `for_each` preserves identity.
Create one resource per item in a list of strings.
`for_each = toset(["a", "b", "c"])`. `each.key` and `each.value` both give the string. For maps: `for_each = var.users` — `each.key` = map key, `each.value` = map value.
Generate a variable number of nested blocks (e.g. ingress rules).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. The `iterator` argument can rename the iterator if needed.
Get a list of attributes across all instances of a `count` resource.
`aws_instance.web[*].id` returns a list of IDs. Works with `count` and `for_each` (but `for_each` produces an unordered map, so `values(aws_instance.web)[*].id`).
Set a value based on a condition.
Ternary: `var.is_prod ? 5 : 1`. Both branches must produce the same type.
Combine two maps; second's values win on key collision.
`merge(local.defaults, local.overrides)`. Right-most map wins. Useful for tag composition.
Read a map value with a default if the key is missing.
`lookup(var.config, "region", "us-east-1")`. Returns the default when the key isn't present. For deeply optional structures, prefer the optional `try()`.
Collapse nested lists into a flat list.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. Recursively flattens lists; preserves order.
Embed a Terraform map into an IAM policy document.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. Produces a JSON string. Inverse: `jsondecode()`.
Render a templated user-data script with values from variables.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. Template uses `${region}` syntax. Newer alternative for static rendering: `file()` + `format()`.
Carve subnet CIDRs out of a VPC range.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. First arg = parent, second = bits to extend, third = subnet number.
Read a value that might not exist; fall back to a default.
`try(yamldecode(file("config.yaml")), { defaults = true })`. Evaluates left-to-right; returns the first non-erroring expression.
Iterate over files matching a glob.
`fileset(path.module, "configs/*.json")` returns a set of paths. Combine with `for_each` to manage one resource per file.
Same provider in two regions (e.g. AWS us-east-1 + us-west-2).
Two `provider "aws" { alias = "..." }` blocks. Resources opt in via `provider = aws.us_west`. Modules accept aliases via `configuration_aliases`.
Run a shell command on a newly-created VM.
`remote-exec` provisioner inside a resource. Last-resort tool — prefer cloud-init, user data, or configuration management. Provisioners aren't tracked in state and don't re-run on drift.
Run a command that doesn't correspond to a cloud resource (e.g. CLI invocation).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. Re-runs when `triggers` change.
Continuously verify a runtime invariant (e.g. health endpoint returns 200) without blocking apply.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. Runs at plan/apply; failure is a warning, not a hard error.
Why: `check` allows scoped data sources usable only inside the check. `precondition`/`postcondition` are hard errors at plan/apply.
Fail the plan if an AMI is too old.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. Hard fail, evaluated before/after as appropriate.
Variable with a fixed-shape positional value.
`type = tuple([string, number, bool])` requires exactly three elements in that order. Different from a list (homogenous, variable length).
Strongly-type a structured input (e.g. `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` makes attributes optional.
How are `*.tfvars` files loaded?
`terraform.tfvars` and `*.auto.tfvars` load automatically (lexical order for `auto`). Other names require `-var-file=path.tfvars`.
Write automated tests for a Terraform module.
`.tftest.hcl` files with `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` is no-side-effects; `command = apply` actually creates resources.
Pass variables into test runs.
File-level `variables { ... }` block applies to all runs. Per-run `variables { ... }` overrides for that run only.
Pick a workspace execution mode in HCP Terraform.
VCS-driven (auto-plan on git push, most common). CLI-driven (developer runs `terraform plan/apply` locally, HCP holds state). API-driven (Terraform runs triggered by API, used by automation/CD systems).
Order of stages in an HCP Terraform run.
plan → cost estimation (if enabled) → policy check (Sentinel/OPA) → manual or auto-apply. Mandatory policy failures or run-task failures halt the pipeline.
Enforce that all S3 buckets are encrypted, blocking apply if violated.
Sentinel policy with hard-mandatory enforcement. Inspects the plan; failure blocks apply. Soft-mandatory allows admin override. Advisory logs but never blocks.
Integrate a third-party security scanner into the HCP Terraform run pipeline.
Run task at the post-plan stage. HCP POSTs the plan to your endpoint; the endpoint replies pass/fail. Mandatory enforcement blocks apply on failure; advisory only warns.
Show the impact of a pull request before merging.
Speculative plans run on PRs (or branches), comment results back to the PR, and never apply. Triggered automatically when VCS integration is enabled.
Avoid storing AWS access keys as static secrets in HCP Terraform variables.
Dynamic provider credentials. HCP Terraform requests short-lived credentials via OIDC trust to AWS/Azure/GCP. No static keys; per-run identities; audit-friendly.
Why: Static keys leak. OIDC trust binds credentials to the workspace + run, expires within the hour.
Share the same provider credentials across many workspaces.
Variable sets. Define once at the org/project level, attach to many workspaces. Updates propagate without per-workspace edits.
What is the Default Project in HCP Terraform?
A built-in project that exists in every organization and cannot be deleted (renaming is allowed). All workspaces belong to it unless explicitly assigned to another project.
Apply downstream workspace whenever an upstream workspace finishes a successful apply.
Run triggers. Configure source workspace(s) on the dependent workspace; HCP queues a run on the dependent after each successful upstream apply.
