Business rules for grant scoring are tangled with AWS SDK calls inside one Lambda handler, making unit tests slow and brittle. What structural change helps?
Select an answer to reveal the explanation.
Short Explanation
Keep the brains of grant scoring in plain functions you can test on a laptop, and let the handler be the thin adapter that talks to AWS. Mixing SDK spaghetti into every rule makes unit tests cry.
Full Explanation
When business rules for grant scoring are tangled with AWS SDK calls inside one Lambda handler—making unit tests slow and brittle—separate the handler so it adapts events and AWS I/O while domain scoring logic stays pure and testable without AWS. Pure functions encode ordinance-driven scoring rubrics with plain data in and out; the handler translates DynamoDB items and API Gateway events at the edges. Municipal scoring changes then get fast unit tests on laptops without IAM, VPC, or sandbox contention.
Requiring every unit test to call live DynamoDB and STS in the shared production account couples correctness checks to cloud availability and endangers production. Dropping automated tests and validating scoring only after production deploys with real applications is reckless for funding decisions. Embedding scoring formulas only in CloudWatch alarm text is not an application architecture.
Exam caveat: “pure domain module” does not mean ignoring integration tests—still verify SDK wiring in non-prod. Avoid leaking AWS types deep into domain models. Feature flags can still live outside pure functions as inputs.
Operational check: extract scoring into a pure module with fixture-based unit tests; keep handler thin; mock AWS in handler tests; run integration tests in sandbox on merge; and ensure ordinance rubric changes are covered before promotion.