A parks Lambda team wants fast unit tests on laptops before any cloud deploy, mocking AWS calls rather than hitting real DynamoDB. Which practice matches that goal?
Select an answer to reveal the explanation.
Short Explanation
Unit tests should run on the laptop like a dress rehearsal with stand-ins — mock DynamoDB, do not book the real stage yet. SAM-friendly local unit tests catch bugs before deploy. Save live AWS calls for later integration checks.
Full Explanation
A parks Lambda team that wants fast unit tests on laptops before any cloud deploy should write and run unit tests in the SAM/dev environment with mocked AWS clients before deploying. Mocks keep tests hermetic, free, and fast: DynamoDB access becomes an in-memory fake, handlers are asserted on inputs/outputs, and developers get feedback before sandbox charges or shared-account contention. That practice matches how municipal teams protect limited cloud budgets while still catching logic defects early.
Running only post-deploy integration tests against shared production endangers live citizens and is too slow for a tight unit-test loop. Skipping tests locally and relying on Amazon Q Developer without review abdicates correctness ownership. Requiring every test to open real DynamoDB tables and charge the sandbox on each keystroke conflates unit tests with integration tests and slows the inner loop.
Exam caveat: mocked unit tests do not replace contract or integration tests against real AWS in a controlled non-prod account. Q Developer may draft tests, but humans still review assertions and secret handling.
Operational check: structure handlers so domain logic is pure and AWS I/O is at the edges; use mocked SDK clients in CI; run a smaller suite of integration tests in a sandbox on merge; and block production deploys on failing unit tests.