A city library catalog must serve static documentation from a /docs virtual path and a REST API from the same App Service site. Which site-level configuration should the developer use instead of a second App Service plan?

The city library catalog needs static documentation under /docs and a REST API on the same App Service site without standing up a second plan. Path mappings and virtual applications (Windows) or equivalent Linux site path configuration let different content roots share one hostname and one app. Map /docs to the documentation content root while the API continues to serve from the primary site root (or another mapped path). Riders and librarians then use one municipal hostname with clean URL paths, and you avoid duplicating plans, certificates, and custom-domain bindings.

An Application Gateway URL path map that “owns” the documentation folder is infrastructure-layer routing in front of backends; it can split traffic across multiple backends but is not the App Service site-level path mapping skill and adds a gateway you do not need for same-site paths. A separate Free-tier web app that only hosts /docs static files creates a second hostname/plan boundary, splits TLS and domain management, and still does not teach same-site virtual path configuration. Azure Traffic Manager priority routing between two identical production apps is DNS-level failover across endpoints, not a way to mount /docs beside an API inside one site.

Exam caveat: virtual applications on Windows can run with separate application pools and physical paths—mis-mapping the physical path is a common reason /docs returns 404 while the API still works. Operational check: after saving path mappings, browse https://SITE_NAME.azurewebsites.net/docs and an API route on the same host, confirm both return expected content, and verify you did not create a second App Service plan solely for documentation.