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.

• ✓

  The cache for the build project was cleared, forcing a full dependency download.

  Why this is correct

  Clearing a CodeBuild project's cache removes previously downloaded dependency artifacts, such as those stored in the local Maven repository (~/.m2) or in an S3 cache bucket. On the next build, Maven must reach out to remote repositories to re-download every JAR it needs, adding significant network and I/O time on top of the compile itself. Because the buildspec commands are unchanged, the only impact is that dependency resolution is no longer incremental, directly explaining the increased build duration.

• ✗

  The build environment was changed from a Linux to a Windows environment.

  Why it's wrong here

  Altering the build environment from Linux to Windows is not an incidental cause; it requires an explicit UpdateProject action choosing a different environment image, and would likely break buildspec commands that are shell-specific. The Java compilation may still work, but the project configuration is the issue, not a hidden cache problem. Since the question states the buildspec is unchanged and no other administrative change is mentioned, this option is unsupported and would not simply elongate build time without visible project modifications.

• ✗

  The build project's compute type was downgraded to a smaller instance.

  Why it's wrong here

  A compute type downgrade, such as moving from a large to a small general purpose instance, is a visible configuration change that a team would notice in the CodeBuild console or API. CodeBuild does not silently lower compute capacity—it has to be updated intentionally—and a smaller instance would proportionally reduce CPU/memory resources, which mainly affects compilation, not dependency download. This is a known, deliberate change, whereas the scenario describes an unexplained increase with only an unchanged buildspec clue, making it an incorrect explanation.

• ✗

  The buildspec.yml file was updated to include more build commands.

  Why it's wrong here

  If the buildspec.yml had been expanded with additional build commands, the file itself would differ from the previously successful version. The problem explicitly verifies that the buildspec is unchanged, ruling out any new compilation steps, tests, or packaging commands that might extend the build. Adding commands would also be an obvious cause that the team would have identified, rather than a subtle state issue like stale or cleared cached artifacts.

Go deeper

Related to this question