DVA-C02 Security 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.

• ✗

  Store AWS credentials in the container image

  Why it's wrong here

  Storing AWS credentials directly within a container image is a severe security vulnerability that should always be avoided. These hardcoded credentials become a permanent part of the image, making them susceptible to compromise if the image is ever accessed by unauthorized parties or pushed to a public repository. This practice violates the principle of least privilege and secure credential management, as it lacks dynamic rotation, auditing, and fine-grained access control, posing a significant security risk to your AWS environment.

• ✓

  Define a task role for the ECS task with DynamoDB permissions

  Why this is correct

  Defining an IAM task role for an Amazon ECS task is the recommended and most secure method for granting AWS permissions to applications running within containers. When a task starts, it assumes this specified IAM role, which then provides temporary, frequently rotated credentials to the container's processes. This mechanism ensures that the application can securely interact with AWS services like DynamoDB without needing to store any long-lived credentials directly, adhering to the principle of least privilege and significantly enhancing security posture.

• ✗

  Assign an IAM role to the ECS service and use it from the container

  Why it's wrong here

  While ECS services do utilize IAM roles, these are specifically "ECS service-linked roles" or "ECS service roles" that grant permissions for the ECS service itself to manage resources on your behalf, such as registering/deregistering tasks with a load balancer or scaling tasks. These service-level roles are not directly assumed by the application containers running within the tasks. Application containers require an IAM task role to obtain permissions for interacting with other AWS services like DynamoDB, making this option incorrect for granting application-level access.

• ✗

  Use an EC2 instance profile and mount it to the container

  Why it's wrong here

  This approach is incorrect because it conflates ECS launch types and their respective credential mechanisms. An EC2 instance profile grants permissions to the underlying EC2 instance on which ECS tasks might run when using the EC2 launch type. However, if the question implies a serverless deployment (common for web applications on ECS), it likely refers to the Fargate launch type, which does not provision or expose EC2 instances to the user. Therefore, an EC2 instance profile is irrelevant and cannot be "mounted" to a container in a Fargate task.

Go deeper

Related to this question