An image should be reusable across environments. A port, greeting or data location often belongs to launch-time configuration rather than a source edit and rebuild. Environment variables are one way to deliver those strings. They are not automatically secret storage: an application can print them, diagnostic tools can expose them, and operators with sufficient process access may inspect them.
Keep ordinary configuration and secret material conceptually separate. A variable such as TOKEN_FILE=/run/secrets/api_token can identify where a runtime-provided secret is expected, while the token bytes remain outside a configuration report. That reference alone does not establish who created the file, its permissions, how it was delivered or who can read it. Our fixture receives only a list of available paths, never secret contents.
Resolve precedence explicitly
The lab has built-in defaults, optional image values and final runtime overrides, in that order. A missing key keeps the earlier value; an explicitly empty string is still supplied. This matters for a greeting that the caller intentionally wants to omit. Applying value or default after the merge changes that decision.
config = {"PORT":"8000", "GREETING":"hello"}
config.update({"GREETING":"image greeting"})
config.update({"PORT":"8123", "GREETING":""})
print(int(config["PORT"]))
print(repr(config["GREETING"]))Environment variables arrive as strings. Parse and validate the resolved port before binding, using the application's stated grammar. The task accepts ASCII decimal digits only, permits leading zeros, and rejects signs, whitespace, zero and values above 65535. Python's broad Unicode digit predicates recognize more characters than this contract accepts; test the actual permitted alphabet instead of assuming every numeric-looking string is valid.
Build-time and runtime secrets are separate
A secret needed while building has a different lifetime from a token needed by the running service. Putting a credential into Dockerfile ARG or ENV, copying it and deleting it later, or embedding it in a command can leave material in build outputs or metadata. Docker's build-secret mounts address a particular build-time delivery need; runtime secret delivery requires its own tooling and policy. The course does not connect to any account or secret manager.
The build rejects unknown environment keys so a direct TOKEN value cannot silently become part of the public report. That is an educational allowlist for this API, not a universal defense: a secret can be placed under any innocent-looking variable name. A real application also needs deliberate logging, access controls, rotation and incident handling.
Validate references without touching files
Validate every supplied secret path and require a nonempty TOKEN_FILE reference to match an available path exactly. The allowed subtree is /run/secrets/, with canonical components and no traversal. An empty reference means no secret. Do not open those paths during grading; they are fixture strings.
Before building, compare a missing GREETING with an empty GREETING, and an absent TOKEN_FILE with a nonempty reference to an unavailable path. The bug hunts isolate override precedence and truthiness. Your result demonstrates deterministic merging and reference validation. It does not prove a running service has received a secret, that its contents stay confidential or that a deployment is ready for production.