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.

• ✓

  Configure CodeBuild to cache dependencies in an Amazon S3 bucket.

  Why this is correct

  Configure CodeBuild with cache.type set to S3 and specify an S3 bucket as cache.location, then declare the Java dependency directory (e.g., /root/.m2 for Maven) in the buildspec cache.paths. This creates a persistent, shared cache that is uploaded at the end of each build and downloaded at the start of the next, so dependencies are fetched from S3 instead of being downloaded one-by-one from public repositories on every run. By keying the cache appropriately (e.g., including a hash of the buildspec or source), you retain a valid cache while invalidating it when dependencies or build parameters change.

• ✗

  Move the build process to a local developer machine to avoid CodeBuild overhead.

  Why it's wrong here

  Moving builds to a developer machine destroys the reproducibility of a managed CI pipeline because local environments differ in JDK versions, environment variables, installed tools, and cached artifacts, leading to 'works on my machine' failures. It also eliminates centralized logging, IAM-based permissions, and audit trails, and it cannot scale across a team since one developer's local cache is not shared. This approach leaves the team without a consistent, compliant, or automated build process, and it does not solve the original dependency-download bottleneck for the pipeline.

• ✗

  Reduce the number of unit tests executed in the build phase.

  Why it's wrong here

  Reducing the number of unit tests executed in the build phase targets the wrong bottleneck: the delay is caused by the build environment being ephemeral and downloading Maven dependencies from the internet, not by test execution time. Unit tests are typically fast, run in-memory, and are a critical quality signal; removing them gives negligible time savings while significantly lowering code coverage and weakening the CI gate. This approach degrades developer confidence and may violate organizational quality policies, making it an unacceptable way to optimize build duration.

• ✗

  Increase the compute type of the build environment to a larger instance.

  Why it's wrong here

  Increasing the compute type of the build environment adds vCPUs and memory, which can speed up compilation and test execution, but the new larger instance still starts with an empty local cache and must make the same network requests to download all third-party dependencies. The dependency-fetch operation is bound by network latency and throughput to public repositories, not by CPU capacity, so larger compute does little or nothing to reduce the dominant cold-cache overhead. This solution also raises per-build cost, potentially eliminating the efficiency benefit that S3 caching would provide.

Go deeper

Related to this question