City employees already authenticate to on-premises Active Directory. Leadership wants them to access AWS without creating a unique long-term IAM password for every person. Which approach matches that goal?
Select an answer to reveal the explanation.
Short Explanation
Federation is the bridge between the city's existing login system and AWS — people keep using Active Directory, and AWS trusts that identity instead of minting thousands of separate IAM passwords. One corporate login story, temporary AWS access on the other side.
Full Explanation
Federated identity that maps the existing identity provider into AWS access matches the goal of letting city employees who already authenticate to on-premises Active Directory reach AWS without creating a unique long-term IAM password for every person. Federation is the bridge — people keep using Active Directory, and AWS trusts that handshake for temporary access. Emailing every employee the root access key for shared use is catastrophic. Disabling IAM and relying only on security group passwords misunderstands both IAM and network filters. Storing each employee's password in a public S3 bucket for self-service publishes secrets. Distractors fail by spreading root keys, by confusing security groups with authentication, or by dumping passwords into public storage. Exam caveat: federation still requires role or permission-set mapping and MFA strategies aligned to the IdP. Operational check: integrate the corporate IdP with IAM Identity Center or federation roles, map AD groups to AWS permission sets, test joiner-mover-leaver, eliminate duplicate IAM user sprawl, and monitor failed federation attempts. In practice, pilot federation with one department, validate AssumeRole or Identity Center flows, then expand citywide while disabling redundant long-lived IAM passwords.