Project: Build a Simple Application Data Store

As with earlier hands-on projects in this course, you can follow this directly in a real AWS account or read through it without creating anything. If you do create a real RDS instance or DynamoDB table, check your AWS account's current Free Tier eligibility and the current RDS/DynamoDB pricing pages first — per Lesson 1's caution against assuming Free Tier means unconditionally free, don't assume a small training database is automatically free.

Karoo Retail (from Lessons 2 and 5) wants a simple data store for a new internal tool: tracking staff training records, where each record belongs to exactly one employee, and the team wants to run occasional reports joining employees and their completed courses.

Following Lesson 5's reasoning: relationships between two entities, plus reporting needs that aren't fully fixed upfront, point toward a relational data store — Amazon RDS, per Lesson 2.

1. Choose the database family — relational (RDS), following the reasoning above.
2. Sketch the tables — an Employees table (one row per employee) and a TrainingRecords table (one row per completed course, referencing the employee it belongs to).
3. Decide on availability — would this internal tool need a Multi-AZ deployment from day one, or is a single-instance setup acceptable while it's new and low-traffic? (There's a reasonable case for either, depending on how critical the tool is — the point is making the decision deliberately, not by default.)
4. Decide on backups, separately from availability — per Lesson 6, backups are a separate decision from Multi-AZ; even a single-instance, non-Multi-AZ setup should have automated backups configured, since backups protect against a different kind of problem than availability does.

Now consider a different piece of the same tool: logging every time an employee opens the training portal, purely for a simple "last accessed" lookup by employee ID, with no reporting needs across other attributes.

This narrower piece — a known key, a single dominant access pattern, no relationship querying — is a reasonable DynamoDB fit, even though the main training-records data store is relational. Real systems often make this kind of per-piece decision rather than forcing every part of an application into one database family.

If you created real resources for this project, work through both checklists before considering it finished — don't assume either "cleans itself up":

RDS cleanup:

1. Stop or delete the training RDS instance once you're done experimenting.
2. Review any automated snapshots or manual snapshots you created — snapshots can persist (and have cost implications) after the instance itself is gone.
3. Review any additional storage allocated to the instance.
4. Confirm, by checking the RDS dashboard directly, that nothing training-related remains — the same "verify, don't assume" discipline Module 3 taught for EC2.

DynamoDB cleanup:

1. Delete any training DynamoDB tables you created that are no longer needed.
2. Confirm, by checking the DynamoDB dashboard directly, that no unnecessary training tables remain.