A harbor-ferry ticketing team rebuilds the same Node image after every one-line route change and waits while package installs run again. Which Dockerfile change keeps the expensive OS and package layers cached across those frequent app edits?

Docker builds images as a stack of layers, and each instruction is cached only while its inputs stay unchanged. When apt-get and other OS package installs sit above the COPY of application source, those expensive layers remain valid across frequent one-line route edits; only the thinner application layers rebuild. That ordering is exactly what the ferry ticketing team needs after every small Node change.

Moving WORKDIR below the application COPY does not protect package layers. WORKDIR only sets the filesystem context for later instructions; it does not control whether apt-get stays cacheable when source files change. Putting the application COPY first and then running apt-get is the reverse of good hygiene: every source edit invalidates the cache for the package install that follows, so the team keeps waiting through full installs. Refreshing AKS node images is an orchestration and host-patching concern; it does not rewrite Dockerfile layer order or restore build-time cache for local or CI builds.

Exam caveat: layer caching also depends on identical preceding instructions and build context. Changing an early ARG, FROM, or apt package list still busts everything beneath it, even when application COPY is correctly ordered last.

Operational check: after reordering the Dockerfile, change only a route file and rebuild with BuildKit timing or --progress=plain. Confirm the apt-get step shows CACHED while the final COPY and app layers show RUN or COPY executed.