A city open-data team needs a partner system to pull a bulk GIS feed with rate limits, while citizens still sign in to a separate account portal. Which auth approach fits each audience?
Select an answer to reveal the explanation.
Short Explanation
Partners pulling bulk open data are machines—API keys plus usage plans throttle them cleanly. Citizens logging into the portal are people—Cognito owns that identity. Do not mash the two patterns together.
Full Explanation
Partner system-to-system bulk GIS feeds that need rate limits fit API keys combined with API Gateway usage plans. Citizens signing into a separate account portal fit Amazon Cognito user authentication. Keeping those mechanisms separate matches audience and threat model: partners receive metered machine access, while residents receive user identity, optional MFA, and application tokens—not a single shared secret printed on a flyer.
Issuing IAM user passwords to every citizen browser misuses IAM as a consumer identity provider. Replacing Cognito with one shared API key for both partners and citizens collapses identity and metering into a brittle secret. Requiring partners to complete interactive Cognito hosted UI for every unattended batch download imposes the wrong UX on system-to-system jobs.
Exam caveat: API keys identify and meter calling applications; they are not strong end-user authentication and must not replace Cognito for citizens. Operational check: call the GIS feed with a usage-plan API key and observe throttling at the plan limit; complete citizen portal login with Cognito without needing the partner key; revoke the partner key and confirm feed access stops while citizen login still works.