A new hire’s laptop runs a UCS inventory script fine, but the CI container fails importing the same modules. Which 12-factor dependency practice prevents that class of failure?
Select an answer to reveal the explanation.
Short Explanation
Declared dependencies are a packing list—everyone loads the same crate. ‘Works on my laptop’ implicit packages leave the CI container missing modules the developer never wrote down.
Full Explanation
Explicit dependency declaration—requirements.txt, a lock file, or equivalent—plus installing that isolated set inside the container makes builds reproducible. CI and production then resolve the same civic library versions the developer intended, independent of whatever happened to be preinstalled on a laptop. Assuming the base OS image already contains every Python package from a developer’s machine fails because base images are intentionally lean and inevitably drift from personal environments. Skipping dependency files and documenting “pip packages as needed” only in a wiki leaves automation nothing executable and invites silent omissions that surface first in production. Vendoring nothing while relying on apt packages that differ between Ubuntu laptops and Alpine builders couples the application to divergent distro packaging and breaks hermetic container installs. Exam caveat: a language lock file without a pinned base image digest can still drift across rebuilds; pin both application dependencies and the FROM digest for true reproducibility. Operational check: build in a clean CI container that has only the declared dependency files, run the test suite there, and fail the pipeline if any import depends on an undeclared host package.