A team uses Cloud Build for CI/CD. The builds are taking longer than expected due to dependency downloads. What is the best practice to speed up builds?
Kaniko or Docker layer caching stores previously built layers in a cache image, so Cloud Build reuses unchanged dependency layers instead of re-downloading and rebuilding them each run. This directly cuts the dependency-download time lengthening builds.
Why this answer
Docker layer caching allows Cloud Build to reuse previously built layers, significantly reducing the time spent re-downloading and re-installing dependencies. By specifying a cache image or using Kaniko's built-in cache, only changed layers are rebuilt, while unchanged dependency layers are pulled from the cache instead of being fetched from the internet each time.
Exam trap
The trap here is that candidates confuse increasing compute resources (Option A) with solving a network-bound problem, or they mistakenly think storing dependencies in a repository (Options C and D) eliminates the need to download them, when in fact only layer caching avoids re-downloading by reusing previously built layers.
How to eliminate wrong answers
Option A is wrong because increasing the machine type to e2-highcpu-32 primarily speeds up CPU-bound compilation tasks, not network-bound dependency downloads; the bottleneck here is network latency and download throughput, not CPU cores. Option C is wrong because Artifact Registry stores built packages (e.g., container images, Maven artifacts), not raw dependency files; pulling pre-built packages from Artifact Registry does not address the initial download of dependencies during the build process. Option D is wrong because Cloud Source Repositories is a Git repository hosting service, not a dependency cache; storing dependencies there would require manual management and does not integrate with standard package managers (e.g., pip, npm, Maven) to avoid re-downloading.