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 tests into smaller batches using CodeBuild test splitting.

  Why it's wrong here

  CodeBuild test splitting only partitions test execution into separate groups for reporting and parallel phases; it does not alter the size or memory ceiling of the build container. Each batch still runs on the same compute type (e.g., BUILD_GENERAL1_SMALL), so the Maven process in a single batch can still exhaust the container's 3 GB memory. It addresses test organization, not the root cause of insufficient memory for the JVM and build tool.

• ✓

  Change the build environment to 'BUILD_GENERAL1_MEDIUM' which has more memory.

  Why this is correct

  Upgrading to BUILD_GENERAL1_MEDIUM is the correct fix because CodeBuild compute tiers directly define the memory and vCPU available to the build environment: GENERAL1_SMALL provides 3 GB, while GENERAL1_MEDIUM provides 7 GB. This increases the total addressable memory for the Maven JVM, native code, and metaspace, directly resolving the OutOfMemoryError without altering the application or its dependencies. It is also cost-effective because you only pay for builds that use the larger compute type, and the price increase is modest compared to the engineering effort of optimizing memory usage.

• ✗

  Configure the buildspec to set MAVEN_OPTS='-Xmx512m' to reduce JVM heap usage.

  Why it's wrong here

  Setting MAVEN_OPTS='-Xmx512m' caps only the Java heap, but OutOfMemoryErrors in CodeBuild often stem from the container's total memory limit, which includes metaspace, thread stacks, and Maven's process overhead. If the application or test suite genuinely needs more than 512 MB of heap, this setting will trigger 'Java heap space' OutOfMemoryError during test execution, making builds fail differently. It is a band-aid that may reduce peak memory usage but does not increase the actual memory available to the build container, and it can cause excessive garbage collection and slower test execution.

• ✗

  Use multiple CodeBuild jobs to run tests in parallel.

  Why it's wrong here

  Running multiple CodeBuild jobs in parallel does not enlarge the memory allocation of any single job; each job still runs in its own isolated container with the same compute type (e.g., 3 GB). The specific Maven process that encounters the OutOfMemoryError still has the same memory ceiling, so the error will recur regardless of how many concurrent jobs you run. It might mask the problem by allowing some tests to pass in separate jobs, but it does not address the underlying resource insufficiency of the build environment.

Go deeper

Related to this question