County integration tests must stay on an approved Lambda build while developers keep iterating on unpublished code. How should aliases be used?
Select an answer to reveal the explanation.
Short Explanation
Tape a sticker on the bottle that passed taste-test—leave the open flask for kitchen experiments. A test alias freezes the approved version while $LATEST stays messy. QA on $LATEST is tasting unfinished soup.
Full Explanation
County integration tests must stay on an approved Lambda build while developers keep iterating on unpublished code. Point integration tests at a test alias that is pinned to a published version, while developers continue publishing experiments to $LATEST. Aliases give municipal QA a stable target without freezing developer iteration, which is a core Lambda versioning skill on the Developer Associate exam and in day-to-day county release trains.
Running integration tests against $LATEST so every save on a laptop immediately becomes the QA target fails because QA then chases a moving binary mid-suite and flakes become inevitable. Deleting all aliases and invoking functions only by changing the console code editor in staging fails conceptually as click-ops without version discipline. Mapping the production alias to $LATEST so QA and prod always share the newest bytes fails by removing version pinning where blast radius is largest.
Exam caveat: updating the test alias should be an explicit pipeline step after the candidate version passes build gates—not an automatic follow of $LATEST on every publish. Operational check: publish a version, move the test alias to it, run integration tests against the alias ARN, and confirm developer publishes to $LATEST do not change alias results until the alias is moved again.