Change advisory requires a human-readable plan file of creates/changes/destroys before any VLAN push, and the team will accept a short ramp on a new tool. Which pick best matches that business constraint?
Select an answer to reveal the explanation.
Short Explanation
When the board wants a printed delta before paint goes on the wall, Terraform’s plan file is the business fit—even if Ansible could also set the VLAN.
Full Explanation
Business constraints can dominate configuration-management tool selection on DEVCOR 5.4 items. When change advisory requires a human-readable plan of creates, changes, and destroys before any VLAN push, and the municipal team will accept a short ramp on a new tool, Terraform best matches: plan/apply and state provide the audit-friendly delta the board wants for civic network changes. That preview is first-class in Terraform’s workflow and attaches cleanly to CAB tickets.
Choosing Ansible only because playbooks “never need a preview” ignores the CAB artifact requirement—even though Ansible check mode exists, the stem’s audit-friendly create/change/destroy plan maps cleanly to Terraform plan output. Treating Puppet manifests as the mandatory CAB artifact for DEVCOR v1.1 fails the blueprint update that moved this construction to Terraform. Relying on manual CLI with screenshots instead of any CM tool fails scalability, repeatability, and honest drift detection.
Exam caveat: 5.4-style questions weigh the stated requirements; do not always pick Ansible because it is familiar if the board’s plan artifact is the decisive need. Document how plan output is stored with change records.
Operational check: produce a terraform plan for a VLAN change, attach it to a mock CAB record, then apply and show that state matches the approved delta on the lab switch.