DOP-C02 SDLC Automation Practice Question
A company uses AWS CodeBuild to run unit tests and package a Java application. The build process takes 15 minutes. The team wants to reduce build time by caching dependencies. Which approach should the engineer recommend?
⚠ Common exam trap
It's easy for candidates to confuse CodeBuild's lack of persistent local storage with the ability to mount external file systems like EFS, or they may think that cloning a repository is an efficient caching mechanism, when in fact CodeBuild's native S3 cache is the simplest and most effective solution for dependency caching.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure CodeBuild to use Amazon S3 for cache storage and specify the cache directory in buildspec.yml
CodeBuild natively supports Amazon S3 for cache storage, allowing you to persist dependency directories across builds. By specifying the cache type as S3 and the path to the dependency cache (e.g., /root/.m2 for Maven) in the buildspec.yml, subsequent builds can reuse previously downloaded dependencies, significantly reducing build time without additional infrastructure.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store the compiled dependencies in a separate CodeCommit repository and clone it during the build
Why it's wrong here
Storing compiled dependencies in a secondary CodeCommit repository does not implement the CodeBuild cache API; it simply forces each build to clone an extra repository, adding network and git overhead while offering no automatic hit rate or key-based invalidation. The build environment is ephemeral, so this approach doesn't persist a local cache between runs—every build starts from an empty container and must re-fetch the dependency archive. It also burdens the source control system with binary artifacts, which is explicitly against CodeCommit best practices.
- ✗
Mount an Amazon EFS file system to the build container and persist the cache across builds
Why it's wrong here
Although you can mount an EFS filesystem during the pre_build phase and write Maven or dependency files to it, CodeBuild has no native parameter for using EFS as the cache backend; by contrast, the built-in cache feature expects an S3 bucket or a local cache mode. A network file system introduces untracked latency for every dependency read and write and leaves you responsible for lifecycle, concurrency, and cleanup. Amazon S3 is the recommended and fully integrated cache store, so EFS is operationally inferior for this use case.
- ✗
Use an Application Load Balancer in front of a private artifact repository
Why it's wrong here
An Application Load Balancer operates at L7 and only distributes inbound traffic to registered targets; it does not store or accelerate repeated artifact downloads. Every CodeBuild run would still traverse the network to retrieve dependencies, so the ALB provides no cache hit benefit and adds deployment and cost overhead. This option confuses availability scaling with deterministic build caching, which is why it fails to solve the stated problem.
- ✓
Configure CodeBuild to use Amazon S3 for cache storage and specify the cache directory in buildspec.yml
Why this is correct
Configuring CodeBuild to use Amazon S3 for cache storage and specifying the cache directory in buildspec.yml is the native, recommended caching solution. Set the project's cache type to S3 with a designated bucket, then declare the dependency path—for Maven that is typically /root/.m2/repository—under cache.path in the buildspec. At the start of a build, CodeBuild downloads the cached files, and at the end it re-uploads them, so repeated runs skip re-resolving and re-downloading dependencies from Maven Central, substantially reducing build time and network egress.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 251-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.