Components — Deep Dive

The building blocks the exam actually asks about: what each piece stores, what it issues, and where developers most often trip over the details.

AWS Exam Thinking

Requirement → Keywords → Expected Answer → why every distractor fails. Written in AWS scenario style ("A company needs to...", "What is the MOST appropriate solution?").

Integrations & Architecture

2 — Where Cognito Plugs In

3 — End-to-End Architecture Examples

Best Practices & Common Exam Traps

4 — When to Use / When Not To

5 — User Pools vs Identity Pools

6 — Common Exam Traps

Memory Anchors

Hands-On Lab

Three self-contained exercises that turn the token flow from the Overview tab into real AWS CLI v2 calls. Everything runs in eu-west-1. Work through them in order — Exercise 1 produces the tokens that Exercises 2 and 3 consume.

Lab 1 — User Pool, Test User, and Decoding the JWTs

Create a User Pool and app client, provision a ready-to-use test user without an email/SMS confirmation round-trip, authenticate via the CLI, and inspect the raw claims inside the ID and Access tokens to see the difference the guide describes conceptually.

1. Create the User Pool.

   aws cognito-idp create-user-pool \
     --pool-name dva-lab-pool \
     --region eu-west-1 \
     --auto-verified-attributes email \
     --policies '{"PasswordPolicy":{"MinimumLength":8,"RequireUppercase":true,"RequireLowercase":true,"RequireNumbers":true,"RequireSymbols":false}}'

   JSON output containing "UserPool": { "Id": "eu-west-1_AbCdEfGhI", ... }. Copy this pool ID — every later command needs it.
2. Create a public app client (no secret, so initiate-auth doesn't need a SECRET_HASH).

   aws cognito-idp create-user-pool-client \
     --user-pool-id eu-west-1_AbCdEfGhI \
     --client-name dva-lab-client \
     --no-generate-secret \
     --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
     --region eu-west-1

   "UserPoolClient": { "ClientId": "1a2b3c4d5e6f7g8h9i0j1k2l3m", ... }.
3. Create the test user and set a permanent password in one shot. Using admin-create-user + admin-set-user-password --permanent skips the verification-code step entirely — the fastest way to get a confirmed user for a lab.

   aws cognito-idp admin-create-user \
     --user-pool-id eu-west-1_AbCdEfGhI \
     --username dva-lab-user \
     --user-attributes Name=email,Value=dva-lab-user@example.com Name=email_verified,Value=true \
     --message-action SUPPRESS \
     --region eu-west-1
   
   aws cognito-idp admin-set-user-password \
     --user-pool-id eu-west-1_AbCdEfGhI \
     --username dva-lab-user \
     --password 'DvaLab2026!' \
     --permanent \
     --region eu-west-1

   User status becomes CONFIRMED (check with admin-get-user) — no verification email/SMS round-trip needed.
4. Authenticate and capture all three tokens.

   aws cognito-idp initiate-auth \
     --auth-flow USER_PASSWORD_AUTH \
     --client-id 1a2b3c4d5e6f7g8h9i0j1k2l3m \
     --auth-parameters USERNAME=dva-lab-user,PASSWORD='DvaLab2026!' \
     --region eu-west-1

   A JSON AuthenticationResult block with IdToken, AccessToken, and RefreshToken — three long dot-separated strings. Save the ID and Access tokens as ID_TOKEN and ACCESS_TOKEN — later labs reuse them.
5. Decode the payload (2nd segment) of the ID token and the Access token and compare claims. Base64url segments are often missing padding, so a plain base64 -d one-liner can fail — pad it first, or use Python, which handles this cleanly.

   ID_TOKEN="<paste IdToken here>"
   ACCESS_TOKEN="<paste AccessToken here>"
   
   decode_jwt() {
     python3 -c "
   import sys, json, base64
   p = sys.argv[1].split('.')[1]
   p += '=' * (-len(p) % 4)
   print(json.dumps(json.loads(base64.urlsafe_b64decode(p)), indent=2))
   " "$1"
   }
   
   decode_jwt "$ID_TOKEN"
   decode_jwt "$ACCESS_TOKEN"

   The ID token's JSON shows "token_use": "id" plus identity claims (email, email_verified, cognito:username). The Access token's JSON shows "token_use": "access", a "client_id" claim, and a "scope" claim — and notably has no email claim, because it isn't meant to carry identity data.

Lab 2 — JWT Authorizer on an HTTP API Route

Attach the User Pool as a native JWT authorizer on an API Gateway HTTP API route, then call the route with and without a valid Authorization header to see the 401 vs 200 behavior the Integrations tab describes.

1. Create the HTTP API.

   aws apigatewayv2 create-api \
     --name dva-lab-http-api \
     --protocol-type HTTP \
     --region eu-west-1

   "ApiId": "abc123xyz4" and an "ApiEndpoint": "https://abc123xyz4.execute-api.eu-west-1.amazonaws.com". Save both.
2. Add a backend integration. To keep the lab self-contained (no Lambda to deploy), proxy to a public echo endpoint — the point of this exercise is the authorizer's behavior, not the backend logic.

   aws apigatewayv2 create-integration \
     --api-id abc123xyz4 \
     --integration-type HTTP_PROXY \
     --integration-method GET \
     --integration-uri https://httpbin.org/anything \
     --payload-format-version 1.0 \
     --region eu-west-1

   "IntegrationId": "i1j2k3l4".
3. Create the JWT authorizer, pointing it at the User Pool's issuer URL. The audience is the app client ID — API Gateway matches it against either the aud claim (ID tokens) or the client_id claim (Access tokens).

   aws apigatewayv2 create-authorizer \
     --api-id abc123xyz4 \
     --authorizer-type JWT \
     --identity-source '$request.header.Authorization' \
     --name dva-lab-cognito-jwt-authorizer \
     --jwt-configuration Audience=1a2b3c4d5e6f7g8h9i0j1k2l3m,Issuer=https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_AbCdEfGhI \
     --region eu-west-1

   "AuthorizerId": "auth9z8y7x".
4. Create a protected route wired to both the integration and the authorizer, then deploy an auto-deploying $default stage.

   aws apigatewayv2 create-route \
     --api-id abc123xyz4 \
     --route-key "GET /secure" \
     --target integrations/i1j2k3l4 \
     --authorization-type JWT \
     --authorizer-id auth9z8y7x \
     --region eu-west-1
   
   aws apigatewayv2 create-stage \
     --api-id abc123xyz4 \
     --stage-name '$default' \
     --auto-deploy \
     --region eu-west-1

   Route and stage created; the API endpoint from Step 1 is live at /secure within a few seconds (auto-deploy).
5. Call the route with no header.

   curl -i https://abc123xyz4.execute-api.eu-west-1.amazonaws.com/secure

   HTTP/2 401 with a body like {"message":"Unauthorized"} — the JWT authorizer rejects the request before the integration ever runs.
6. Call it again, sending the Access token from Lab 1 (not the ID token — this is the token type resource servers expect, per Components 1.3).

   curl -i https://abc123xyz4.execute-api.eu-west-1.amazonaws.com/secure \
     -H "Authorization: Bearer ${ACCESS_TOKEN}"

   HTTP/2 200 with the httpbin echo response body — the authorizer validated the token's signature, issuer, and client_id-as-audience, then let the request through with zero custom authorization code.

Lab 3 — Identity Pool: Trading a Token for Temporary AWS Credentials

Create an Identity Pool that trusts the User Pool as an authentication provider, walk through GetId → GetCredentialsForIdentity by hand, and use the resulting temporary credentials to prove they are real, scoped, short-lived AWS credentials — not another JWT.

1. Create the Identity Pool linked to the User Pool app client.

   aws cognito-identity create-identity-pool \
     --identity-pool-name dva_lab_identity_pool \
     --no-allow-unauthenticated-identities \
     --cognito-identity-providers ProviderName=cognito-idp.eu-west-1.amazonaws.com/eu-west-1_AbCdEfGhI,ClientId=1a2b3c4d5e6f7g8h9i0j1k2l3m,ServerSideTokenCheck=false \
     --region eu-west-1

   "IdentityPoolId": "eu-west-1:11111111-2222-3333-4444-555555555555".
2. Create the IAM role the Identity Pool will hand out for authenticated users. The trust policy is the part the exam cares about — it trusts cognito-identity.amazonaws.com, scoped to this specific Identity Pool via the aud condition.

   cat > trust-policy.json <<'EOF'
   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": { "Federated": "cognito-identity.amazonaws.com" },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
         "StringEquals": { "cognito-identity.amazonaws.com:aud": "eu-west-1:11111111-2222-3333-4444-555555555555" },
         "ForAnyValue:StringLike": { "cognito-identity.amazonaws.com:amr": "authenticated" }
       }
     }]
   }
   EOF
   
   aws iam create-role \
     --role-name dva-lab-cognito-authenticated-role \
     --assume-role-policy-document file://trust-policy.json
   
   aws iam attach-role-policy \
     --role-name dva-lab-cognito-authenticated-role \
     --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

   A role ARN like arn:aws:iam::123456789012:role/dva-lab-cognito-authenticated-role, scoped (for this lab) to read-only S3 access.
3. Wire the role to the Identity Pool as the default authenticated role.

   aws cognito-identity set-identity-pool-roles \
     --identity-pool-id eu-west-1:11111111-2222-3333-4444-555555555555 \
     --roles authenticated=arn:aws:iam::123456789012:role/dva-lab-cognito-authenticated-role \
     --region eu-west-1

   No output on success — the mapping is now active.
4. Call GetId, presenting the ID token from Lab 1 as the login (an Identity Pool's --logins map is keyed by the User Pool's issuer path, and expects the ID token there — not the Access token).

   aws cognito-identity get-id \
     --identity-pool-id eu-west-1:11111111-2222-3333-4444-555555555555 \
     --logins cognito-idp.eu-west-1.amazonaws.com/eu-west-1_AbCdEfGhI=${ID_TOKEN} \
     --region eu-west-1

   "IdentityId": "eu-west-1:99999999-aaaa-bbbb-cccc-dddddddddddd" — a Cognito identity, not an AWS credential yet.
5. Call GetCredentialsForIdentity with that identity ID and the same login map.

   aws cognito-identity get-credentials-for-identity \
     --identity-id "eu-west-1:99999999-aaaa-bbbb-cccc-dddddddddddd" \
     --logins cognito-idp.eu-west-1.amazonaws.com/eu-west-1_AbCdEfGhI=${ID_TOKEN} \
     --region eu-west-1

   A Credentials block with AccessKeyId (starts ASIA...), SecretKey, SessionToken, and an Expiration roughly an hour out — temporary STS credentials, exactly as the guide describes, never a static IAM access key.
6. Prove they're real AWS credentials scoped to the mapped role by using them directly.

   AWS_ACCESS_KEY_ID="ASIA..." \
   AWS_SECRET_ACCESS_KEY="..." \
   AWS_SESSION_TOKEN="..." \
     aws sts get-caller-identity --region eu-west-1

   "Arn" in the response reads arn:aws:sts::123456789012:assumed-role/dva-lab-cognito-authenticated-role/CognitoIdentityCredentials — proof this session was minted via sts:AssumeRoleWithWebIdentity against the role from Step 2, not via any User Pool mechanism.

Flashcards — 22 Cards

Click card to flip. Mark right or wrong to track score.

Practice Quiz — 12 Questions

DVA-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.