Question

Difficulty: Very hardAmazon ECS and Docker Deployment

A developer is deploying a containerized application to an Amazon ECS cluster using the Amazon EC2 launch type. The application, which runs in a container with the `bridge` network mode, is designed to write records to an Amazon DynamoDB table. The developer specifies an IAM role named `DynamoDBWorkerRole` in the `taskRoleArn` parameter of the task definition. This IAM role has a policy that allows `dynamodb:PutItem` on the target table. However, at runtime, the application fails to write to DynamoDB and logs the following error:

`AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/ECSInstanceRole/i-0abcdef123456789 is not authorized to perform: dynamodb:PutItem on resource`

(Note: `123456789012123456789012` is the AWS account ID, and `ECSInstanceRole` is the IAM role associated with the EC2 container instances.)

Which of the following actions will resolve this issue?

  1. A
    Attach the DynamoDB permission policy to the ECS Task Execution Role (taskExecutionRoleArn) instead of the Task Role (taskRoleArn).
  2. B
    Modify the application code inside the container to query the EC2 Instance Metadata Service (IMDS) at 169.254.169.254169.254.169.254 to retrieve temporary credentials for the DynamoDBWorkerRole.
  3. Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.Answer
  4. D
    Store the AWS access key and secret access key for an IAM user with DynamoDB permissions in AWS Secrets Manager, and reference them in the secrets section of the task definition.

Answer

Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.
The application failed to write to DynamoDB because the AWS SDK inside the container could not retrieve task credentials, causing it to fall back to the EC2 instance profile role (`ECSInstanceRole`). This fallback happens because the ECS agent is unable to assume the `DynamoDBWorkerRole` due to a misconfigured trust policy. To resolve this, the role's trust relationship must trust `ecs-tasks.amazonaws.com` instead of `ec2.amazonaws.com`.

Step-by-Step Solution

1
Analyze the error message to identify which IAM identity is performing the unauthorized request.
The error shows that `ECSInstanceRole` (the role associated with the EC2 container instance profile) is attempting the `dynamodb:PutItem` action, not the specified `DynamoDBWorkerRole`.
This indicates that the AWS SDK inside the container has fallen back to using the host instance's credentials because it could not retrieve container task credentials.
2
Determine why the task-specific credentials for `DynamoDBWorkerRole` were not provided to the container.
The ECS agent retrieves credentials by assuming the role specified in `taskRoleArn`. If the trust policy of that role does not trust the `ecs-tasks.amazonaws.com` service principal, the ECS agent will fail to assume the role.
ECS tasks require the `ecs-tasks.amazonaws.com` service principal to assume the IAM role defined in the task definition.
3
Evaluate the correct remediation to enable the ECS agent to assume the task role.
Modify the trust policy of `DynamoDBWorkerRole` to allow the `ecs-tasks.amazonaws.com` service principal to perform the `sts:AssumeRole` action.
This allows the ECS agent to assume the role, generate temporary credentials, and inject them into the container's environment.
4
Confirm the destination of the policy for application-level actions like DynamoDB operations.
The application permissions must remain attached to the Task Role (`taskRoleArn`), not the Task Execution Role (`taskExecutionRoleArn`).
The Task Execution Role is only used by the ECS container agent for infrastructure tasks such as pulling images and exporting logs.

Key Concept

ECS Task Role trust relationships and credential provider chain fallback behavior
Estimated Time:3m 0s
Rate this question