A regional blood-bank courier app COPY-includes a .env file that holds a storage account key, and that layer is now in every registry replica. What is the correct image-hygiene fix at build time?
Select an answer to reveal the explanation.
Short Explanation
Baking a storage key into an image layer is like laminating your house key into every photocopy of the floor plan. Leave secrets out of COPY, ignore them in .dockerignore, and hand configuration in when the container actually runs.
Full Explanation
Secrets must never become image layers. The blood-bank courier fix at build time is to exclude .env and similar secret files via .dockerignore or by simply not COPY-ing them, then inject storage keys and other configuration at run time through environment variables, Key Vault references, or host secret stores. Once a key is in a layer, every registry replica that received that image still holds it until the image is purged and replaced.
Encrypting Dockerfile comments that mention the key name does nothing to the secret already baked into a COPY layer. Pushing only to a Basic SKU ACR does not remove the secret from layers; SKU choice is unrelated to secret hygiene. Renaming .env to .config is security through obscurity—scanners and attackers still read file contents inside the image.
Exam caveat: rebuilding without the secret is not enough if old tags remain pullable. Rotate the exposed storage key, delete or untag compromised manifests, and run retention cleanup so historical layers are not still downloadable.
Operational check: build a fresh image, then docker history / dive / export and grep for the former key material; confirm .dockerignore lists .env, and verify ACI or Container Apps supplies the key via secure environment settings or Key Vault instead of image contents.