A logistics firm runs shipment APIs on EC2, order workers on ECS Fargate, and image builds with CodeBuild, and developers confused task roles with execution roles causing S3 denials and over-permissive keys. Which role mapping should the architect enforce to authorize each compute workload with least privilege?
Select an answer to reveal the explanation.
Short Explanation
You'll stop those S3 denials when you give EC2 its instance profile, your ECS tasks their own task role, and let the execution role handle only infrastructure pulls. It's like handing each crew member just the badge they need, and that separation keeps your permissions tight and safe.
Full Explanation
EC2 uses instance profiles to vend temporary credentials to applications, ECS tasks use task roles for application AWS API calls, and the ECS execution role is used by the ECS agent infrastructure for image pulls and log delivery, so mapping each identity to its purpose enforces least privilege and explains S3 denials as role misuse. Swapping task and execution semantics fails by concept because it grants application permissions to infrastructure and vice versa, causing denials and privilege excess. IAM user access keys on EC2 fail by concept because long-lived keys violate temporary credential best practice and cannot scope ECS behavior. Using CodeBuild service roles for ECS tasks fails by concept because service roles authorize CodeBuild project actions, not task application calls, and misplaces build permissions. Exam caveat is to memorize that task role equals app and execution role equals ECS agent plus CodeBuild has its own distinct service role, and practical check is to inspect task definitions for both role ARNs and test with IAM policy simulator.