A county runs a public citizen API and a payroll microservice as separate ECS services. Security wants a breach of the public API task unable to write to payroll DynamoDB tables. How should task IAM be designed?
Select an answer to reveal the explanation.
Short Explanation
One giant role is a master key for the whole courthouse—lose the public door and payroll opens too. Give each ECS service its own task role with only the tables it needs. Blast radius stays local.
Full Explanation
A county that runs a public citizen API and a payroll microservice as separate ECS services should assign a unique task role per service. With separate roles, a compromise of the public API task cannot write to payroll DynamoDB tables because that role simply lacks permission. Least-privilege task roles implement blast-radius separation that network segmentation alone cannot guarantee for AWS API calls.
Attaching one shared AdministratorAccess role to every ECS task maximizes lateral movement after any single task compromise. Storing payroll table credentials as plaintext environment variables on the public API task places secrets on the wrong service. Disabling IAM for ECS and hard-coding long-lived access keys into each container image combines static secrets with weak workload identity.
Exam caveat: ECS task roles (application AWS API permissions) differ from task execution roles (pull images, publish logs)—do not conflate them when designing or answering exam items. Operational check: obtain credentials equivalent to the public API task role and attempt a payroll table write expecting AccessDenied; confirm the payroll service role succeeds; review policies for accidental wildcards that reunite the blast radii.