The core Terraform workflow (Write, Plan, Apply)
Free HashiCorp Certified: Terraform Associate (004) practice — 6 questions on The core Terraform workflow (Write, Plan, Apply), with explanations. No sign-up. Full 12-question mixed test →
A `terraform plan` shows: `-/+ aws_instance.web must be replaced` because the `ami` argument changed, and `ami` is a ForceNew attribute. Nothing else in the configuration changed. The team wants to apply only this replacement, without Terraform evaluating or touching any other resource in the state, and without editing any .tf files. Which command should they run?
-target restricts the plan/apply operation's scope to the named resource (and its dependencies), so Terraform only evaluates and applies that resource, ignoring the rest of the configuration and state — exactly what's required here since the replacement is already detected from the config diff.
An engineer wants to preview exactly what resources and attributes would be removed if `terraform destroy` were run — without actually deleting any infrastructure. Which command produces this preview?
terraform plan -destroy generates a speculative destroy plan, showing every resource that would be removed, without modifying real infrastructure or requiring confirmation.
When you run `terraform apply` directly (without passing a previously saved plan file), what does Terraform do immediately before generating and displaying the plan for your approval?
By default, terraform apply (like terraform plan) refreshes the state of managed resources against real infrastructure first (unless -refresh=false is passed), ensuring the plan is computed against current real-world values.
A CI/CD pipeline needs a full, machine-readable JSON representation of a Terraform plan (for feeding into a policy-as-code tool like OPA) rather than just log output. Which command sequence is the correct, documented way to produce this?
The documented pattern for policy-as-code integration is to save a binary plan file with -out, then convert it to a full JSON plan representation using terraform show -json <planfile>, which HashiCorp's policy tooling (like Sentinel/OPA integrations) is built to consume.
An engineer wants to generate a visual representation (consumable by Graphviz) of the dependency order in which Terraform will create, update, or destroy resources, without applying any changes. Which command should they use?
terraform graph outputs the resource dependency graph in DOT format, which can be piped into Graphviz (e.g., `terraform graph | dot -Tsvg > graph.svg`) to visualize the order of operations Terraform will follow.
An engineer runs `terraform plan -out=tfplan`. Before they run `terraform apply tfplan`, a teammate applies an unrelated change directly through the cloud console, altering the real-world state of a resource referenced in that saved plan. What happens when the engineer then runs `terraform apply tfplan`?
A saved plan file is tied to the specific state snapshot it was generated against. If the real state changes before the plan is applied, Terraform detects the mismatch and errors out (commonly surfaced as a stale-plan error), forcing the user to regenerate the plan against current state rather than risk applying an outdated diff.
Ready for the real thing?
The full course: two full-length practice tests, video lessons for every exam domain, hands-on labs and detailed explanations.
undefined $34.99 with code FREETEST33 — valid through Sep 23.
Get my $34.99 deal →