DVA-C02 Deployment 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.

• ✗

  Increase the compute type of the build environment to have more CPU and memory.

  Why it's wrong here

  Increasing the compute type (for example, from 2 GB memory and 1 vCPU to a larger instance) only allocates more CPU and RAM to the build container. It does not accelerate the network-bound operation of downloading Maven or Gradle dependencies from remote repositories, which is typically the dominant cost in a cold Java build. Dependency downloads remain constrained by network latency and throughput, so the time spent fetching artifacts is essentially unchanged; you would only see modest gains in compilation itself, not in dependency resolution.

• ✗

  Change the build runtime to a language that compiles faster.

  Why it's wrong here

  Switching the Java build runtime to a different language is not a feasible optimization because the project's source code and build tooling are written for the JVM. CodeBuild provides fixed runtimes for Java, Node.js, Python, Go, and others, but you cannot compile a Java application in another runtime without rewriting the entire codebase. Even if a different runtime had a faster compiler, it would not address the root cause of repeated dependency re-downloads, and it would break the existing build definition and test suite.

• ✗

  Configure the build project to run builds in parallel.

  Why it's wrong here

  Running builds in parallel creates multiple separate CodeBuild projects or concurrent invocations for different branches or commits, but it has no effect on the duration of a single build. The throughput improvement applies to the number of builds processed per unit time across a fleet, not to the wall-clock time of one pipeline. A single Maven or Gradle build remains sequential in its dependency resolution and compilation phases; parallelizing across builds does not cache or share dependencies for the specific build that is already slow.

• ✓

  Enable local caching in the CodeBuild project to reuse dependency files between builds.

  Why this is correct

  Local caching in CodeBuild stores specific directories, such as /root/.m2 for Maven or /root/.gradle for Gradle, on the build instance's local disk, keyed by the project and optionally by a custom cache key. On subsequent builds, if the same instance is reused, downloaded dependency JARs are restored from the local cache instead of being fetched from the internet, eliminating the network latency that dominates a cold build. To make it effective, you must configure a cache key that changes only when dependencies actually change, so identical builds skip the download entirely.

• ✓

  Use Amazon S3 to cache dependencies and restore them at the start of each build.

  Why this is correct

  Alternatively, you can configure CodeBuild to use an Amazon S3 cache bucket, where the cache is persisted as an archive or folder in S3 across all build environments. At the start of each build, CodeBuild downloads the cached dependency directory from S3, and at the end uploads it again after changes, so dependency resolution becomes a fast S3 GET rather than many external HTTP requests to Maven Central. This is more durable than local caching because it survives instance reclamation, but it still incurs an S3 transfer that local caching avoids; the correct choice depends on whether you need cross-project sharing or can tolerate occasional cache misses.

Go deeper

Related to this question