A developer's unit-test suite creates real SNS topics in the production account during CI because mocks were skipped. What is the correct testing practice?
Select an answer to reveal the explanation.
Short Explanation
Unit tests should be a dress rehearsal with stand-ins, not a live show on the production stage. Mock SNS in unit tests; save real AWS calls for a controlled integration account. Admin rights in prod CI and "just click after deploy" make the blast radius bigger, not safer.
Full Explanation
When a developer’s unit-test suite creates real SNS topics in the production account during CI because mocks were skipped, the correct practice is to keep unit tests hermetic with mocks and reserve real AWS calls for controlled integration environments. Unit tests assert handler logic with fake publishers; they must not mutate production or incur surprise cost. Hermetic CI is deterministic and safe for municipal pipelines that share accounts carefully across teams.
Keeping unit tests pointed at production so failures “match live behavior exactly” endangers live citizen workloads and shared quotas. Granting CI AdministratorAccess so topic creation always succeeds in production amplifies blast radius when a bad test runs. Disabling all automated tests and relying only on manual clicks after deploy abandons regression safety.
Exam caveat: local emulators (or moto-style mocks) can support unit scope; integration tests still belong in isolated non-prod accounts with teardown. Never use production as a convenient test double. CI roles should be denied production write APIs they do not need.
Operational check: mock SNS in unit tests; run integration tests in a sandbox that creates/deletes disposable topics; block CI roles from production CreateTopic via SCP or IAM; and scan test code for real AWS endpoints before merge.