[newaccountman2]

> Consider this scenario: 1. You have a critical DynamoDB table with a Lambda trigger handling important business logic 2. A developer pushes changes to the Lambda's `$LATEST` version for testing 3. Surprise! Those changes are now processing your production data

...why would a DynamoDB trigger for prod data be pointing to a Lambda where people push things that are still being tested?

> The workarounds are all suboptimal...- Maintain separate tables for different environments

This is not "suboptimal" or a "workaround"; it's the proper way to do things lol

Just as one would have separate RDS instances for QA/staging/test versus production.

Test Lambda --> Test DynamoDB table

Prod Lambda --> Prod DynamoDB table