A city open-data front end uses Amplify. Production should publish from the main branch only after QA validates a preview branch. Which Amplify practice supports that?
Select an answer to reveal the explanation.
Short Explanation
Amplify branches are dress rehearsals: preview branch for QA, main for the citizen-facing stage. Skipping previews and FTP-zipping prod is how open-data sites ship untested UI.
Full Explanation
City open-data front ends on AWS Amplify should use branch and channel deployments so QA can exercise a preview branch before production publishes from main. Amplify connects repository branches to hosted environments: feature or preview URLs validate content and client behavior, then main (or a release branch) promotes the citizen-facing production domain after that validation. That practice keeps broken open-data UI changes off the public hostname.
Forcing every commit on every branch straight to the production domain eliminates preview validation and maximizes citizen-visible breakage. Disabling branch deployments and uploading zip files through FTP fights Amplify's Git-based workflow and weakens provenance. Replacing Amplify with unsigned S3 website sync from laptops removes managed front-end CI and invites configuration drift.
Exam caveat: Amplify Hosting branch deployments are the Associate-level lever for preview-then-promote front ends; you need not redesign the entire city's CMS to answer correctly.
Operational check: connect the open-data repo, enable a preview branch for QA, confirm the preview URL serves the candidate build, require QA sign-off, then merge or promote so only main updates the production Amplify domain.