A logistics company has corporate staff using Okta, delivery drivers using mobile phones with social logins, and microservices calling AWS APIs from ECS tasks. Access must federate human identities centrally while giving apps scalable customer auth without long-lived keys. Which identity architecture best supports human, app, and system authentication needs?

The correct architecture matches each identity type to its purpose-built service, with IAM Identity Center federating Okta via SAML or OIDC for centralized workforce single sign-on and permission sets, Amazon Cognito handling mobile drivers via user pools for social sign-up plus identity pools to vend temporary credentials at internet scale, and ECS task roles providing containers with automatic short-lived STS credentials for AWS API calls without stored secrets. The architecture injecting long-lived keys via Secrets Manager fails on lifecycle management because rotation and encryption still leave static credentials exposed in images, logs, and env variables, violating the no long-lived keys mandate where task roles would auto-rotate. The architecture placing drivers in IAM Identity Center fails on customer identity scale because Identity Center is designed for internal workforce directories without native social providers or millions of external identities, which Cognito supports with OAuth flows and federation. The architecture placing corporate staff in Cognito user pools fails on centralized workforce governance because Cognito lacks cross-account permission sets, Okta lifecycle sync, and workforce audit, fragmenting access control. An exam caveat is to classify the principal first as workforce versus customer versus workload, since names overlap but trust policies differ sharply. A practical check is to verify Okta as an external IdP in Identity Center, social providers configured in the Cognito identity pool, and each ECS task definition carrying a least-privilege taskRoleArn with CloudTrail showing STS temporary credentials.