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.

• ✓

  Add 'ecr:InitiateLayerUpload' and 'ecr:CompleteLayerUpload' permissions to the CodeBuild service role.

  Why this is correct

  The AWS CodeBuild service role is the IAM identity that supplies temporary credentials to the build container. Pushing a Docker image to Amazon ECR requires calling the ECR API operations InitiateLayerUpload, UploadLayerPart, CompleteLayerUpload, and PutImage, so the role must explicitly allow those actions. Without these permissions, even a successfully authenticated docker login will fail when the push actually attempts to upload the image layers. Granting the policy to the service role is the secure, minimal-change fix.

• ✗

  Use the 'docker login' command with AWS CLI in the build phase.

  Why it's wrong here

  Running `docker login` with the AWS CLI in the build phase is a valid way to authenticate the Docker client with ECR, but it only obtains a registry authentication token. That token does not itself grant the underlying IAM permissions; every ECR API request made during the push is still authorized against the CodeBuild service role's policy. If the role is missing ecr:InitiateLayerUpload or ecr:CompleteLayerUpload, the login succeeds but the push fails with an access-denied error. Thus, the login command is not the missing piece—it is the role's permissions that need updating.

• ✗

  Install the AWS CLI in the CodeBuild build environment.

  Why it's wrong here

  The AWS CLI is already preinstalled in all current CodeBuild managed images, including those based on Amazon Linux 2 and the standard Docker images, so the installation step would be redundant. More importantly, the error is not caused by a missing CLI binary or helper tool; it is entirely an IAM authorization problem. Installing the CLI would not alter the permissions of the service role that CodeBuild uses, so the push would still fail. The fix must be a policy change on the IAM role, not a change to the build environment.

• ✗

  Create a new IAM user with ECR permissions and store the keys in CodeBuild environment variables.

  Why it's wrong here

  Creating a new IAM user and hard-coding its access keys in CodeBuild environment variables would technically give the build the ECR permissions it needs, but it violates AWS best practices by introducing long-term static credentials that can leak or expire. The CodeBuild service can instead assume an IAM role, which automatically supplies short-lived, rotating credentials to the build container; no key management is required. Additionally, storing secret keys in environment variables increases the risk of exposure via logs or build artifacts. The simplest and secure solution is to add the required ECR actions to the existing CodeBuild service role, which is the identity the build already uses.

Go deeper

Related to this question