SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses AWS CodeBuild to run unit tests. The build process is taking longer than expected. The buildspec.yml file includes a pre-build phase that downloads dependencies from a public repository. What is the most effective way to reduce build time?

⚠ Common exam trap

SAP-C02 often tests the misconception that scaling compute (more vCPUs) or parallelism always reduces build time, when the actual bottleneck is often network-bound dependency retrieval that caching solves.

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 the build project to use an S3 cache for dependencies.

The pre-build phase downloads dependencies from a public repository, which is the slowest part of the build. Configuring an S3 cache in CodeBuild lets the project persist and reuse files (like downloaded dependencies) between builds, so subsequent builds skip the network download entirely. This directly targets the identified bottleneck and is the most effective, cost-efficient optimization for repeated dependency fetching.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Configure the build project to use an S3 cache for dependencies.
Why this is correct
An S3 cache bucket stores the downloaded dependencies between runs, so the pre-build phase retrieves them from S3 rather than re-downloading from the public repository. This directly addresses the stem's constraint: repeated dependency downloads inflating build duration. CodeBuild restores the cache before the pre-build phase, cutting that wait.
✗
Run the build in parallel across multiple build projects.
Why it's wrong here
Parallel build projects split separate workloads; they do not shorten a single build whose pre-build phase serially downloads dependencies. It is tempting because parallelism genuinely reduces aggregate pipeline duration, and would be correct if the pipeline ran many independent build jobs that could execute concurrently.
✗
Increase the compute type of the build environment to use more vCPUs.
Why it's wrong here
More vCPUs do not accelerate a network-bound dependency download in the pre-build phase, which is limited by repository throughput rather than compute. It is tempting because larger compute types speed up CPU-intensive compilation, and would be correct if the bottleneck were compilation or test execution rather than fetching packages.
✗
Reduce the build timeout setting to force faster execution.
Why it's wrong here
The build timeout is a maximum duration limit; lowering it aborts the build rather than making any phase execute faster. It is tempting because it appears to cap wasted time, and would be correct if the goal were to fail stalled builds early rather than to reduce actual build duration.

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

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question