AWS DVA-C02 Drill: ECS Task IAM Roles - The ECS_ENABLE_TASK_IAM_ROLE Configuration

Jeff’s Note

#

Jeff’s Note

#

“Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.”

“For DVA-C02 candidates, the confusion often lies in mixing up Instance Profile Roles with Task Roles, and not understanding the ECS_ENABLE_TASK_IAM_ROLE flag. In production, this is about knowing exactly how to configure the ECS Agent to enable granular, per-task IAM permissions instead of sharing broad instance-level permissions. Let’s drill down.”

The Certification Drill (Simulated Question)

#

Scenario

#

TechFlow Solutions is migrating their monolithic application to a microservices architecture using Amazon ECS with EC2 launch type. Two containerized services have been deployed: the InventoryReader service needs read-only access to a PostgreSQL database hosted on Amazon RDS Aurora, while the OrderCache service requires read-only access to an Amazon DynamoDB table storing session data. The Lead Developer must configure IAM permissions following the principle of least privilege, ensuring each service only has access to its specific data store.

The Requirement:

#

Configure the ECS environment and IAM roles to grant each microservice the minimum necessary privileges to access only its required AWS resources.

The Options

#

• A) Set ECS_ENABLE_TASK_IAM_ROLE to false on EC2 instance boot in ECS agent configuration file. Run the first microservice with an IAM role for ECS tasks with read-only access for the Aurora database. Run the second microservice with an IAM role for ECS tasks with read-only access to DynamoDB.
• B) Set ECS_ENABLE_TASK_IAM_ROLE to false on EC2 instance boot in the ECS agent configuration file. Grant the instance profile role read-only access to the Aurora database and DynamoDB.
• C) Set ECS_ENABLE_TASK_IAM_ROLE to true on EC2 instance boot in the ECS agent configuration file. Run the first microservice with an IAM role for ECS tasks with read-only access for the Aurora database. Run the second microservice with an IAM role for ECS tasks with read-only access to DynamoDB.
• D) Set ECS_ENABLE_TASK_IAM_ROLE to true on EC2 instance boot in the ECS agent configuration file. Grant the instance profile role read-only access to the Aurora database and DynamoDB.

Correct Answer

#

Option C.

Quick Insight: The Least Privilege Imperative

#

For Developers: The ECS_ENABLE_TASK_IAM_ROLE flag in the ECS agent configuration is the critical switch that enables IAM roles for tasks. When set to true, each ECS task can assume its own IAM role, providing granular permissions. When false or not set, tasks inherit the broader EC2 instance profile role, violating the principle of least privilege. This is the foundation of secure container orchestration in AWS.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option C

The Winning Logic

#

Option C correctly implements IAM Roles for ECS Tasks with proper configuration:

1. ECS Agent Configuration: Setting ECS_ENABLE_TASK_IAM_ROLE=true in /etc/ecs/ecs.config enables the ECS agent to provide task-level IAM credentials via the ECS Task Metadata Endpoint (v2 or v3).

2. Granular Permissions: Each microservice receives its own Task Role:

   • InventoryReader task → Task Role with rds:DescribeDBInstances and Aurora read permissions
   • OrderCache task → Task Role with DynamoDB read-only permissions (dynamodb:GetItem, dynamodb:Query)

3. SDK Credential Chain: The AWS SDK inside containers automatically retrieves temporary credentials from the Task Metadata endpoint at http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI.

4. Least Privilege: Each task can only access its specific resource—the Aurora service cannot touch DynamoDB, and vice versa.

Key Implementation Details for DVA-C02:

# /etc/ecs/ecs.config on EC2 instance
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_CLUSTER=production-cluster

Task Definition Snippet (JSON):

{
  "family": "inventory-reader",
  "taskRoleArn": "arn:aws:iam::123456789012:role/InventoryReaderTaskRole",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "inventory-app",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/inventory:latest",
      "environment": [
        {
          "name": "DB_ENDPOINT",
          "value": "aurora-cluster.cluster-xyz.us-east-1.rds.amazonaws.com"
        }
      ]
    }
  ]
}

Inside the Container (Credential Retrieval):

import boto3

# AWS SDK automatically uses task role credentials
rds_client = boto3.client('rds')
response = rds_client.describe_db_instances(
    DBInstanceIdentifier='inventory-db'
)

# Credentials are fetched from:
# http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

The Trap (Distractor Analysis)

#

• Why not Option A? Setting ECS_ENABLE_TASK_IAM_ROLE=false disables the task IAM role feature. Even if you specify taskRoleArn in your task definition, the ECS agent will not provide the credential endpoint, causing your application to fall back to the instance profile role (or fail with credential errors). This is a configuration logic trap—the option mentions assigning task roles, but the flag prevents them from working.

• Why not Option B? This violates least privilege by design. Using the instance profile role means all containers running on that EC2 instance share the same permissions. If the instance role has both Aurora and DynamoDB access, a compromised container in the InventoryReader task could access DynamoDB data it shouldn’t. Additionally, ECS_ENABLE_TASK_IAM_ROLE=false is explicitly wrong for task-level permissions.

• Why not Option D? While ECS_ENABLE_TASK_IAM_ROLE=true is correct, using the instance profile role instead of task-specific roles is the same security flaw as Option B. The instance profile role is meant for the ECS agent itself (pulling images from ECR, sending logs to CloudWatch) via the execution role, not for application-level data access. This option fails the “minimum privileges” requirement.

The Technical Blueprint

#

ECS Task IAM Role Architecture:

{
  "TaskDefinition": {
    "taskRoleArn": "arn:aws:iam::ACCOUNT:role/AppTaskRole",
    "executionRoleArn": "arn:aws:iam::ACCOUNT:role/ecsTaskExecutionRole",
    "containerDefinitions": [
      {
        "name": "app-container",
        "image": "...",
        "environment": [
          {
            "name": "AWS_CONTAINER_CREDENTIALS_RELATIVE_URI",
            "value": "/v2/credentials/GUID"
          }
        ]
      }
    ]
  }
}

IAM Policy for InventoryReader Task Role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters"
      ],
      "Resource": "arn:aws:rds:us-east-1:123456789012:cluster:inventory-aurora"
    },
    {
      "Effect": "Allow",
      "Action": [
        "rds-db:connect"
      ],
      "Resource": "arn:aws:rds-db:us-east-1:123456789012:dbuser:cluster-*/app_readonly_user"
    }
  ]
}

CLI Command to Update ECS Agent Config:

# SSH into EC2 instance and edit ECS config
sudo vi /etc/ecs/ecs.config

# Add or modify:
ECS_ENABLE_TASK_IAM_ROLE=true

# Restart ECS agent
sudo systemctl restart ecs

The Comparative Analysis

#

Key Differentiators:

• API Complexity: Task roles require proper task definition JSON and trust policies, but the AWS SDK handles credential retrieval automatically via the metadata endpoint.
• Performance: Negligible difference—credentials are cached by the SDK.
• Use Case: Task roles are mandatory for multi-tenant ECS clusters or when tasks need different permission scopes.

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the DVA-C02 exam, when you see ‘minimum privileges’ + ECS + multiple services with different resource needs, always pick the option with ECS_ENABLE_TASK_IAM_ROLE=true + separate Task Roles. Never use instance profile roles for application logic.”

Real World

#

“In production, we always enable task IAM roles, even for single-service clusters, because requirements change. I once debugged a 3-hour outage caused by a forgotten ECS_ENABLE_TASK_IAM_ROLE=false in a Terraform module—the app kept getting 403 errors from S3 because it was trying to use non-existent task credentials. Also, use execution roles (not task roles) for ECS agent operations like ECR pulls—that’s a common confusion point. And if you’re using Fargate, task IAM roles are enabled by default; this flag only matters for EC2 launch type.”

Pro Tip for Developers: Use AWS CloudFormation or CDK to manage task definitions with embedded role ARNs. Never hardcode IAM credentials in container images. Always test credential retrieval locally using aws sts get-caller-identity from within the container to verify the correct role is assumed.

Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the DVA-C02 exam. All company names and scenarios are fictional and created for educational purposes. Always refer to official AWS documentation and practice in your own AWS account.