A retailer runs corporate AWS access for 800 employees with Okta, a customer mobile app with 200,000 users, and EC2 microservices calling DynamoDB. Password sprawl and hard-coded keys caused incidents. Which identity architecture should the architect implement to provide phishing-resistant workforce, customer, and workload authentication?
Select an answer to reveal the explanation.
Short Explanation
You've got three different crowds knocking, so you'll want to give each its own front door like a hotel with staff, guest, and service entrances. Your employees federate through Okta with IAM Identity Center, your shoppers sign in with Amazon Cognito, and your microservices use IAM roles instead of hard-coded keys.
Full Explanation
The correct approach federates the human workforce through IAM Identity Center integrated with Okta for centralized SSO, MFA, and short-lived portal credentials, uses Amazon Cognito User Pools plus Identity Pools for scalable customer sign-up, social federation, and temporary AWS credentials, and attaches IAM roles to EC2 instance profiles or ECS task roles for system authentication without static keys. Creating IAM users with MFA and access keys for microservices fails by concept because IAM users do not scale for hundreds of staff and long-term keys for workloads invite leakage and rotation burden, while deploying AD Connector plus API keys fails because API keys are not authentication for end users and shared roles destroy auditability and least privilege. Using Identity Center for both employees and customers with embedded credentials fails because Identity Center is designed for workforce identities, not massive consumer directories, and embedding long-term credentials reintroduces the exact secret-sprawl risk. For the exam, map Identity Center to workforce, Cognito to customers, and roles to workloads, and in practice enforce MFA, use ABAC with role session tags, and rotate any remaining keys via Secrets Manager.