Two municipal developers work on separate feature branches for a parks reservation API. Both need to exercise SAM resources without overwriting the shared team development stack. What pattern should they use?
Select an answer to reveal the explanation.
Short Explanation
Shared kitchen, two chefs, one stove—somebody burns dinner. Spin up a short-lived SAM stack per branch so each feature can cook alone. Email turn-taking and forced merges just invite stomping.
Full Explanation
Two municipal developers on separate feature branches for a parks reservation API should deploy ephemeral, branch-scoped SAM stacks so each branch has an isolated temporary environment. Ephemeral stacks prevent overwriting the shared team development stack and let reservation features be exercised in parallel without change-set collisions. This is the Domain 3 pattern for isolated developer environments on infrastructure-as-code apps.
Taking turns deploying to the single shared stack and emailing the team before each change set fails because email locks do not scale and still serialize work. Only running sam local forever and never deploying either branch until production fails conceptually—many IAM, API, and DynamoDB behaviors need cloud deploys. Merging both branches first, then deploying once to the shared stack for all testing fails by forcing premature integration before branch validation.
Exam caveat: ephemeral stacks need lifecycle cleanup (TTL, pipeline teardown) or the county account fills with abandoned stacks and costs. Operational check: deploy a branch stack with a unique stack name prefix, run API checks, merge only after review, and delete the ephemeral stack automatically on branch delete.