Transit ops already has hundreds of working Ansible plays and trained operators; leadership asks whether to rip-and-replace with Terraform next quarter for the same VLAN work. What does 5.4 emphasize?
Select an answer to reveal the explanation.
Short Explanation
Hundreds of working plays are like a well-stocked tool crib—switching cost is a real requirement. Greenfield estates that want state-backed drift detection may still choose Terraform when the stem says so.
Full Explanation
DEVCOR 5.4 emphasizes identifying a CM solution from requirements, including switching-cost realities. When transit ops already has hundreds of working Ansible plays and trained operators, leadership’s urge to rip-and-replace with Terraform next quarter for the same VLAN work must weigh that investment carefully. Existing plays and trained staff are valid requirements that can justify keeping Ansible rather than forcing a tool change for its own sake across the municipal estate.
Always switching to Terraform because Ansible investment is never a valid requirement fails 5.4’s requirement-driven mindset. Requiring Puppet as the only way to preserve prior automation investment is wrong on both tool choice and v1.1 status. Deleting all plays and rewriting everything as shell one-liners for compliance destroys operational value without satisfying modern configuration-management goals.
Exam caveat: if new requirements mandate plan/state artifacts that Terraform uniquely fits, a migration may still be justified—but the stem here stresses switching cost. Score the requirement set, not brand loyalty or blog hype.
Operational check: list inventory of plays, skills, and ticket SLAs; present a keep-Ansible option versus a Terraform migration cost before any rip-and-replace decision lands in CAB.