City platform engineers containerize a Python DNA Center collector. What does using Docker for that application primarily establish?
Select an answer to reveal the explanation.
Short Explanation
The recipe travels with the meal—FROM and app bits define the runtime inside the image so any Docker kitchen can cook it. Installing Python on every VM is the non-container design.
Full Explanation
Using Docker for a Python DNA Center collector primarily establishes a Dockerfile FROM plus application bits so any Docker host can run that image-defined runtime. The recipe travels with the meal: the base image and installed app define the interpreter and dependencies inside the artifact. Municipal operators then run the same image without preparing a unique language install on every possible VM.
Requiring operators to install the language runtime on every VM that might run the app is the pre-container model Docker replaces for this use case. Claiming only Kubernetes scheduling rules matter and the image need not declare a runtime ignores that containers still need a defined userland from the image. Mandating Compose and Helm charts before a single image may exist confuses orchestration packaging with the basic containerization outcome—an image that runs on Docker.
Exam caveat: containerizing establishes a portable runtime-in-the-image; orchestrators consume that image later but are not prerequisites for the image itself. Operational check: build the DNA collector image from a Dockerfile that includes FROM and app install/copy steps, then run it on a clean Docker host that does not have the city’s Python packages preinstalled.