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
QA accidentally pointing integration tests at the production DynamoDB table through a wrong parameter shows why test environments must use isolated data stores and correct environment-specific configuration so tests never target production tables. Guardrails around parameter files, account boundaries, and naming conventions protect municipal citizen data from test writes, deletes, and scans. Isolation is not optional polish—it is a safety requirement.
Sharing the production DynamoDB table with QA to keep data perfectly realistic fails because realism is not worth production corruption or PII exposure. Allowing any parameter file to override table names without environment guards fails conceptually by making accidents easy. Granting CI roles unrestricted dynamodb:* on all tables including production fails by removing the last IAM backstop.
Exam caveat: similar table names across stages invite misconfiguration—prefer explicit ARNs, separate accounts, or pipeline-injected parameters over hand-edited files. Operational check: attempt a staging test run with a deliberately wrong prod table name in a safe drill account layout, confirm guards block it, and review CI role policies for production denials.