On the same API deployment, /health should allow anonymous clients while /admin must require a specific access scope after authentication. How is that modeled?
Select an answer to reveal the explanation.
Short Explanation
After the front door checks ID, each hallway sets its own visitor rules—anonymous for /health, a required scope for /admin. Authorization is per route, not a second gateway.
Full Explanation
After deployment-level authentication is configured, per-route authorization decides what each path allows. On the same API deployment, /health can use ANONYMOUS (or equivalent anonymous-allowed authorization) while /admin requires AUTHENTICATION_ONLY or ANY_OF scopes for a specific access scope. That models mixed public probes and privileged administration without splitting appliances.
Deploying a second API Gateway solely for /health anonymous traffic is unnecessary overhead when route authorization can differ. Authorization is not locked to one deployment-wide scope list that every route must share. Disabling authentication on the deployment and relying on Object Storage ACLs per path abandons gateway security for an unrelated data-plane control.
Exam caveat: anonymous routes still sit behind the deployment’s authentication policy framework—configure the deployment to allow anonymous where intended, then explicitly mark routes. Operational check: set deployment authentication, mark /health as anonymous-authorized, require the admin scope on /admin, call both paths with and without tokens, and confirm /health succeeds anonymously while /admin rejects missing or insufficient scopes.