SOA-C02 Monitoring, Logging, and Remediation 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 container image is corrupted.

  Why it's wrong here

  Container image corruption is an unlikely cause because ECR stores images with a content-addressable digest and verifies integrity during pull; a corrupted image would raise a manifest or checksum mismatch error, not a network failure. The error message described in the scenario points to a connectivity issue (such as a timeout), not a data corruption issue. Since the image is present in ECR and permissions are confirmed, corruption does not explain the pull failure.

• ✗

  The ECR repository policy is not allowing the task role.

  Why it's wrong here

  If the ECR repository policy did not allow the task role, the pull attempt would fail with an AccessDenied or Unauthorized error from the ECR API. The team explicitly verified task role permissions, so authentication and authorization are not the issue. Additionally, the error pattern typical of this scenario—like a connection timeout or 'no route to host'—indicates the task cannot reach ECR at the network level, not that it was denied access.

• ✗

  The ECS task definition has an incorrect memory allocation.

  Why it's wrong here

  An incorrect memory allocation in the ECS task definition would only affect the container's runtime resource limits; the image pull occurs before the container is instantiated and is performed by the Fargate infrastructure, independent of the task's configured memory. If memory were too low, the container might be killed or fail to start after being pulled, but the error would be an OOM or a resource-limitation error, not an image-pull failure. Therefore, memory allocation is unrelated to the described symptom.

• ✓

  The ECS tasks are in a private subnet without a NAT gateway or VPC endpoints for ECR and S3.

  Why this is correct

  Fargate tasks running in a private subnet do not have public IP addresses, so they cannot reach the internet without a NAT gateway. To pull images from ECR, the task also needs access to the Amazon S3 endpoints that store image layers, which requires either a NAT gateway or VPC endpoints for both ECR and S3. Without these routes, the image pull attempts time out or fail with a network connectivity error, exactly matching the scenario. This is the correct cause.

Go deeper

Related to this question