A regional transit authority wants one login portal so staff across subsidiaries can reach multiple AWS accounts with workforce single sign-on. Which service should the architect designate as the central workforce SSO hub?

Designating AWS IAM Identity Center as the central workforce SSO hub gives the regional transit authority one login portal and one place to assign permission sets across subsidiary AWS accounts in an organization. Staff authenticate once—often federated from the city’s existing IdP—and receive temporary, role-based access into the accounts they need without maintaining a unique IAM user per person per account. That pattern matches multi-subsidiary municipal operations where parks, rail, and shared IT must share a controlled door rather than a ring of unmanaged keys.

Creating a unique IAM user in every account and sharing passwords in a spreadsheet fails because it multiplies long-lived credentials, cannot enforce consistent MFA or revocation, and is operationally incompatible with least privilege across subsidiaries. Enabling only root MFA and instructing staff to sign in as root fails conceptually because the root user is an emergency break-glass identity, not a workforce access path; daily root use destroys accountability and maximizes blast radius. Publishing an open S3 static site that hosts long-lived access keys fails because it deliberately exposes standing credentials on a public object store and substitutes key distribution for identity federation.

Exam caveat: Identity Center assignment alone does not replace SCPs, CloudTrail, or per-account guardrails—SSO is the front door, not the entire multi-account security program. Operational check: confirm permission sets map to job functions (not “admin everywhere”), verify federation and MFA requirements with the city’s IdP, and revoke a departing subsidiary user’s Identity Center access while proving they can no longer assume roles in production accounts.