Project: Build a Serverless REST API

As with earlier hands-on projects in this course, you can design this directly in a real AWS account or work through it entirely on paper. If you do build any of this in a real account, review your current Free Tier eligibility and current pricing for Lambda, API Gateway, and DynamoDB first — none of these should be assumed automatically free, and each has its own independent cost story.

A small internal tool needs an API that accepts a training registration and stores it. The core synchronous flow, exactly the shape Lesson 3 introduced:

Client
  → API Gateway (POST /registrations)
  → Lambda (validates the request, writes the registration)
  → DynamoDB (one item per registration)
  → Response (success or a clear error) back to the client

Optionally, once a registration is stored, a second, asynchronous path can react to it — for example, an event published to EventBridge that triggers a second Lambda function to log the registration or send an internal notification. This second path doesn't block the client's response; the client already received its result from the synchronous path before this asynchronous step even begins.

Work through each component and be able to justify its placement:

• Trigger: API Gateway, because a human or another system is submitting a registration and expects an immediate result — this is a synchronous fit (Lesson 3), not asynchronous.
• Lambda's responsibility: validate the incoming registration data, then write exactly one item to DynamoDB — keep the function's job narrow and specific.
• Data store: DynamoDB, with a partition key built around how registrations will actually be looked up later (Module 5's access-pattern-first reasoning) — for example, by registration ID, or by the training course being registered for, depending on what the tool actually needs to query.
• IAM role: the Lambda function's execution role grants only dynamodb:PutItem (and, if registrations are later read back, dynamodb:GetItem/Query) on this one specific table — never a broad DynamoDB or account-wide policy (Lesson 4, Module 2).
• Error handling: a validation failure (missing required fields, for example) should return a clear error response to the client synchronously, not fail silently.
• Idempotency consideration: if the optional asynchronous notification path exists, it should tolerate the same registration event arriving more than once (Lesson 4) without sending duplicate notifications.
• Observability: CloudWatch logs and metrics (Lesson 5) for both Lambda functions — invocation count, error count, and duration — so a problem is visible before a learner has to guess at it.
• Cost: Lambda invocations, API Gateway requests, and DynamoDB read/write capacity all have their own independent cost stories — review current pricing rather than assuming a small training load is free.

If any part of this was built in a real account, work through this checklist before considering the project finished — some of these have dependencies on each other, so order matters:

1. Delete the API Gateway API and its stage(s) first, since removing the entry point first prevents any further invocations while you clean up what's behind it.
2. Delete the Lambda function(s) created for this project (both the synchronous registration function and, if built, the asynchronous notification function).
3. Remove any EventBridge rule created solely for this training exercise, if the optional asynchronous path was built.
4. Delete the DynamoDB table, once you're confident you don't need the data in it — review its contents first if that matters to you.
5. Delete the CloudWatch log groups created for these functions, if you don't need to keep the logs.
6. Delete the IAM execution role(s) created solely for this project, once nothing still references them.
7. Confirm nothing training-related remains by checking the Lambda, API Gateway, DynamoDB, and IAM dashboards directly — the same "verify, don't assume" discipline every earlier module's project applied to its own resources.