Almost every SAA-C03 candidate can recite what IAM users and roles do. Then a question describes a mobile app with a million end-users who sign in with Google and upload photos to S3, and the trap answers all involve creating IAM users — which is exactly wrong. The service that owns that scenario is Amazon Cognito, and the single most-tested thing about it is a distinction candidates routinely blur: User Pools authenticate people, Identity Pools hand out AWS credentials. Get that one sentence right and a whole family of exam questions collapses into a quick decision.
This guide takes an architect’s view of Cognito for the SAA-C03 exam. It builds on the identity foundations in the AWS IAM guide for SAA-C03 — where Cognito appears as one option among many — and drills into the parts the exam actually rewards: the two pool types, how they combine, federation with external identity providers, the tokens Cognito issues, and the signal words that tell you which piece a scenario wants. For the wider security domain, the designing secure architectures guide places Cognito next to IAM Identity Center and STS so you can tell them apart under time pressure.
Why Cognito Exists: End-Users Are Not IAM Principals
IAM is built for your principals — the people and workloads inside your AWS account. It does not scale to the customers of an application. You would never create an IAM user for every visitor to a photo-sharing app: IAM has hard limits on users per account, no sign-up UI, no email/phone verification, and no social login. Cognito is AWS’s answer to customer identity and access management (CIAM) — the sign-up, sign-in, and access-control layer for the end-users of web and mobile apps.
The exam leans on one clean split of responsibilities:
| Concern | Service | One-line role |
|---|---|---|
| Your team / workloads accessing AWS | IAM | Principals inside your account |
| Workforce SSO across many AWS accounts & SaaS apps | IAM Identity Center | Human employees, centrally |
| App end-users (customers) signing in | Cognito User Pool | Authentication for your app’s users |
| Giving those app users temporary AWS credentials | Cognito Identity Pool | Authorization to AWS resources |
Keep that table in your head and most “which identity service?” questions answer themselves. If the actors are your customers using your app, it is Cognito. If they are your employees needing console/CLI access across accounts, it is IAM Identity Center. If they are AWS principals in one account, it is IAM.
User Pools: Authentication (“Who Are You?”)
A User Pool is a fully managed user directory. It handles the entire authentication lifecycle so you do not build it yourself:
- Sign-up and sign-in with username/email/phone and a configurable password policy.
- Verification of email and phone, and self-service account recovery.
- Multi-factor authentication (MFA) — SMS or TOTP authenticator apps.
- A Hosted UI (an AWS-hosted sign-in page you can brand and put on a custom domain) so you can skip building login screens.
- App clients — the per-application configuration that defines allowed auth flows, token expirations, and OAuth scopes.
- Groups that can map to IAM roles for coarse-grained authorization.
- Lambda triggers at points in the flow (pre-sign-up, post-confirmation, pre-token-generation, custom auth challenges) to inject your own logic — for example, blocking disposable email domains or adding custom claims to a token.
When a user authenticates successfully, the User Pool issues JSON Web Tokens (JWTs). That is the key output: a User Pool proves who the user is and returns signed tokens your application (and services like API Gateway) can trust. It does not, by itself, give the user any access to your AWS resources.
Exam signal words that point to a User Pool: “sign up / sign in,” “user directory,” “hosted login page,” “MFA for app users,” “email/phone verification,” “add authentication to my application.”
Identity Pools: Authorization to AWS (“What Can You Touch?”)
An Identity Pool (historically “Cognito Federated Identities”) solves a different problem: your authenticated user now needs to call an AWS service directly — say, upload straight to an S3 bucket or read from DynamoDB from the mobile client. AWS APIs require AWS credentials, and a JWT is not an AWS credential.
The Identity Pool exchanges a proof of identity for temporary, limited-privilege AWS credentials minted by STS. It accepts identities from many sources — a Cognito User Pool, social providers, SAML, OIDC, or even unauthenticated (guest) access — and vends credentials tied to an IAM role:
- Authenticated role — for signed-in users.
- Unauthenticated role — for guests, when you want to allow limited access (for example, read-only browsing) before login.
- Role mapping — choose the IAM role dynamically based on rules or token claims (e.g., users in the
admingroup get a broader role).
Exam signal words that point to an Identity Pool: “temporary AWS credentials,” “access S3/DynamoDB directly from the app,” “guest / unauthenticated access to AWS resources,” “exchange a token for AWS credentials,” “scope each user to their own S3 prefix.”
The distinction to memorize:
| User Pool | Identity Pool | |
|---|---|---|
| Answers | Who are you? (authentication) | What AWS can you use? (authorization) |
| Output | JWTs (ID, access, refresh) | Temporary AWS credentials (via STS) |
| Talks to | Your app / API Gateway | AWS services (S3, DynamoDB, …) |
| Backs onto | A user directory | IAM roles |
| Guest access | No | Yes (unauthenticated role) |
The Combined Flow: How the Two Pools Work Together
The canonical Cognito architecture — and a favourite exam pattern — uses both pools in sequence:
1. App user signs in ──▶ Cognito USER POOL
2. User Pool returns JWTs (ID / access / refresh)
3. App passes the ID token ──▶ Cognito IDENTITY POOL
4. Identity Pool calls STS, returns temporary AWS credentials
5. App uses those credentials ──▶ Amazon S3 / DynamoDB / etc.Read that as: authenticate with the User Pool, then swap the resulting token at the Identity Pool for AWS credentials. A scenario that says “users log in and then upload to S3” is describing this two-step flow. A scenario that stops at “users log in to the app” needs only a User Pool. A scenario that says “guests, with no login, get limited AWS access” needs only an Identity Pool (unauthenticated role).
You do not always need both. If your backend is an API (via API Gateway) and the client never calls AWS services directly, a User Pool alone is enough — API Gateway validates the JWT. If your app is a pure guest experience with no sign-in, an Identity Pool alone covers it.
Federation: Signing In With an External Identity Provider
“Federation” means trusting an external identity provider (IdP) so users do not create yet another password. Cognito supports it at both layers, and knowing where federation plugs in is a common exam nuance.
User Pool federation makes the User Pool a token broker in front of external IdPs:
- Social IdPs — Google, Facebook, Apple, Amazon (the “sign in with Google” scenario).
- SAML 2.0 — a corporate IdP such as an existing enterprise directory.
- OIDC — any OpenID Connect provider.
The user signs in at the external IdP, and the User Pool still issues its own standard Cognito tokens. This is the modern, recommended pattern: your app only ever deals with one token format, regardless of how many IdPs you support.
Identity Pool federation can also accept external IdPs directly (social, SAML, OIDC, or a User Pool) and go straight to AWS credentials. In practice, most designs federate at the User Pool and then hand its token to the Identity Pool, keeping a single consistent token flow.
Exam cues: “sign in with Google/Facebook/Apple” → User Pool with a social IdP; “let corporate users authenticate with our existing SAML identity provider” → User Pool with SAML federation; “we already run an OIDC provider” → OIDC federation.
The Tokens Cognito Issues
When a User Pool authenticates a user it returns three JWTs, and the exam occasionally tests what each is for:
| Token | Purpose | Typical use |
|---|---|---|
| ID token | Carries identity claims (who the user is — name, email, groups) | Your app reads user attributes; passed to an Identity Pool |
| Access token | Carries authorization scopes (OAuth) | Authorizing calls to User Pool APIs and OAuth resource servers |
| Refresh token | Longer-lived; gets new ID/access tokens without re-login | Silent session renewal |
All three are signed JWTs; the ID and access tokens are short-lived (minutes to an hour), while the refresh token is long-lived (configurable up to years) so users are not forced to sign in constantly. When you wire Cognito into API Gateway, a Cognito User Pool authorizer validates the JWT on each request — no custom auth code needed. The API Gateway integrations guide covers where the User Pool authorizer sits relative to Lambda authorizers if you need finer control.
Cognito vs the Alternatives (Don’t Mix Them Up)
The exam plants tempting-but-wrong identity services in the answer choices. Sort them by who the actor is:
| Scenario | Right service | Wrong (trap) answers |
|---|---|---|
| Customers signing in to your web/mobile app | Cognito User Pool | IAM users, IAM Identity Center |
| App users needing direct, scoped AWS access | Cognito Identity Pool | IAM users with long-term keys |
| Employees needing SSO across many AWS accounts | IAM Identity Center | Cognito |
| An EC2 instance or Lambda needing AWS access | IAM role | Cognito, IAM user |
| Cross-account access for your own workloads | IAM role + STS AssumeRole | Cognito |
The recurring trap is IAM users for application end-users. Long-term access keys embedded in a mobile app is an anti-pattern the exam actively tests against — the correct design is Cognito plus temporary credentials.
Security Features Worth Knowing
Cognito ships several security capabilities that map to “harden the sign-in” style questions:
- MFA — optional or required, via SMS or TOTP.
- Adaptive authentication — risk-based MFA that steps up challenges when a sign-in looks anomalous (new device, unusual location).
- Compromised-credentials detection — blocks sign-ins using credentials known to be breached.
- Password policies, account lockout, and encryption of user data at rest.
When a scenario asks how to reduce account-takeover risk for app users without forcing MFA on everyone, adaptive authentication is usually the intended answer.
Worked Exam Pattern
A mobile game lets players sign in with their Google or Apple accounts. After signing in, each player must be able to save game state to a personal folder in an S3 bucket, and nobody should access another player’s folder. What should the architecture use?
Walk the decision:
- Players sign in with Google/Apple → a User Pool with those social IdPs (federation).
- Players must call S3 directly with AWS credentials → an Identity Pool exchanges the User Pool token for temporary credentials.
- “Personal folder, no cross-access” → an IAM role on the Identity Pool that uses policy variables (e.g.,
${cognito-identity.amazonaws.com:sub}) to scope each user to their own S3 prefix.
Answer: User Pool (social federation) → Identity Pool → scoped IAM role. That three-part shape is the Cognito question in its purest form.
Practice in Realistic Exam Conditions
Cognito questions are fast points if the User-Pool-vs-Identity-Pool reflex is automatic — and slow, error-prone ones if it is not. Reading about the two pools is not the same as seeing the trap answers under a 130-second-per-question clock and instantly discarding the IAM-users option.
The AWS Certified Solutions Architect – Associate (SAA-C03) Mock Exam Bundle gives you eight full-length mock exams — 520+ scenario questions at real exam length (65 questions, 130 minutes) — with the kind of identity and security scenarios where Cognito, IAM, and IAM Identity Center are all on the table and you have to pick the one that fits. Every answer is explained, so when you mistake a User Pool question for an Identity Pool one you find out why before exam day. Pair it with the SAA-C03 study plan to sequence identity alongside the rest of the syllabus, and the exam domains and strategy guide to see how the secure-access domain is weighted.
Conclusion
For the SAA-C03, Amazon Cognito comes down to one durable distinction: User Pools authenticate your app’s users and issue JWTs; Identity Pools exchange an identity for temporary AWS credentials via STS. User Pools own sign-up, sign-in, MFA, the hosted UI, and federation with social/SAML/OIDC providers. Identity Pools own the handoff to AWS — including guest access through an unauthenticated role and per-user scoping through IAM policy variables. The two combine in a clean sequence: sign in at the User Pool, swap the token at the Identity Pool, then call AWS. Learn the signal words, refuse the “IAM users for customers” trap, and Cognito becomes one of the more predictable topics in the secure-architectures domain.
For adjacent identity and security topics, review the IAM guide for SAA-C03 (roles, policies, and STS — the machinery underneath Identity Pools), designing secure architectures (where Cognito sits among IAM Identity Center and federation), and the scenario where authenticated users trigger downstream work via SQS, SNS, and EventBridge. Keep the Solutions Architect cheat sheet close for a one-line reminder of each identity service’s job.
Frequently Asked Questions
What is the difference between a Cognito User Pool and an Identity Pool?
A User Pool is a user directory that authenticates people and issues JWT tokens — it answers “who are you?” An Identity Pool takes an authenticated (or guest) identity and returns temporary AWS credentials so the user can call AWS services directly — it answers “what AWS resources can you use?” User Pools do authentication; Identity Pools do authorization to AWS.
Do I always need both pools?
No. Use a User Pool alone when your app only needs sign-in and your backend (e.g., API Gateway) validates the token — the client never calls AWS directly. Use an Identity Pool alone for guest experiences with no sign-in that still need limited AWS access. Use both when authenticated users must call AWS services directly, which is the most common combined pattern.
How do users sign in with Google or Facebook?
Configure the social identity provider on a Cognito User Pool (federation). The user authenticates at Google/Facebook/Apple/Amazon, and the User Pool still returns its own standard Cognito tokens, so your app deals with a single token format regardless of the external IdP.
What are the three tokens Cognito returns?
The ID token (identity claims about the user), the access token (OAuth scopes for authorizing API calls), and the refresh token (long-lived, used to obtain new ID/access tokens without re-authenticating). ID and access tokens are short-lived JWTs; the refresh token controls how long a session lasts.
When should I use Cognito instead of IAM Identity Center?
Use Cognito for the end-users (customers) of your application. Use IAM Identity Center for your workforce — employees who need single sign-on across multiple AWS accounts and SaaS applications. Different audiences, different services.
How do I stop one app user from accessing another user’s S3 files?
Attach an IAM role to the Identity Pool that uses policy variables (such as the Cognito identity ID) in the resource ARN, so each user’s permissions are scoped to their own S3 prefix. Combined with authenticated-role role mapping, this enforces per-user isolation without writing custom authorization code.
Can Cognito protect an API Gateway API?
Yes. A Cognito User Pool authorizer validates the User Pool JWT on each request to a REST or HTTP API, rejecting unauthenticated calls before they reach your integration — no custom auth code required.