A utilities team stores a Dockerfile next to their meter-reading service. What is that file’s correct role?
Select an answer to reveal the explanation.
Short Explanation
A Dockerfile is the baking recipe, not the cake and not the waiter. You change the recipe and rebuild to get a new image; the running service is something else entirely.
Full Explanation
A Dockerfile is a text recipe: ordered instructions that docker build executes to produce image layers for the meter-reading service. It describes how to assemble the filesystem and metadata of an image—base selection, package installs, file copies, and default process settings. It is build-time input owned by the utilities team next to source, not the live HTTP process and not a Kubernetes API object. Changing the recipe and rebuilding is the supported path to a new image for later run or push.
The Dockerfile is not the live process that answers HTTP once a Pod is scheduled; that process comes from a container started from a built image. It is not a Deployment manifest OKE applies; Deployments are separate orchestration documents. It is not the only runtime configuration a container reads after start—ENV, mounts, secrets, and application config still apply at run time.
Exam caveat: editing a Dockerfile on disk does nothing to already-running containers until you rebuild, retag or retarget digests, and redeploy the new image. Operational check: change a LABEL or default ENV in the Dockerfile, rebuild, and confirm docker history or image inspect shows the update while an old container still references the previous image ID.