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 environment variables in buildspec.yml are incorrectly set

  Why it's wrong here

  Incorrectly set environment variables in buildspec.yml would only change runtime configuration values such as GOPATH or build tags; they do not remove or add executables from the container's PATH. A 'go: command not found' error occurs during command resolution, before any environment variable values are consumed by the Go compiler. Only an explicit override of the PATH variable itself could hide an installed binary, but that is a distinct PATH misconfiguration, not a generic incorrect environment variable issue.

• ✗

  The build project does not have enough memory to compile Go code

  Why it's wrong here

  A CodeBuild project with insufficient memory would cause the Go compiler to be terminated by the kernel, typically surfacing as an out-of-memory (OOM) kill or a 'fatal error: out of memory' message from the Go runtime, not as a command-not-found error. The standard CodeBuild images allocate at least 3 GB of memory per build, which is more than adequate for typical Go compilation. Since the shell cannot execute 'go' only when the binary is absent from the image or PATH, memory constraints are not a plausible root cause for this symptom.

• ✓

  The build environment image does not have the Go runtime installed

  Why this is correct

  The CodeBuild managed build image is version-specific and does not include every language runtime; for example, the Amazon Linux 2 x86_64 standard image version 3.0 has Java, Python, Node.js, and Ruby, but no Go binary on its PATH. When the buildspec runs 'go build', the shell returns 'go: command not found' because the executable is simply not installed in the selected image. The correct remedy is to select an image that includes Go (such as a newer standard image with the Go runtime), add a runtime-versions entry for golang, or provide a custom Dockerfile that installs Go.

• ✗

  The CodeBuild service role does not have permission to access the S3 bucket for artifacts

  Why it's wrong here

  Artifact access permissions for the CodeBuild service role are checked later, when CodeBuild attempts to put the output artifact into the S3 bucket after the build phases finish. If the role lacks s3:PutObject, the build itself still executes successfully and then fails with an 'Access Denied' error from S3. A command-not-found error is generated by the shell in the install or build phase because the command is missing, not by an IAM authorization decision, so this misdiagnoses the failure stage.

Go deeper

Related to this question