Customer and app identity (Amazon Cognito): SCS-C03 study notes and practice questions
What to know about Customer and app identity (Amazon Cognito) for the SCS-C03 exam, from the Identity and Access Management domain (20% of the exam guide), then 2 free questions to test it. Part of the SCS-C03 study guide.
These questions describe an application with many end users, often a mobile or web front end. The key phrase is usually whether users need to sign in to your application, or whether they need AWS credentials to reach a resource such as an S3 prefix or a DynamoDB table. Those are different Cognito components, and the wrong one is a common distractor.
The two Cognito components
User pools are a user directory. They provide sign-up and sign-in, password policies, MFA, account recovery, hosted sign-in pages and tokens (ID, access and refresh tokens). Your API or application validates those tokens.
Federation in user pools accepts sign-in from social providers and from SAML 2.0 or OIDC identity providers, and maps the provider’s attributes onto user pool attributes.
Identity pools exchange a token from a user pool or another identity provider for temporary AWS credentials. Each user gets an authenticated IAM role, and you can also define an unauthenticated (guest) role.
Put policy variables such as ${cognito-identity.amazonaws.com:sub} in the role’s policy so each user can reach only their own S3 prefix or DynamoDB items. Without that scoping, every signed-in user gets the same access.
Threat protection features add risk-based checks to user pool sign-in.
For fine-grained rules inside the application, pair the user pool with Amazon Verified Permissions.
How to choose
Scenario wording
Pick
Mobile or web users sign up and sign in to your application
Cognito user pool
App users read or write their own S3 or DynamoDB data directly
Cognito identity pool with an authenticated role scoped by policy variables
Customers sign in with a social or enterprise identity provider
User pool with federated identity providers
Employees need console or CLI access to AWS accounts
IAM Identity Center, not Cognito
Per-user authorization rules across many application operations
Amazon Verified Permissions, with the user pool as identity source
Guests use a limited part of the app without signing in
Identity pool unauthenticated role, with narrow permissions
Common traps
Identity pools alone for sign-up and password management. Identity pools do not handle sign-up or password reset. A user pool does.
One broad authenticated role with no per-user scope, so any signed-in user can read another user’s data.
A broad unauthenticated role. Guest access should grant the smallest possible set of actions.
Using Cognito for workforce accounts. Workforce access belongs in IAM Identity Center.
Storing AWS access keys in the app instead of using identity pool credentials, which are temporary.
A regional bank runs a mobile banking app that uses an Amazon Cognito user pool for sign-in. The fraud team has seen account takeovers in which criminals reuse passwords leaked in unrelated breaches.
Customers on a familiar device should not be asked for a second factor at every sign-in. Sign-ins from unfamiliar devices or locations must require one, and high-risk sign-ins and known leaked passwords must be blocked. The app team does not want to write risk-scoring code.
Which solution meets these requirements with the LEAST custom code?
Choose one answer.
AA. Keep MFA optional, and add a pre authentication Lambda trigger that compares each sign-in IP address with a stored list of known addresses for each customer, blocking any that do not match.
BB. Set MFA to optional and turn on threat protection in full-function mode. Require MFA for medium-risk sign-ins, and block high-risk sign-ins and compromised credentials.
CC. Require SMS MFA for every sign-in, and associate an AWS WAF web ACL with the user pool that blocks clients sending more than 100 sign-in requests in five minutes.
DD. Turn on threat protection in audit-only mode, and send the risk events to a dashboard that the fraud team reviews each morning to disable risky accounts by hand.
Show the answer and explanation
Answer: B
A. Wrong: The trigger can block some sign-ins, but it is custom risk-scoring code that the team does not want to write. An address list also fails customers who travel, and it cannot detect leaked passwords.
B. Right: Correct. Threat protection scores each sign-in for risk, including unfamiliar devices and locations, and detects passwords found in public breaches. Adaptive authentication then asks for a second factor or blocks the sign-in, with no custom scoring code. Learn more: Threat protection for Amazon Cognito user pools (opens in a new tab)
C. Wrong: Customers on familiar devices would be asked for a second factor every time, which the bank wants to avoid. A slow attack with leaked passwords would also stay under the rate limit.
D. Wrong: Audit-only mode logs risk but takes no action, so high-risk sign-ins and leaked passwords are not blocked. A morning review leaves accounts exposed for hours.
Explanation
Cognito threat protection in full-function mode scores each sign-in and detects compromised credentials. Adaptive authentication turns that risk into a second-factor challenge or a block, so customers on familiar devices are not challenged every time. Custom triggers, always-on SMS with rate limits, and audit-only mode each miss a requirement.
A subscription company runs a customer web app and an admin console through the same Amazon API Gateway REST API. Users sign in with an Amazon Cognito user pool, and support staff belong to a group named support-admins.
Only members of support-admins may call the routes under /admin. Customers must not be able to call those routes even with a valid token. The team does not want to run a separate token server, and route access must change when staff join or leave the group.
Which solution meets these requirements?
Choose one answer.
AA. Attach the Cognito user pool authorizer to the whole API. Create a second app client for support staff, so that only staff tokens can be issued for the admin routes.
BB. Attach a Lambda authorizer to the /admin routes that verifies the Cognito token and returns an IAM policy allowing the call only when the cognito:groups claim includes support-admins.
CC. Store a support flag in a custom attribute, and have the web app send an x-support header with each admin request. The API then checks that header against the value in the user's profile before it forwards the call.
DD. Create a separate API Gateway REST API for the admin console with an IAM authorizer, and create IAM users in the same account for each support employee. Keep the customer API on the Cognito authorizer.
Show the answer and explanation
Answer: B
A. Wrong: Restricting app clients changes which users can sign in, not which token a user holds on each call. Any valid token from the pool passes the authorizer, so a customer could still call the admin routes.
C. Wrong: The browser sets the header, so a customer can send any value it likes. The API would trust client input instead of a signed claim, so the check is not reliable for access control.
D. Wrong: IAM users for support staff bring long-term credentials, and each staff change now needs IAM user management. The requirement is to follow the Cognito group, so this option creates a second identity system to run.
Explanation
A Cognito user pool authorizer checks that a token is valid, but it does not check group membership on each route. A Lambda authorizer can read the signed cognito:groups claim and allow only the admin routes for support staff. Custom headers and IAM users each fail the trust or overhead requirement.
Want more on Customer and app identity (Amazon Cognito)? The 5 full-length practice sets have 5 more Customer and app identity (Amazon Cognito) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →