An engineer proposes building custom orchestration code to automate a ten-minute manual task that runs twice a year. The code would need ongoing maintenance whenever the connected systems change. Which consideration should MOST influence the decision?

Automation decisions weigh benefits against considerations such as complexity, financial cost, and ongoing maintenance. A task that takes ten minutes twice a year saves very little labor, while custom orchestration code requires development time, testing, documentation, and updates whenever connected systems change. Unmaintained automation also accumulates technical debt and can fail silently when an interface changes, introducing new risk. For a rare, short, well-documented task, a clear runbook is often the better investment; the decision should rest on whether cost and complexity exceed the gain. The idea that automation always reduces risk is false, since poorly maintained scripts can perform the wrong action at machine speed, and ignoring cost is not a defensible engineering position. Manual tasks can be audited through tickets, change records, and logs, so auditability is not a reason to automate this particular task. Skipping guardrails because a task is infrequent is backward; infrequent automation is the most likely to break unnoticed and the least likely to be watched when it runs. Exam caveat: the same consideration can favor automation for frequent, error-prone tasks where the efficiency gain is large. Operational check: estimate annual hours saved against build and maintenance effort, and document the result in the decision record.