A zoning-board API image embeds the production database URL and a plaintext password so “it just works” in prod. What twelve-factor-aligned fix should the team apply before promoting the same artifact to test and production?
Select an answer to reveal the explanation.
Short Explanation
The same sealed jar of preserves should fit every kitchen—only the labels on the shelf change. Externalize config so one artifact runs in test and prod. Baking production URLs into the image forces rebuilds and couples environments.
Full Explanation
Twelve-factor alignment for the zoning-board API means keeping one built artifact and supplying endpoints, secret handles, and feature flags from the environment at runtime. The production database URL and plaintext password must not be embedded in the image; otherwise the same digest cannot promote cleanly from test to production, and secrets leak into the build layer and registry history. Externalized configuration is what makes “build once, promote many” real for municipal APIs.
Rebuilding a separate image for every environment with different hardcoded endpoints bakes environment identity into the artifact and multiplies drift between what was tested and what runs in production. Committing environment-specific passwords into the application source tree under a prod config path puts secrets in version control and still fails the single-artifact rule. Disabling TLS in lower environments so hardcoded URLs never need to change papers over configuration differences by weakening security rather than externalizing settings.
Exam caveat: twelve-factor config means environment-supplied settings and secret references for the same immutable build—not “a different image per stage” and not plaintext secrets in Git or image layers.
Operational check: promote one image digest from test to production, inject different endpoint and secret-handle values via the environment or platform secret store, and confirm the process never required a rebuild to change those values.