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.

• ✓

  Change the compute-type to 'BUILD_GENERAL1_MEDIUM' or 'BUILD_GENERAL1_LARGE' in the buildspec.

  Why this is correct

  Upgrading the compute type in the buildspec—from the default BUILD_GENERAL1_SMALL (3 GB memory) to BUILD_GENERAL1_MEDIUM (7 GB) or BUILD_GENERAL1_LARGE (15 GB)—is the correct fix because CodeBuild's compute-type property directly controls the memory and vCPU allocated to the build container. Java compilation through Maven or Gradle is memory-intensive, and a small instance can easily cause the JVM or compiler daemon to run out of heap space. Selecting a larger general-purpose tier gives the build process a proportionally larger heap and OS memory, resolving the OOM without changing application code.

• ✗

  Enable Amazon S3 caching for the build artifacts to reduce memory usage.

  Why it's wrong here

  Enabling Amazon S3 caching stores build dependencies, caches, and artifacts in S3 so subsequent builds can reuse them, but this only reduces network time, dependency resolution, and disk I/O during the build. It does not alter the JVM heap, the compiler's working set, or the CodeBuild container's memory limit—those are fixed by the compute type. Caching artifacts is about persisting outputs, not about providing additional RAM to a process that is already hitting the memory ceiling.

• ✗

  Split the build into multiple parallel CodeBuild actions in the pipeline, each compiling a subset of the code.

  Why it's wrong here

  Splitting the build into multiple parallel CodeBuild actions in the pipeline does not increase the memory available to any single Java compile process. Each parallel action would run in its own container with its own memory limit, and unless the source code and build logic are explicitly refactored into independent modules, Maven/Gradle still need to compile the entire project's classes in one JVM. Parallelism helps wall-clock time for independent tasks, but it does nothing for a JVM that exhausts its heap while compiling a large codebase; in fact, you could still hit the same OOM in each parallel container.

• ✗

  Set the environment variable 'MEMORY_OVERPROVISION=2' in the buildspec.

  Why it's wrong here

  CodeBuild does not support a 'MEMORY_OVERPROVISION' environment variable or any equivalent setting. Environment variables in CodeBuild are simply passed to the build commands; they cannot change the underlying container's memory allocation, which is strictly determined by the selected compute-type (e.g., BUILD_GENERAL1_SMALL, MEDIUM, LARGE). Any attempt to set this variable is ignored and provides no additional memory, so this option is invalid as a solution.

Go deeper

Related to this question