Three city departments want separate API path prefixes and policies but one shared public hostname. When is a second API Gateway unnecessary?
Select an answer to reveal the explanation.
Short Explanation
One reception building can host several department desks—multiple deployments on one gateway. Open a second gateway when public versus private front end or VCN attachment must differ.
Full Explanation
Multiple API deployments can share one API Gateway, each with its own path prefixes and policies, while presenting one shared public hostname to clients. Three city departments can therefore coexist on a single public gateway when they only need logical separation of deployments and routes. A second gateway becomes necessary when front-end type (public versus private) or VCN attachment must differ—not merely because path prefixes or department ownership differ.
Always creating one gateway per route path segment multiplies appliances, certificates, and operational overhead without benefit. Forcing each department onto a different region’s gateway solely for path isolation confuses geographic locality with HTTP routing. Claiming deployments cannot share a gateway contradicts the product model; specifications routinely host more than one deployment per gateway hostname.
Exam caveat: shared hostnames still need non-overlapping path design and careful deployment policies so one department’s authentication rules do not surprise another’s clients. Operational check: place three deployments on one public gateway with distinct path prefixes, verify each department’s routes and policies independently with test clients, and only provision another gateway if a private front end or a different VCN attachment is truly required.