What must the Docker build include so the Meraki location consumer is a self-contained containerized application?
Select an answer to reveal the explanation.
Short Explanation
Pack the lunch and the utensils in the same box—source plus locked requirements inside the image. Counting on whatever happened to be on one laptop is not containerized.
Full Explanation
A self-contained Meraki location consumer image must copy the application (or built artifact) and install locked requirements inside the image rather than relying on the laptop’s packages. Whatever host runs the container may lack the engineer’s site-packages; the image must carry its own dependency closure. That packaging is what “containerized application” means for municipal CD.
Assuming packages already on the developer laptop will be present on every host that runs the container breaks as soon as the image lands on a clean worker or CI runner. Omitting dependency install from the image and bind-mounting the engineer’s site-packages at runtime only ties production to a personal workstation path and is not a portable image. Shipping an empty image and installing dependencies manually after kubectl exec on each pod recreates snowflake nodes and abandons immutable, prebuilt artifacts.
Exam caveat: locked requirements inside the image are part of the build, not a post-start SSH or exec chore; reproducibility depends on that bake-in. Operational check: build the Meraki location consumer with COPY/ADD of app code and a pip (or equivalent) install of the lockfile, run the image on a host without those packages installed, and confirm imports succeed without bind-mounting a laptop virtualenv.