DOP-C02 Incident and Event Response 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.

• ✗

  Attach an EBS volume to the Fargate task for caching.

  Why it's wrong here

  Attaching an EBS volume is impossible for Fargate tasks because Fargate is a serverless compute model that only exposes the ephemeral task storage (mounted at /var/lib/docker for the image layer) and does not allow attaching block devices such as EBS volumes. Even if caching were attempted via an EFS file system or enhanced ephemeral storage, this would not resolve an image pull failure caused by a missing authorization or policy; the pull happens before any cache could be leveraged. Fargate simply does not support EBS, so this option is technically invalid.

• ✗

  Check that the ECS service role has the required permissions.

  Why it's wrong here

  The ECS service role is an IAM role assumed by the ECS service itself to make API calls on behalf of the task, such as registering/deregistering targets with an Elastic Load Balancer or publishing metrics to CloudWatch. It is not used for downloading container images from Amazon ECR; that action is performed by the task execution role. Checking the service role will not help diagnose an image pull failure because the service role has no bearing on ECR authentication or authorization.

• ✓

  Ensure that the ECR repository policy allows the task execution role to pull images.

  Why this is correct

  Amazon ECR uses both identity-based policies (attached to the principal, typically the task execution role) and resource-based policies (attached to the repository) to control access. If the repository policy does not explicitly grant the task execution role permission to perform actions like ecr:BatchGetImage and ecr:GetDownloadUrlForLayer, the pull will be denied even if the role's IAM policy allows those actions. The default repository policy is restrictive, and an overly narrow or misconfigured repository policy will cause a 'CannotPullContainerError' during task startup. Therefore, verifying that the ECR repository policy includes an Allow statement for the task execution role is a critical step.

• ✗

  Increase the task memory to accommodate the image pull.

  Why it's wrong here

  Increasing the task memory allocation does not affect the image pull process because image pulling is performed by the Fargate infrastructure before container resource limits are applied. The failure in this scenario is an authorization or policy issue, not a resource exhaustion issue; additional memory would neither grant ECR permissions nor change the repository policy. Moreover, memory limits apply to the running container's resource usage, not to the bandwidth or credentials used to download image layers. Thus, this option is irrelevant to the root cause.

• ✓

  Verify that the task execution IAM role has the necessary permissions to pull from Amazon ECR.

  Why this is correct

  The task execution IAM role is the correct principal that ECS uses to authenticate with Amazon ECR and download the container image. Without a proper trust policy and the required permissions, specifically ecr:GetAuthorizationToken, ecr:BatchGetImage, and ecr:GetDownloadUrlForLayer, the pull will fail. ECS first calls ECR to get an authorization token and then uses that token to access the repository, so the execution role must be allowed by both the IAM identity-based policy and the ECR repository policy. This is the primary IAM role to verify for any image pull issue in ECS tasks.

Go deeper

Related to this question