Rebuilds of a city’s permit-intake image are slow because application source changes on every commit. How should Dockerfile instructions be ordered to protect the layer cache?
Select an answer to reveal the explanation.
Short Explanation
Put the ingredients that almost never change on the lower shelves of the cake, and the frosting you tweak daily on top. That way you reuse the heavy layers instead of remaking them every time.
Full Explanation
Each Dockerfile instruction typically yields a layer the builder can reuse when the instruction text and its inputs are unchanged. For the city’s permit-intake image, install rarely changing dependencies before the frequently changing application COPY so heavy install layers stay cache hits across commits that only tweak source. Stable work belongs lower in the file; volatile application COPY belongs higher so daily changes do not force remaking dependency layers.
Copying application source first and then installing dependencies busts the cache early whenever source changes, forcing reinstalls on every commit. Putting the most frequently changing COPY instructions before dependency installs has the same cache-busting effect. Disabling layer caching entirely guarantees slow rebuilds and abandons a primary Dockerfile performance lever for municipal CI agents.
Exam caveat: cache keys include context checksums—changing an early COPY of a lockfile or package manifest still rebuilds everything below, so keep those files intentional and ordered carefully. Operational check: rebuild twice with only an application source tweak and confirm dependency install steps report cache hits while the final application COPY or build step re-executes.