A platform team keeps interface descriptions and shutdown state for 180 IOS XE switches in Git and wants one tool to enforce that code. Leadership also wants a saved plan showing pending changes before anything reaches the devices, plus a state file recording the last applied configuration for drift reports between scheduled runs. Which automation approach matches this desired-state, state-tracked workflow for IOS XE?
Select an answer to reveal the explanation.
Short Explanation
Terraform uses your declared configuration and persistent state to track IOS XE settings, like a blueprint paired with a running change log. Its saved plan shows pending changes before they reach your switches, and its state helps report drift between scheduled runs.
Full Explanation
Terraform models an IOS XE interface as a resource declared in code. During planning, the provider reads the device and compares its observed state with the declaration; Terraform records managed resource state between runs, and a saved plan can preview proposed changes. That persistent state supports the requested drift workflow. Ansible check mode can preview supported task changes, but the cisco.ios.ios_config module does not maintain Terraform-style persistent state between runs. A refresh-only Terraform workflow updates state from the device but deliberately makes no changes, so it does not enforce declared interface values. An apply workflow can enforce code and update state, but applying without first reviewing a saved plan omits the requested preview. Check that the chosen IOS XE provider and resource support the device and configuration you need, and configure the provider's required device access.