Before changing campus IOS XE routes with Terraform, change control wants a preview of creates, updates, and destroys. Which workflow order satisfies that review?
Select an answer to reveal the explanation.
Short Explanation
Plan is the dress rehearsal; apply is opening night. When reviewers need the delta first, skip neither step—and do not borrow Ansible’s check mode as a Terraform synonym.
Full Explanation
Change control for municipal routing wants a human-reviewed preview before anyone mutates IOS XE. The Terraform workflow order that satisfies that review is to run terraform plan to show creates, updates, and destroys, then terraform apply only after the delta is accepted. Plan is the CAB-friendly artifact; apply is the commit step. Skipping the preview undercuts the very control board that asked for visibility into route changes on the campus edge.
Running terraform apply immediately with no plan when a review is required fails the stated process and can push unintended destroys. Using ansible-playbook --check as the Terraform plan step fails by swapping tools mid-workflow—Ansible check mode is not Terraform’s resource delta against state. Destroying the entire root first, then recreating without reviewing a plan, maximizes outage risk and still never produced a reviewed create/update/destroy list beforehand.
Exam caveat: CI pipelines may separate plan and apply into gated jobs; that is still plan-then-apply. Auto-approve flags can violate local CAB policy even when the CLI permits them, so civic pipelines should keep an approval gate.
Operational check: capture plan output for the route change, attach it to the change ticket, apply only after approval, and confirm the executed delta matches the reviewed plan on the target IOS XE devices.