Amazon Cognito: SAA-C03 app authentication scenarios

Where application end-users sign in and where they get temporary AWS access — User Pools, Identity Pools, and federation, the way the exam frames them. Seven scenarios, SAA-C03, 2026 edition.

Try 7 free Amazon Cognito scenarios in the exam's own style — every answer explained, no sign-up.

Straight to the 7 free questions ↓

Amazon Cognito is where the SAA-C03 checks whether you can place application identity correctly. The scenarios rarely ask what Cognito is; they ask which piece of it solves a stated requirement, and whether you can keep it apart from IAM. Two clean distinctions carry almost every question.

User Pools: who the user is

A User Pool is a managed user directory for your app’s end-users. It handles sign-up, sign-in, password policies, multi-factor authentication, and a hosted UI, and it scales to millions of users with no servers for you to run or patch. After a successful sign-in it issues signed JSON Web Tokens — an ID token and an access token — that prove who the user is and carry their group claims.

That token is the payoff. A serverless backend behind Amazon API Gateway can validate it with a Cognito authorizer and admit only signed-in users, reading identity and group membership straight from the claims. The token proves identity to your application — it is not, by itself, an AWS credential.

Identity Pools: temporary AWS access

An Identity Pool (federated identities) answers the other half. It takes a trusted token — from a User Pool or a social provider — and exchanges it, through AWS STS, for short-lived temporary AWS credentials tied to an IAM role. Now the client can call AWS services directly: a mobile app can upload straight to its own prefix in an Amazon S3 bucket, or write to Amazon DynamoDB, with the role’s policy scoping each user to their own data.

The diagram traces the full path: an app user authenticates against the User Pool, presents the returned token to the Identity Pool, receives temporary credentials, and calls S3 and DynamoDB directly. The exam’s favourite trap is trying to hand a User Pool ID token straight to S3 as if it were a credential — it is not. Identity comes from the User Pool; AWS access comes from the Identity Pool.

Federation: bringing in existing identities

Users often already have identities elsewhere. A User Pool can act as a federation hub, accepting social logins (such as Google) and enterprise SAML identity providers, so customers sign in with credentials they already own and your app never stores a password. Downstream code still receives one consistent set of Cognito tokens regardless of where the user came from. This is distinct from IAM SAML federation, which grants a workforce access to the AWS console and APIs — not app customers to your app.

The line you must not cross: Cognito vs IAM

The single sharpest distinction: IAM identifies principals that operate the AWS account — employees, roles, and workloads using the console, CLI, or SDKs. Cognito identifies your application’s own end-users. Minting an IAM user per app customer is a genuine anti-pattern that collides with account limits and mismanages who your customers are. If the identity belongs to someone administering AWS, it is IAM; if it belongs to a customer of your app, it is Cognito.

How to use the seven scenarios below

Answer each before opening the explanation, and when you miss, name the requirement that decided it — “managed directory, no servers”, “call S3 directly from the device”, “sign in with Google”, “operators versus customers”. Every explanation states that deciding constraint and then takes apart the distractors, most of which are real AWS features solving a slightly different problem. That discrimination is the skill the exam measures. For the temporary-credential mechanics underneath Identity Pools, see IAM roles and STS, and for the wider picture, Design Secure Architectures.

An application end-user signing into an app. The user first authenticates against an Amazon Cognito User Pool, which acts as a managed user directory and returns identity and access tokens as proof of who the user is. Those tokens are then presented to an Amazon Cognito Identity Pool, which exchanges them for short-lived temporary AWS credentials from AWS STS. With those credentials the client calls AWS services such as Amazon S3 and Amazon DynamoDB directly. A side note contrasts this end-user path with IAM users, which are for AWS operators, not application customers.

7 free SAA-C03 practice questions

Answers and explanations — no email wall

SAA-C03 Question 1 of 7

A team is building a mobile app for millions of consumers who need to register with email, sign in, and use multi-factor authentication. The team does not want to run, patch, or scale any authentication servers, and wants a ready-made hosted sign-in page. Which AWS service meets this?

Answer: A — An Amazon Cognito User Pool.

A Cognito User Pool is a fully managed user directory: sign-up, sign-in, MFA, password policies, and a hosted UI, scaling to millions with no servers to run. That is precisely the requirement. Why not the others: creating an IAM user per customer is a hard anti-pattern — IAM principals are for people and workloads that operate the AWS account, not application end-users, and IAM has account-level quotas. An Identity Pool alone hands out AWS credentials; it does not provide the sign-up/sign-in directory the app needs to authenticate people. Directory Service plus a hand-built portal is undifferentiated heavy lifting when a managed directory already exists.

SAA-C03 Question 2 of 7

A serverless backend built on Amazon API Gateway must accept requests only from users who have signed into the app's Amazon Cognito User Pool, and must read the caller's identity and group membership. What should the architecture use to enforce this?

Answer: A — Validate the JSON Web Tokens the User Pool issues, using a Cognito authorizer on API Gateway.

After sign-in a User Pool issues signed JWTs (ID and access tokens) that carry the user's identity and group claims; an API Gateway Cognito authorizer verifies those tokens on every request, so only authenticated users get through. Why not the others: application end-users have no IAM access keys, and distributing long-term keys to clients would be a serious credential-exposure risk. Re-sending username and password on every call defeats the point of token-based auth and multiplies password exposure. Filtering by IP does not identify a user at all and breaks the moment addresses change.

SAA-C03 Question 3 of 7

A photo-sharing mobile app authenticates users with a Cognito User Pool. Each signed-in user must upload directly from the device to their own prefix in an Amazon S3 bucket, with no proxy tier in between. What provides the AWS access to do this?

Answer: A — A Cognito Identity Pool that exchanges the user's token for temporary AWS credentials scoped by an IAM role.

A Cognito Identity Pool takes the User Pool token and exchanges it, via AWS STS, for short-lived temporary AWS credentials tied to an IAM role — the role's policy can scope each user to their own S3 prefix. That is exactly 'signed-in user calls S3 directly'. Why not the others: an ID token is proof of identity for your app, not an AWS credential, so S3 will not accept it as one. Embedding a shared key in the app binary leaks a long-term credential to every installed copy. A public, anonymous-write bucket removes the per-user isolation the requirement demands and is dangerous.

SAA-C03 Question 4 of 7

During design review, a colleague asks for the one-line difference between a Cognito User Pool and a Cognito Identity Pool. Which statement is correct?

Answer: A — A User Pool authenticates users and proves who they are; an Identity Pool exchanges that proof for temporary AWS credentials to reach AWS services.

The clean split the exam tests: a User Pool is the identity provider — it authenticates people and issues tokens that say who they are. An Identity Pool (federated identities) takes a trusted token and returns temporary AWS credentials so a client can call AWS services directly. Who you are versus temporary AWS access. Why not the others: the second option reverses the two roles. They are distinct features that are often used together but are not interchangeable. And neither is about AWS operators or raw database rows — that framing confuses Cognito with IAM entirely.

SAA-C03 Question 5 of 7

An enterprise SaaS app must let customers sign in with their existing Google accounts and let corporate customers sign in through their own SAML identity provider. The app team does not want to store or manage passwords itself. What is the most appropriate approach?

Answer: A — Configure the Cognito User Pool to federate social and SAML identity providers, so external identities sign in through the pool.

A User Pool can act as a federation hub: it integrates social providers such as Google and enterprise SAML identity providers, so users authenticate with existing credentials while the app never handles passwords, and downstream code still receives one consistent set of Cognito tokens. Why not the others: hand-building an OAuth/SAML server on EC2 reinvents exactly what Cognito federation offers as a managed feature. IAM SAML federation is for granting AWS Management Console and API access to a workforce, not for signing application customers into an app. Storing other providers' passwords is both unnecessary and a severe security liability.

SAA-C03 Question 6 of 7

A consumer app expects rapid growth from tens of thousands to several million registered users. The team wants sign-up and sign-in to scale automatically with no capacity planning and no auth servers to operate. Which choice fits?

Answer: A — Use a Cognito User Pool, which is a managed, serverless directory that scales to millions of users.

Cognito User Pools are managed and serverless: sign-up and sign-in scale to millions of users with no servers to size, patch, or fail over, which is the least-operational-overhead answer for a fast-growing consumer base. Why not the others: running your own identity server on EC2 works but re-introduces the patching, scaling, and availability work Cognito removes. IAM users are the wrong construct for app end-users and run into account-level limits well before millions. A single vertically scaled RDS instance is a capacity ceiling and a single point of failure — the opposite of scaling automatically.

SAA-C03 Question 7 of 7

An organization has two distinct groups: employees who administer AWS resources through the console and CLI, and external customers who sign into the company's public web app. Which identity model correctly serves each group?

Answer: A — IAM (users and roles) for the AWS operators; Amazon Cognito for the application's end-users.

The dividing line the exam draws: IAM identifies principals that operate the AWS account — employees, roles, and workloads using the console, CLI, or SDKs — while Cognito identifies the application's own end-users signing into the app. Match each group to its tool. Why not the others: pointing Cognito at AWS operators leaves out the console and CLI access model IAM is built for. Minting IAM users for external app customers hits account limits and mismanages who your customers are. And the last option swaps the two, giving customers IAM and operators Cognito — exactly backwards.

That is exactly how every question in the course works — answer, explanation, why-not. The real set continues in the practice player: 10 free questions, no sign-up.

Continue with the 10 free questions →

Those 7 questions were the start.

The exam does not test whether you recognise a term — it tests whether you can rule out three plausible answers under time pressure. That is what the explanations above are for, and there are 780 more questions built exactly like them.

Collecting questions yourself

Scattered across forums, of unknown age
Answer keys without reasoning
No idea which domain you are weak in

Practising with a system

780 questions in 12 full tests, SAA-C03 (2026)
Every option explained — including the wrong ones
Readiness per exam domain, and drills for your weakest

Start free — 10 questions

Straight into the player. No account, no email.

Frequently asked questions

User Pool or Identity Pool — what is the difference?

A Cognito User Pool authenticates people and issues tokens that prove who they are — it is a managed sign-up and sign-in directory. A Cognito Identity Pool takes a trusted token and exchanges it for temporary AWS credentials so the client can call AWS services like Amazon S3 directly. Authentication versus temporary AWS access; the two are commonly used together.

Is Cognito for app users or for AWS administrators?

For application end-users — the customers who sign into your web or mobile app. AWS administrators, developers, and workloads that operate the account use IAM users and roles instead. A quick tell on the exam: if the identity belongs to someone using the AWS console or CLI it is IAM; if it belongs to a customer of your app it is Cognito.

Are these real exam questions?

No. They are original scenarios written for this page in the exam's style and difficulty. Reproducing real exam items violates the AWS certification agreement and can cost a candidate their certification — ours come with the reasoning attached instead.

Updated for SAA-C03 (July 2026). The sample questions above are our own work in the style of the exam — not real exam items. The exam itself is set and marked by the certification body.