After an emergency, an elections-office engineer edits binaries on the running production host so voters can keep checking polling locations. Why does that violate cloud-native build/release/run staging?
Select an answer to reveal the explanation.
Short Explanation
Build, release, and run are like stamp, label, and ship: once the package leaves the dock, you do not re-solder it on the truck. Editing binaries on the host erases the answer to “what is in prod?” Keep stages separate and releases immutable.
Full Explanation
Build/release/run staging forbids editing binaries on the running elections-office production host because source becomes an immutable build, build plus config becomes a uniquely identified release, and only that release should run. Live binary edits collapse the stages: production no longer matches a known build, rollback targets disappear, and the next deploy may overwrite or conflict with emergency mutations. Citizen-facing polling-location checks must recover by shipping a proper release, not by soldering the live host.
OCI Compute does allow SSH under policy in many tenancies; “SSH is impossible” is false and misses the staging principle. Production hosts absolutely receive environment configuration; forbidding all config confuses externalized config with the ban on mutating the built artifact in place. Restricting production to container images built only on developer laptops is an unnecessary and often unsafe constraint—the point is a controlled immutable build pipeline, not “laptops only.”
Exam caveat: the violation is collapsing build/release/run by mutating the running release; emergency fixes still go through build → identified release → run, even when the change is urgent.
Operational check: reproduce the fix in source, produce a new build and uniquely identified release, deploy that release, and confirm no lingering manual binary edits remain on the production hosts.