A citizen portal must stay reachable on the internet, but its backend storage should not be. How should endpoint types be chosen for those two pieces?
Select an answer to reveal the explanation.
Short Explanation
Front door for citizens can stay public; the storage vault behind it should go private. Match endpoint type to who should reach the service. Exposure need drives the choice.
Full Explanation
Endpoint choice should follow exposure needs rather than a one-size-fits-all rule. A citizen portal that must remain reachable on the internet appropriately uses a public endpoint backed by strong application security. Backend storage that should not be internet-reachable is a fit for a private endpoint inside the city’s VNet so only trusted application tiers talk to the data. Forcing both onto private endpoints would block citizens unless complex publishing patterns are added—contradicting the portal’s public requirement. Keeping both on public endpoints forgoes the protection private endpoints give backend storage holding sensitive records. Azure DNS and ExpressRoute are useful services, but they are not “endpoint types” that replace this public-versus-private decision for portal versus storage. Exam caveat: public portal plus private storage still needs the app tier to have a network path—VNet integration, private DNS, and NSGs—to the storage private endpoint, or the portal breaks after lockdown. Operational check: confirm the portal hostname resolves publicly and serves pages, while storage resolves privately inside the app subnet and rejects direct internet reads of backend containers.