Architects must not conflate citizen-facing sign-in with workforce AWS access for a municipal portal. Which identity pattern is correct?
Select an answer to reveal the explanation.
Short Explanation
Citizens get a library-card login (Cognito). Staff who open AWS doors get the employee badge system (IAM Identity Center). Mixing those—or handing citizens IAM users and keys—is how you blur customer identity with cloud admin access.
Full Explanation
Citizen-facing sign-in and workforce AWS access are different identity planes. Amazon Cognito user pools (customer identity) authenticate residents to the municipal portal and mobile app, while AWS IAM Identity Center federates employees for AWS console and CLI access into Organization accounts. Keeping those patterns separate prevents architects from forcing citizens through workforce SSO or minting IAM users for the public.
Using IAM Identity Center user portal credentials as the only login for anonymous or public citizens conflates workforce AWS access with application identity and does not scale as a citizen IdP. Creating IAM users for every citizen with long-lived access keys for the mobile app is operationally impossible and insecure. Sharing one IAM role’s permanent access keys inside the citizen mobile app binary embeds cloud credentials in a redistributable client.
Exam caveat: Cognito = app/customer identity; IAM Identity Center = workforce AWS access; IAM users/keys in mobile apps are almost always wrong on SAP-C02. Operational check: implement Cognito for the portal sign-in path, keep Identity Center for staff AWS access, confirm citizens never appear as IAM users, and verify the mobile app uses Cognito tokens rather than embedded access keys.