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.

• ✗

  Enable Amazon S3 cache for the CodeBuild project to reuse dependencies from previous builds.

  Why it's wrong here

  Enabling Amazon S3 cache preserves dependency archives and build artifacts from previous runs, but CodeBuild still has to rehydrate that cache from S3 into a fresh build container, which involves downloading and extracting the cache on every build. This can reduce repeat downloads from the internet, yet the S3 transfer and extraction time remains a per-build overhead that a pre-baked image avoids entirely. Additionally, S3 cache misses occur on the first build or whenever the dependency set changes, so the long monolith build time may persist.

• ✗

  Store the dependencies in an Amazon S3 bucket and download them at the start of each build.

  Why it's wrong here

  Downloading dependencies from a pre-populated S3 bucket at the start of each build still forces the build environment to pull potentially hundreds of MB or GB of artifacts over the network, making each build's critical path include that transfer time. While S3 latency and bandwidth are better than public internet, the download is not eliminated and can still be the dominant cost when the dependency tree is large. Managing versioned S3 artifacts also adds operational complexity without addressing the root cause of the slow build.

• ✓

  Create a custom Docker image that includes all dependencies and use it as the build environment.

  Why this is correct

  Creating a custom Docker image that pre-installs all dependencies means those dependencies already exist inside the image's local file system when the CodeBuild container starts, so there is no download phase at all. The build can proceed directly to compilation, packaging, and testing, making the build time deterministic and dramatically shorter for a monolith. This image should be stored in Amazon ECR and updated whenever the dependency set changes, ensuring the build environment is both fast and consistent.

• ✗

  Use a larger compute type for the CodeBuild project to speed up the build.

  Why it's wrong here

  Choosing a larger CodeBuild compute type increases the CPU and memory resources available to the build, but if the build's bottleneck is network-bound dependency downloads, those extra resources sit idle while the job waits for data to arrive. Dependency download speed is typically constrained by network bandwidth and the source repository's throughput, not by the size of the build container. Thus, upgrading compute type can raise costs without meaningfully reducing the over-an-hour build time.

Go deeper

Related to this question