For a grants intake stack, the team wants the Lambda function, API Gateway, and DynamoDB table versioned together. What should live in the application repository?
Select an answer to reveal the explanation.
Short Explanation
Code and the blueprint that stands it up should travel in the same suitcase. Park the SAM/CloudFormation template next to the app so grants releases promote function, API, and table as one versioned unit. Console folklore and wiki diagrams are not IaC.
Full Explanation
Including infrastructure-as-code templates with application source keeps releases coherent: the same commit describes runtime code and the AWS resources a grants intake stack needs. Keeping the SAM or CloudFormation template that defines the Lambda function, API Gateway, and DynamoDB table versioned alongside application code as one release unit is the Domain 3 practice for municipal stacks. Console-only provisioning drifts from production reality and complicates rollbacks when grant season pressure rises.
Maintaining infrastructure only as undocumented console clicks outside the repo fails because changes are not reviewable or reproducible. Storing production table names in a personal spreadsheet and omitting templates fails conceptually by scattering critical config outside version control. Defining the API in a wiki and recreating resources manually each release fails because wikis are not executable IaC and invite drift.
Exam caveat: templates must parameterize environment-specific names/secrets rather than hard-coding production values into the shared unit. Operational check: deploy the paired code+template commit to a test stack, confirm function, API, and table match the template, and ensure production changes flow through the same repository path.