DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Split the build into multiple parallel build actions.

  Why it's wrong here

  Splitting a build into parallel actions in a pipeline increases overall throughput by running independent stages concurrently, but it does not shorten the execution time of the sequential compilation steps within a single CodeBuild project. A typical compile has a dependency chain (configure, compile, link, test) that must execute in order; forcing parallelism would require decomposing the build into independently compilable modules, which is a major refactor and introduces overhead for artifact passing. Thus, it addresses pipeline throughput, not the specific slow build duration.

• ✗

  Use multiple build environments to distribute the work.

  Why it's wrong here

  Configuring multiple CodeBuild environments does not distribute one build's workload; each environment is an isolated container for a separate build job per project. CodeBuild associates one environment with one build run, so spinning up several environments would simply create multiple independent builds rather than splitting the compilation of a single project. Multiple environments are intended for building for different platforms (e.g., Linux vs. Windows) or runtimes, not for partitioning one build's tasks, so it leaves the original slow build untouched.

• ✓

  Enable caching in the build project to store dependencies in Amazon S3.

  Why this is correct

  Enabling S3 caching in a CodeBuild project stores the dependency cache (e.g., Maven's .m2, npm's node_modules, or Python's pip cache) in an Amazon S3 bucket between builds, so the build only downloads changed or missing packages instead of re-fetching the full dependency set each time. This directly reduces the time spent on network I/O, which is often the dominant cost for builds with many third-party libraries. By setting the 'cache' type to S3 and specifying a bucket, subsequent builds restore the cache at the start, making the compilation faster. This is the recommended approach because it targets the common bottleneck of dependency resolution.

• ✗

  Use a larger compute type for the build project.

  Why it's wrong here

  Choosing a larger compute type (e.g., from 2 GB to 7 GB memory or more vCPUs) only increases CPU and memory resources, but if the build's primary bottleneck is downloading dependencies from the internet, the faster instance still saturates the same network bandwidth and provides negligible speedup. A larger instance may marginally speed up compilation via more cores, but it will not reduce the dependency download time that caching would. Additionally, it increases cost per minute without guaranteeing a corresponding reduction in build duration, making it an ineffective fix for dependency-heavy build times.

Go deeper

Related to this question