A fire district’s Ansible playbook must be safe to re-run after a partial failure without creating duplicate VRFs on the same routers. Which automation design best provides that safety?
Select an answer to reveal the explanation.
Short Explanation
Idempotent automation is like setting the station thermostat to 72—pressing the button twice does not invent a second furnace. Check or declare the VRF you want, then converge. Wiping everything or inventing new names just makes the next outage harder.
Full Explanation
Fire-district Ansible playbooks that must be safe to re-run after partial failure without creating duplicate VRFs need idempotent create/update operations: check desired state before applying or use declarative APIs that converge to the same result. Idempotency is the automation design property that makes retries safe on civic routers. Without it, partial failures spawn duplicate or conflicting VRFs.
Always deleting every VRF first then recreating them turns every run into a destructive wipe. Appending a random suffix to each VRF name on every run avoids collisions by creating sprawl. Disabling API error checking so failed creates are ignored hides problems and still is not idempotent convergence.
Exam caveat: idempotency includes correct check-mode/diff behavior and handling of present-but-wrong state, not only present/absent. Operational check: run the playbook twice against a lab router, confirm the second run makes no unnecessary changes, then interrupt mid-run and re-run to verify convergence. Store that test as CI evidence for the fire-district automation guild. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.