A static park-map front end should give stakeholders a preview URL per Git branch. Which Amplify-oriented artifact approach fits?
Select an answer to reveal the explanation.
Short Explanation
Stakeholders need a link, not a merge lottery. Amplify branch builds turn each Git branch into its own hosted front-end artifact for park-map previews. Laptop tunnels and HTML-in-email are not environment-scoped releases.
Full Explanation
Amplify Hosting branch builds give stakeholders a preview URL per Git branch by producing an environment-scoped front-end artifact for each branch. For a static park-map front end, that Amplify-oriented approach isolates experimental map UI for municipal stakeholders without merging unfinished cartography work to main first. Preview environments are the artifact pattern that matches branch-based civic UX review and keeps experimental layers off the public production site.
Merging every experimental branch to main before any preview can exist fails because it forces incomplete work onto the integration branch merely to be seen by stakeholders. Hosting each developer's laptop over ngrok as the official stakeholder environment fails conceptually—laptops are not durable, access-controlled municipal preview hosts and vanish when the laptop sleeps. Publishing park maps only as email attachments of raw HTML files fails as a non-interactive, non-representative delivery method for map UX.
Exam caveat: preview apps still need non-production API endpoints and synthetic data so stakeholders do not mutate live park reservations while clicking around. Operational check: push a feature branch, open the Amplify preview URL, confirm it reflects branch commits within the expected build time, and tear down or auto-expire previews after review.