A county's open-data chatbot has a public-facing endpoint and an internal knowledge-base backend, and the architecture must keep the two properly separated on the network. How should the county lay this out?
Select an answer to reveal the explanation.
Short Explanation
A public lobby and a back-office file room don't share a door for a reason. Putting the public endpoint in a public subnet and the internal backend in a private one, with traffic between them restricted, keeps that same separation on the network. Sharing a subnet erases the boundary you're trying to build.
Full Explanation
Separating the public-facing endpoint into a public subnet and the internal knowledge-base backend into a private subnet, with traffic between the two explicitly restricted, mirrors the trust boundary the county needs: the backend is never directly reachable from outside, and only the specific traffic path from the public component is permitted through. Placing both components in the same public subnet erases that boundary — anything that can reach the public endpoint could potentially reach the backend on the same network segment as well. Placing both in a private subnet and exposing the whole subnet through one public route reopens the same problem from a different angle: the entire subnet, backend included, ends up reachable through that shared route. Putting the internal backend itself in a public subnet inverts the intended architecture, exposing the component that's supposed to stay internal. Scope caveat: subnet placement alone doesn't restrict traffic between the two tiers — pair it with security groups or network ACLs that permit only the specific expected traffic pattern between the public and private subnets. Operational check: attempt to reach the internal backend directly from outside the VPC and confirm the request fails, rather than only confirming the public endpoint responds correctly.