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.

• ✗

  Create a deploy stage that uses AWS CodeDeploy to deploy to Amazon ECS

  Why it's wrong here

  Using AWS CodeDeploy as the deploy provider for Amazon ECS is not the standard or native method in CodePipeline. CodeDeploy is primarily designed for EC2/on-premises deployments using the CodeDeploy agent and AppSpec files; while CodeDeploy has ECS-specific deployment support via Blue/Green, in CodePipeline the recommended and supported deploy action is the Amazon ECS deploy provider, which directly updates an ECS service with the new image. Choosing CodeDeploy would require extra configuration such as AppSpec hooks and ALB target group management, adding unnecessary complexity and not aligning with the intended simple continuous deployment flow.

• ✓

  Create a source stage that uses AWS CodeCommit as the source provider

  Why this is correct

  Creating a source stage with AWS CodeCommit as the source provider is required because the pipeline needs a trigger and a location for the application source code, including the Dockerfile and any build specifications. CodeCommit is the native Git repository service on AWS, and integrating it with CodePipeline allows automatic pipeline execution on every push to the configured branch. This provides version-controlled source securely within AWS, avoiding the need for external credentials or additional network access.

• ✓

  Create a deploy stage that uses Amazon ECS as the deploy provider with an imagedefinitions.json file

  Why this is correct

  The deploy stage must use the Amazon ECS deploy provider with an imagedefinitions.json file because that file maps the container image URI in Amazon ECR to the container name defined in the ECS task definition. When CodeBuild finishes pushing the image to ECR, it emits the imagedefinitions.json artifact, which the ECS deploy action reads to update the ECS service with the new image and trigger a rolling deployment. This provider handles the ECS service deployment directly and is the correct, minimal way to deploy to ECS in CodePipeline.

• ✗

  Create an invoke stage that uses AWS Lambda to update the ECS service

  Why it's wrong here

  Invoking an AWS Lambda function to update the ECS service is an unnecessary and brittle workaround because the Amazon ECS deploy provider in CodePipeline already performs the service update natively. Adding a Lambda invocation stage would require writing custom code, managing IAM permissions for the Lambda to call UpdateService, and wiring the pipeline to wait for completion. It also breaks the purpose of using pipeline actions that have built-in integration, making the pipeline harder to maintain and more error-prone.

• ✓

  Create a build stage that uses AWS CodeBuild to build a Docker image and push it to Amazon ECR

  Why this is correct

  Creating a build stage that uses AWS CodeBuild to build the Docker image and push it to Amazon ECR is a required step because the source code from CodeCommit must be compiled into a container image in a repository that ECS can pull from. CodeBuild can run a buildspec that executes Docker commands to build, tag, and push the image to ECR, then output the imagedefinitions.json file for the deploy stage. Without this build stage, there would be no image artifact to deploy, and the pipeline could not achieve continuous deployment.

Go deeper

Related to this question