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.

• ✓

  Enable Amazon S3 caching in the CodeBuild project and specify an S3 bucket to store the cache.

  Why this is correct

  Enabling Amazon S3 caching in the CodeBuild project configuration lets you specify an S3 bucket (and optional prefix) that CodeBuild uses to store and retrieve build artifacts such as the Maven local repository. When S3 caching is turned on, CodeBuild automatically saves the directories declared in the buildspec's cache/paths section to that bucket and restores them at the start of subsequent builds, eliminating repeated dependency downloads and reducing build time. This is the recommended, fully managed caching approach for Java/Maven projects.

• ✗

  Use CodeBuild's 'build cache' feature without specifying a bucket; it will automatically cache to a default location.

  Why it's wrong here

  CodeBuild has no 'build cache' feature that automatically caches to a default location. The project's cache configuration must explicitly choose a cache type: NO_CACHE, LOCAL, or S3. If you specify S3, you are required to provide a bucket name; if you specify LOCAL, you must select specific local cache modes. There is no implicit bucket—if you omit the bucket while selecting S3, the API or console will reject the configuration, and caching will not function.

• ✗

  Set the cache type to 'Local' in the CodeBuild project configuration.

  Why it's wrong here

  Setting the cache type to 'Local' alone does not cache Maven dependencies. CodeBuild's local cache is limited to Docker layer caching, source code caching, and a custom cache directory under /codebuild/output/cache on the same build host. To cache Maven artifacts locally, you still need to list /root/.m2 in the buildspec's cache paths, and even then the cache is not durable—it survives only as long as the build host is recycled, so it is unsuitable for reliably sharing dependencies across build runs or instances.

• ✗

  Mount an Amazon EFS file system to the build container and configure Maven to use it as a local repository.

  Why it's wrong here

  Mounting an Amazon EFS file system to the build container is technically possible by configuring FileSystemLocations in the project, and you could point Maven's local repository to a directory on the EFS mount. However, this introduces additional operational overhead: you must manage security groups, mount targets, IAM permissions, and filesystem lifecycle, and network I/O to EFS adds latency compared to local S3 caching. It is neither the simplest nor the intended CodeBuild caching mechanism, making S3 caching the better and recommended option.

• ✓

  Configure the buildspec file to save the Maven local repository (.m2) to the cache path.

  Why this is correct

  This is a correct and necessary component of the caching solution: the buildspec must declare the Maven local repository path (typically /root/.m2) under the cache/paths section so CodeBuild knows exactly which files to save to the S3 cache bucket or restore before the build starts. Without this explicit declaration, CodeBuild cannot determine what to cache, even if the project has S3 caching enabled. Thus, the buildspec cache configuration works together with the project-level S3 cache setting to achieve fast, repeatable builds.

Go deeper

Related to this question