DOP-C02 Security and Compliance 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.

• ✗

  Embed the IAM user credentials in the container image

  Why it's wrong here

  Hardcoding an IAM user's access key ID and secret access key directly into a container image creates long-lived credentials that are exposed to anyone who can pull the image, inspect its layers, or gain access to the running container. These credentials are not automatically rotated and violate the principle of least privilege; they also persist in the image registry as plaintext, making this approach fundamentally insecure. The correct pattern on ECS is to grant the task an IAM role and let the SDK obtain temporary credentials automatically.

• ✗

  Store AWS access keys in AWS Secrets Manager and retrieve them at runtime

  Why it's wrong here

  While storing access keys in AWS Secrets Manager removes them from the image, the application still has to load a long-term IAM user key pair at runtime, and it must already have some valid credentials just to call Secrets Manager—creating a bootstrap problem. Additionally, these keys remain valid indefinitely, so a compromise or leak cannot rely on short-lived session rotation. Secrets Manager is meant for confidential data such as database passwords or third-party API tokens, not for distributing IAM credentials; for AWS API access, the ECS task should assume an IAM role instead.

• ✗

  Use an IAM role for the EC2 instance if using EC2 launch type

  Why it's wrong here

  Using the EC2 instance's IAM role, rather than a task-specific role, only works with the EC2 launch type and cannot be applied to AWS Fargate, where no underlying EC2 instance exists. Even on EC2, the instance role is shared by every task running on that instance, and it is intended for the ECS container agent and ECS operations, not for granting scoped permissions to a particular containerized application. Giving each task its own IAM role in the task definition provides fine-grained control, isolates permissions per workflow, and works consistently across both launch types.

• ✓

  Create an IAM role for the ECS task and reference it in the task definition

  Why this is correct

  Create an IAM role that defines the exact AWS API permissions the container needs, then specify that role in the task definition using the taskRoleArn parameter. The ECS agent—on Fargate or EC2—assumes this role on behalf of the task and exposes temporary credentials to the container via the ECS credential endpoint, so the SDK automatically rotates them. This is the recommended pattern because it scopes credentials to a single task, follows least privilege, and eliminates the need to manage any static access keys.

Go deeper

Related to this question