Integrate AWS services into a private order API, a recoverable queue consumer and an order-report workflow. Each project asks you to connect previously taught capabilities and verify concrete business results.
The course contains three independent challenges with complete explanatory solutions. Application code, interfaces, synthetic data and unrelated fixtures are supplied so you can focus on service connections, permissions, failure handling and cleanup.
What You Will Learn
- Launch a signed-in order API backed by Lambda, DynamoDB and scoped configuration
- Keep public health available while rejecting anonymous and invalid-token requests
- Recover poison messages only after their corrected business result exists
- Protect stored orders when new duplicate messages are processed
- Build a store/report workflow from S3 input and managed configuration
- Handle temporary, permanent and unauthorized failures with observable outcomes
- Verify downloadable report bytes and remove owned state and private files
Who This Course Is For
This course is for learners who have completed the relevant AWS service labs and want independent integration practice.
Prerequisites: Choose the matching branch below; all three projects start independently.
PS01 builds on Protect API Routes with a JWT Authorizer (A05) route/invocation authorization and its Lambda–DynamoDB prerequisites, plus Load Application Credentials from Secrets Manager (SEC03) credential handling and Separate Configuration with Parameter Store (SEC04) parameter/environment handling. Here prices use ordinary String parameters; the SEC04 SecureString/KMS exercise is not required. CORS and Lambda versions/aliases are optional.
PS02 builds on Isolate Failed Jobs with a Dead Letter Queue (Q03)/Process Queue Jobs Without Duplicate Effects (Q05): visibility and current receipts, bounded failure isolation, Lambda code/role updates and DynamoDB conditional writes. SNS and the other project challenges are optional; no earlier VM resources are reused.
PS03 builds on Keep Workflow Retries from Repeating a Business Effect (EV05) and its FN03/D04/FN02 prerequisites, Process an Uploaded S3 Report (FN04) S3 object reads/writes, and Load Application Credentials from Secrets Manager (SEC03)/Separate Configuration with Parameter Store (SEC04) credential/configuration handling. FN04 is Process an Uploaded S3 Report; FN05 versions/aliases are not required. This workflow does not require S3 notifications, EventBridge routing, SecureString/KMS or either earlier project.
Learning environment: All activities run in a provided browser-based LabEx Linux environment. Use Terminal for AWS CLI commands and AWS View above Terminal to inspect the same resource and application state. Tools and the connection are prepared; you do not need a personal AWS account or access keys. Each lab starts independently in a fresh VM. AWS View correlates API decisions, safe logs, configuration, queue processing, workflow history and table data. No screenshots or report submission are required.
Frequently Asked Questions
Do I need to complete the three challenges in one VM?
No. Each starts independently. Reuse knowledge, not resources, credentials or tokens. The recommended stages follow the API, messaging and workflow service courses.
What does the private API challenge verify?
Signed-in requests create and retrieve computed orders, and configuration changes affect later pricing. Anonymous or invalid-token requests stop before Lambda; invalid input or denied configuration creates no order. JWT route access does not establish per-user ownership. Keep synthetic passwords, tokens and partner credentials private.
When can I acknowledge a failed message?
After the corrected job produces its real business result. Then remove the original failed delivery and test new duplicates. Conditional writes protect one business effect without promising an atomic queue/database transaction or exactly-once delivery.
How is the report workflow assessed?
Execution history, stored orders and downloaded report bytes demonstrate completion under temporary failure and repeated execution. Permanent or unauthorized failures must remain clear. Complete functional checks, remove only owned state and credential-bearing configuration, and preserve unrelated resources.
