A township finance team and parks team share one AWS account and keep colliding on permissions when both use shared admin users. How should the architect structure authorization?
Select an answer to reveal the explanation.
Short Explanation
Shared admin logins are like one master badge that every desk passes around—when something breaks, you cannot tell who did what. Put finance and parks into groups or roles with only the rights each job needs. Least privilege beats one overloaded admin account.
Full Explanation
When township finance and parks teams share one AWS account and collide through shared admin users, authorization should be rebuilt around IAM groups or roles that map to job functions with least-privilege policies. Each human or workload assumes an identity that can perform only the APIs needed for that function—finance may manage billing and specific DynamoDB tables; parks may manage their S3 prefixes and EC2 tags—while CloudTrail attributes actions to distinct principals. Shared admin logins erase accountability and inflate blast radius: anyone with the password can affect both departments' resources.
Giving every employee the account root password maximizes damage and eliminates forensics; root is for break-glass only. Attaching AdministratorAccess to a single shared IAM user that both teams reuse recreates the same anti-pattern with a slightly different principal name—still one credential, still full power, still no separation. Disabling IAM and managing access only through local OS accounts on EC2 ignores the AWS control plane entirely: API calls to S3, IAM, and RDS would still need AWS credentials, and host OS accounts do not replace identity-based access to AWS services.
Exam caveat: in a single shared account, IAM can separate duties but cannot match the hard boundary of separate accounts; if tax data must never be readable by parks even under misconfiguration, prefer account isolation plus SCPs. Within one account, prefer roles (especially with Identity Center) over long-lived IAM user passwords, and use permissions boundaries for delegated admins who create users. Operational check: create FinanceAuditors and ParksOperators groups/roles with distinct policies; sign in as each; confirm finance cannot PutObject to parks buckets and parks cannot read finance databases; review CloudTrail to see separate ARNs for each team's actions.