DOP-C02 Practice Question 3: CodeBuild Cache Build Duration

CodeBuild supports two cache types. An S3 cache stores the directories you name in the buildspec's cache.paths in an S3 bucket and restores them at the start of the next build, regardless of which build host runs. Because the problem is a repeatedly re-downloaded dependency directory and the fleet is on-demand, a different host each time, an S3 cache is exactly the right tool, and it requires only a project setting plus a cache.paths entry rather than any rewrite of the build logic.

Option B treats a network-bound problem as a CPU problem. A larger compute type gives more vCPU and memory; it does not stop the build from fetching the same packages from the internet on every run. It also raises cost per build minute.

Option C targets the wrong artifact. Local Docker layer caching speeds up docker build by reusing image layers, which helps projects that build container images. These builds are populating a node_modules directory in the build workspace, not producing Docker layers. Local caches also live on the build host, so they are unavailable to a fresh on-demand host.

Option D does not fix the problem on its own. Reusing the same reserved-capacity host does not by itself keep node_modules between builds; AWS's fleet guidance still recommends turning on a cache mode to benefit from reuse. It also contradicts the stem: a reserved capacity fleet is dedicated, always-on infrastructure that keeps incurring cost for as long as it is provisioned, whether or not builds are running. The S3 cache solves the stated problem directly and at trivial cost.

References: Build caching in CodeBuild; Run builds on reserved capacity fleets