After a failed Webex notification deploy, an engineer SSHes into the live container and edits Python files to hotfix production. Which 12-factor rule did that break?
Select an answer to reveal the explanation.
Short Explanation
Build stamps the artifact, release marries it to config, run starts processes—like factory, staging dock, and open street. Editing live files collapses those stages into a snowflake nobody can redeploy.
Full Explanation
Build, release, and run are distinct stages: build produces an immutable artifact, release binds that artifact to a configuration set, and run starts processes from the release. Do not mutate a running release on disk to invent a new one—that collapses the stages into an unreproducible snowflake nobody can redeploy for the civic API. Leaving dependencies undeclared so production can pick packages from the host OS freely destroys build purity and makes “the same release” meaningless across nodes and base images. Compiling configuration into the image at build so run never reads the environment merges build and release, multiplying images per environment and slowing routine endpoint changes. Writing logs only to encrypted USB drives attached during the run stage is an operational fantasy that ignores stream logging and central collection on container platforms. Exam caveat: hot-patching a live container for an emergency still leaves you without a rebuildable release; capture the fix back into the build pipeline and cut a proper release afterward. Operational check: for a municipal deploy, verify the running image digest matches the build artifact, confirm configuration came only from the release’s injection mechanism, and ensure no manual edits exist inside the container filesystem relative to the image.