A logistics company runs delivery-route EC2 instances reading SQS and writing DynamoDB, plus ECS Fargate tasks pulling ECR and writing CloudWatch Logs. Credentials were found hardcoded in user data and task definitions. Which role assignment eliminates static keys while granting least-privilege workload access?
Select an answer to reveal the explanation.
Short Explanation
You’re swapping spare keys under the mat for badges that auto-rotate. Profiles and task roles deliver credentials safely, like backstage passes scoped to each performer.
Full Explanation
The correct design works because EC2 instance profiles supply temporary credentials via instance metadata, eliminating hardcoded keys in user data with a policy limited to SQS polling and DynamoDB writes, while Fargate uses two distinct identities where the execution role performs only platform operations of authenticating to ECR and delivering logs and the task role provides only application permissions, preserving least privilege per workload. The task-role-only design fails on platform authentication concept because image pulls and log delivery require an execution role, so without it deployments must reintroduce static ECR credentials. The combined-execution-role design fails on privilege separation concept because merging infrastructure and application permissions gives the launch infrastructure unnecessary workload rights and prevents independent policy tightening and auditing. The shared-policy design fails on workload isolation concept because giving both compute types permission to all four services is functional but grants EC2 unneeded ECR and logging rights and grants Fargate unneeded queue and table rights. For exams, treat any mention of private ECR plus application AWS calls as a signal that both Fargate roles are mandatory even when one broad role would appear to work. In practice confirm no access keys exist, validate effective permissions with IAM policy simulator, and check CloudTrail for prior key misuse.