DOP-C02 Configuration Management and IaC Practice Question

A company uses AWS CodeBuild to compile and test code. The build process requires a specific version of a library that is not available in the default build environment. Which approach should be used to include this library in the build process?

⚠ Common exam trap

It's easy for candidates to choose Option B or C because they think 'download during build' is simpler, but they overlook the core DevOps principle of immutable build environments and the inefficiency of re-downloading or recompiling dependencies on every build run.

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

✓

Create a custom Docker image that includes the library and use it as the build environment in CodeBuild.

Creating a custom Docker image that includes the required library ensures the build environment is consistent, reproducible, and avoids repeated download/compile overhead. AWS CodeBuild supports custom Docker images via the `image` field in the buildspec file or the console, allowing you to specify a repository in Amazon ECR or Docker Hub. This approach aligns with infrastructure-as-code best practices by baking dependencies into the environment rather than managing them at build time.

Answer analysis

Option-by-option breakdown

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

✗
Modify the buildspec file to include the library as a build artifact.
Why it's wrong here
Declaring the library as a build artifact in buildspec only defines what CodeBuild uploads to S3 after the build phase completes. Build artifacts are outputs, not inputs, so they cannot inject the library into the build environment before compilation or testing begins. The build environment is provisioned before buildspec phases run, and artifact declarations do not alter the image or pre-populate dependencies.
✗
Store the compiled library in an Amazon S3 bucket and download it during the build process using the buildspec file.
Why it's wrong here
Downloading a precompiled library from S3 during the build adds an external runtime dependency and requires the build role to have s3:GetObject permissions for that bucket. It also introduces a network call that may fail if VPC settings, bucket policies, or credentials are misconfigured, and the library version in S3 must be manually kept in sync with the source code. While possible, this approach is more fragile and operationally complex than baking the dependency into the build image.
✗
Add an install command in the buildspec file to download and compile the library during each build.
Why it's wrong here
Adding an install command to compile the library on every build increases wall-clock time and adds build-time dependencies such as compilers, build tools, and system packages that may themselves require installation. This approach also risks nondeterministic builds if the library's upstream source or dependency versions change between builds. CodeBuild's managed images are generic for convenience, but they are not tailored to precompile application-specific libraries, so the build would repeatedly pay the cost of compilation.
✓
Create a custom Docker image that includes the library and use it as the build environment in CodeBuild.
Why this is correct
Creating a custom Docker image with the library preinstalled makes the library available at the very start of every build because CodeBuild runs build phases inside that image. Custom images let you pin the exact library version and all transitive runtime dependencies, ensuring reproducibility and eliminating repeated download/compile overhead. This is a best practice when the build consistently requires specialized binaries, libraries, or tools that are not present in CodeBuild's standard managed images.

Go deeper

DOP-C02 Configuration Management and IaC Practice Question

Why each option matters

Option-by-option breakdown

Related to this question