A county IT portal must show device inventory plus health views from two different Cisco controller families. How should the privileged API sessions be arranged?
Select an answer to reveal the explanation.
Short Explanation
Think of a single city service desk that calls other departments for you. One back-end facade talks to inventory and both controllers; the browser only talks to that desk. Platform credentials never leave the server, and the front-end keeps one origin.
Full Explanation
When a county portal must combine inventory and health from different Cisco controller families, privileged API sessions should terminate on one back-end facade. That facade holds credentials, fans out to each controller, normalizes responses, and presents a single origin to the browser. Clerks never see controller hostnames or keys, CORS and CSP stay simple, and policy can audit one hop instead of many.
Opening multiple privileged API clients from browser-origin JavaScript fails because secrets and controller reachability leak to the client and each hop becomes a separate attack and CORS surface. Embedding each controller's API key in a distinct front-end bundle fails for the same credential-exposure reason and makes key rotation a front-end release. Having the clerk's browser authenticate directly to every listed controller hostname fails operationally (firewall, cert, and IdP sprawl) and design-wise (the UI becomes a mesh of privileged clients).
Exam caveat: a facade can still call multiple platforms asynchronously; one origin does not mean one serial blocking hop to every controller before any UI paint.
Operational check: from the browser, verify only the municipal portal origin is called for health data, and that controller tokens exist only in server configuration or a secrets manager.