A municipal container build currently COPYs server.key into the image. Security review requires configuring TLS material at run time. Which change correctly configures the application certificate?

TLS private keys must not be baked into immutable image layers. Security review correctly requires configuring certificate material at run time: mount the current certificate and private key into the running municipal container from a secret or volume, then reload the TLS listener. That lets ops rotate keys without rebuilding, prevents keys from living in registry history, and matches twelve-factor secret handling for civic APIs.

Committing a newer server.key into the same Dockerfile layer and rebuilding nightly fails because the key remains in image history and every rebuild still couples rotation to CI. Embedding the private key as a base64 ENV default so every replica inherits it from the image fails similarly—ENV defaults are visible in image config and swarm/k8s inspect surfaces. Publishing the private key to a public object store and curling it during image build fails confidentiality outright and still bakes retrieval into build time rather than run-time mount.

Exam caveat: an init container that fetches from a vault into a memory volume at start is still run-time configuration; the anti-pattern is COPY/ENV of PEM material into the image. Reload (or rolling restart) after rotation is part of the operational path.

Operational check: scan the image for *.key/PEM artifacts, confirm the running pod mounts a secret at the TLS path, and verify a rotated secret appears after remount/reload without a new image tag.