You log in · Lambda + DynamoDB

Your browser sends POST /login over HTTPS.

POST /login HTTP/1.1
Host: abc123.execute-api.us-east-1.amazonaws.com
Content-Type: application/json

{"email":"sam@example.com","password":"••••••••"}

The request arrives at API Gateway, a managed HTTPS front door. There's no server or firewall for you to look after.

API Gateway invokes your Lambda function and hands it the request as an event.

• 🔑IAM Lambda resource policy: API Gateway may invoke todo-apiAllowed

{
  "Effect": "Allow",
  "Principal": {
    "Service": "apigateway.amazonaws.com"
  },
  "Action": "lambda:InvokeFunction",
  "Resource": "arn:aws:lambda:us-east-1:111122223333:function:todo-api",
  "Condition": {
    "ArnLike": {
      "AWS:SourceArn": "arn:aws:execute-api:us-east-1:111122223333:abc123/*"
    }
  }
}

Exam tipThis is a resource-based policy. It lives on the function and says who may call it, the opposite of a policy attached to a role.

The app reads your email and password. You're a customer of Todo.io, not an IAM user, so AWS has no idea who you are.

Exam tipYour app's customers are never IAM principals. IAM is for the people and software that manage or call AWS itself.

The app gets temporary credentials for its IAM role (the execution role) which Lambda already put in its environment variables. No keys are stored in the code.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Exam tipEvery Lambda function has exactly one execution role. Its permissions are everything your code can do in AWS.

The function calls GetItem on the DynamoDB API over HTTPS, signed with those credentials.

{
  "TableName": "Users",
  "Key": {
    "email": {
      "S": "sam@example.com"
    }
  }
}

Exam tipThis function isn't attached to a VPC, so it reaches DynamoDB directly. No VPC, no security groups.

DynamoDB checks with IAM: may todo-app-lambda-role do dynamodb:GetItem here? The policy on the role allows it on the table's ARN.

• 🔑IAM todo-app-lambda-role: dynamodb:GetItem on table/UsersAllowed

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:us-east-1:111122223333:table/Users",
        "arn:aws:dynamodb:us-east-1:111122223333:table/Todos"
      ]
    }
  ]
}

Exam tipIAM starts from deny. A request is only allowed if some policy explicitly allows it and nothing explicitly denies it.

DynamoDB returns your user item, including the stored password hash.

The app hashes the password you typed and compares it with the stored hash. They match, so it starts a session for you.

• ✓App Password hash matchesAllowed

You get 200 OK plus a session cookie, so your next requests prove who you are.

HTTP/1.1 200 OK
Set-Cookie: session=eyJ1c2VySWQiOiJ1LTEyMyJ9.Zm9v; HttpOnly; Secure

Lambda sends what the function printed to CloudWatch Logs, so Todo.io's engineers can see what happened.

2026-10-11T18:42:07Z INFO POST /login user=u-123 status=200 14ms

Exam tipLambda sends whatever your function prints to CloudWatch Logs automatically, as long as the execution role allows logs:PutLogEvents.