docker build for a 911-dispatch helper is unexpectedly large and slow. What should the team understand about the build context?
Select an answer to reveal the explanation.
Short Explanation
Build context is the suitcase you hand the daemon. Without a .dockerignore packing list, you may ship the whole closet—including secrets and .git—and wonder why the trip is slow.
Full Explanation
When you run docker build, the build context directory is uploaded to the daemon as the set of files available to COPY and related instructions. A missing or weak .dockerignore for the 911-dispatch helper can send .git, local secrets, and bulky folders such as node_modules, which slows the transfer and risks accidental inclusion of files that must never enter a municipal image. Professional image hygiene includes curating what leaves the developer workstation toward the daemon—not only what the Dockerfile explicitly copies afterward.
The daemon does not receive only the Dockerfile with nearby files never uploaded. Build context is not whatever is already in OCIR; OCIR stores published images after push, not your local upload set. Only files listed in ENTRYPOINT are not the filter for context, and .dockerignore is absolutely used to control context size and contents.
Exam caveat: files you never COPY still travel in the context upload if not ignored, so network and disk cost hit before any COPY instruction runs—ignore early. Operational check: add a .dockerignore, rebuild, compare the reported context size, and verify required source still COPYs while secrets directories and VCS metadata stay excluded from the upload.