A city open-data portal team wants high-impact configuration changes to feel routine instead of heroic overnight projects. Which approach best matches the cloud-native goal of frequent, predictable change?
Select an answer to reveal the explanation.
Short Explanation
Automation is the boring highway from commit to running revision—the goal is frequent, predictable, low-toil change. Manual tribal checklists and giant weekend batches make high-impact work dramatic again. The principle is the goal, not picking a pipeline SKU.
Full Explanation
Frequent, predictable change for the city open-data portal comes from automating the path from commit to a running revision so releases stay repeatable and low-toil. Automation turns high-impact configuration updates into routine promotions of a known artifact instead of heroic overnight projects. The goal is a boring highway from merge to running revision, not fewer deploys or more exclusive human rituals.
A unique manual checklist invented by whoever is on call that week recreates tribal knowledge and non-repeatable risk—every change becomes a personality-dependent procedure. Batching six months of changes into one maintenance weekend reduces deploy count while maximizing blast radius and making each window terrifying. Forbidding automation so only senior architects change production over SSH concentrates risk, slows learning, and guarantees that change remains dramatic rather than routine.
Exam caveat: the principle is automated, repeatable delivery; the item is not asking you to pick an OCI DevOps pipeline product name or a particular CI vendor SKU.
Operational check: push a small config change through the automated path in a non-production environment, confirm the same steps work without SSH, and measure that the change does not require a maintenance weekend or an on-call-invented checklist.