QA accidentally pointed integration tests at the production DynamoDB table name through a wrong parameter. What must test environments ensure?
Select an answer to reveal the explanation.
Short Explanation
Test traffic and production tables should never share a last name on the jersey. Isolate DynamoDB (and config) per environment so a wrong parameter cannot wipe civic data. "Realistic" shared prod tables are an outage waiting to happen.
Full Explanation
Non-production testing requires isolated data stores and carefully scoped configuration parameters. Pointing integration tests at production DynamoDB—whether by mistake or by design—risks data corruption and downtime for municipal workloads. Environment guards, separate tables, and least-privilege CI roles enforce that isolation; shared prod tables and wildcard data-plane permissions do not.