ExamFinch.com My Study

Study guide

2.4 Amazon Cognito

Practice this exam

AWS Certified Developer – Associate DVA-C02

Track your progress as you read

Finished sections get a check mark.

1 Introduction: DVA-C02 Overview & Study Plan

1.1 What the AWS Developer Associate Tests 1.2 Exam Format, Scoring & Logistics 1.3 The Four Domains & A Study Plan

2 Chapter 1: Development with AWS Services

1.1 AWS Lambda 1.2 Amazon API Gateway 1.3 Amazon DynamoDB 1.4 Amazon S3 1.5 Messaging: SQS, SNS, EventBridge 1.6 Containers: ECS, ECR, Fargate 1.7 AWS SDK & API Best Practices

3 Chapter 2: Security

2.1 IAM for Developers 2.2 Encryption & AWS KMS 2.3 Secrets Manager vs Parameter Store 2.4 Amazon Cognito

4 Chapter 3: Deployment

3.1 CloudFormation & SAM 3.2 CI/CD with CodePipeline, CodeBuild, CodeDeploy 3.3 Deployment Strategies 3.4 Elastic Beanstalk & Container Deploys

5 Chapter 4: Troubleshooting, Optimization & Exam Strategy

4.1 Observability: CloudWatch & X-Ray 4.2 Performance & Caching 4.3 Common Traps & Final Review

2.4 Amazon Cognito

Key Takeaways Explain This Topic AI

Amazon Cognito user pools handle authentication: sign-up, sign-in, MFA, and a managed Hosted UI, issuing ID, access, and refresh JWT tokens

Amazon Cognito identity pools handle authorization to AWS: they exchange a user pool token or third-party login for temporary AWS credentials via STS

The user pool ID token carries identity claims, the access token carries scopes/authorization for APIs, and the refresh token obtains new ID and access tokens

Identity pools support both authenticated and unauthenticated (guest) roles and federate Google, Facebook, Apple, SAML, and OIDC providers

Use a user pool to log users in; add an identity pool only when those users must call AWS services like S3 or DynamoDB directly

Last updated: June 2026

The Single Biggest Cognito Confusion

DVA-C02 loves to test whether you know the difference between the two halves of Amazon Cognito . Memorize one sentence: user pools log users IN; identity pools hand out AWS CREDENTIALS. Nearly every Cognito question reduces to deciding which half (or both) is required.

User Pools — Authentication

A user pool is a managed user directory. It handles:

  • Sign-up and sign-in , password policies, account recovery, and email/phone verification
  • Multi-factor authentication (MFA) — SMS or time-based one-time password (TOTP)

A managed Hosted UI plus OAuth 2.0 / OpenID Connect (OIDC) endpoints, and federation with social and SAML providers

App clients and Lambda triggers (pre-sign-up, pre-token-generation, custom auth challenge) for custom flows

On success the user pool issues three JSON Web Tokens (JWTs) :

  • Token Purpose Default lifetime
  • ID token Identity claims (username, email, attributes) 1 hour
  • Access token Scopes/authorization for APIs and Cognito self-service operations 1 hour
  • Refresh token Obtains new ID and access tokens without re-login 30 days (configurable)

API Gateway can validate a user pool JWT directly with a Cognito authorizer — no AWS credentials involved. This is the cheapest way to protect a REST API for logged-in users.

Identity Pools — Authorization to AWS

An identity pool (federated identities) does not authenticate users. It takes a token — from a Cognito user pool, Google, Facebook, Apple, SAML, or any OIDC provider — and exchanges it through AWS STS for temporary AWS credentials . Those credentials let the user call AWS services such as S3 or DynamoDB directly under an IAM role.

Identity pools support two role types:

Authenticated role — for users who signed in with an identity provider.

Unauthenticated (guest) role — for anonymous users you explicitly choose to allow.

Role selection can use a default role, rule-based mapping on token claims, or attribute-based access control (ABAC) that injects token attributes as IAM Condition values, so one role can scope each user to their own S3 prefix or DynamoDB items.

How They Work Together User → User Pool (login) → JWT → Identity Pool → STS → AWS credentials → S3/DynamoDB

Need only sign-in / a logged-in identity (e.g., protect an API behind a Cognito authorizer) → user pool alone .

Need users to call AWS services directly from the client → user pool plus identity pool .

Need guest access to AWS resources with no login → identity pool with an unauthenticated role .

Common Exam Traps

Treating the ID token as an API authorization token — that is the access token's job.

Thinking a user pool can return AWS credentials — it cannot; only an identity pool (via STS) does.

Provisioning a long-lived IAM user per app user — never the answer; identity pools vend short-lived credentials instead.

Federation and Hosted UI

A user pool can federate external identity providers so users sign in with existing accounts. Social providers (Google, Facebook, Apple, Amazon) use OAuth/OIDC; enterprise providers connect via SAML 2.0 or generic OIDC . The Hosted UI is an AWS-managed, brandable sign-in page reachable at your user pool domain; it implements the OAuth 2.0 authorization-code and implicit flows so you do not build login screens yourself. App clients can also use direct SDK flows like USER_SRP_AUTH (Secure Remote Password, which never sends the password over the wire) for custom front ends.

Securing APIs: Authorizer Choices

For protecting an API behind logged-in users, the exam compares three options:

  • Approach What it validates When to choose
  • Cognito authorizer A user pool JWT, automatically Simplest path for user-pool-authenticated REST APIs
  • Lambda authorizer Any token/header via custom code Non-Cognito tokens or complex authorization logic
  • IAM authorization SigV4-signed requests with AWS creds Service-to-service or identity-pool credentials

If the scenario says users authenticate with a Cognito user pool and you must protect an API Gateway endpoint, the Cognito authorizer is almost always the lowest-effort correct answer.

Token Validation and Lifetimes

Clients should validate the JWT signature against the user pool's public JSON Web Key Set (JWKS) and check exp , aud / client_id , and iss . Access and ID tokens default to a one-hour lifetime; the refresh token (default 30 days, configurable from 5 minutes to 10 years) is exchanged at the token endpoint for fresh access and ID tokens, so users are not forced to log in hourly. Never use the refresh token to call APIs directly — only the access token authorizes resource calls.

Lambda Triggers and Customization

User pools expose Lambda triggers at key lifecycle points, and the exam expects you to map a customization to the right trigger. The pre-sign-up trigger can auto-confirm or auto-verify users; the pre-authentication and post-authentication triggers run around login for logging or risk checks; the pre-token-generation trigger adds or suppresses custom claims in the ID/access token (for example, injecting a tenant ID or a group-derived role); and the custom auth challenge triggers (define/create/verify) implement passwordless or CAPTCHA flows.

A worked scenario: to embed a customer's subscription tier into the token so downstream APIs can authorize on it without a database lookup, use the pre-token-generation trigger to add a custom claim. Combined with a Cognito authorizer, this lets API Gateway authorize requests entirely from the validated JWT — no extra round trips, lower latency, and a clean separation between authentication (user pool) and AWS authorization (identity pool).