A municipal operations portal fans request traffic across several identical back-end workers that talk to Cisco controllers. What is the primary job of the load balancer in that design?
Select an answer to reveal the explanation.
Short Explanation
Picture a ticket window with several clerks behind it. The load balancer is the line manager who hands the next citizen to any free clerk—not the filing cabinet, the ID badge printer, or the backup vault. Its job is fan-out and hiding instance identity.
Full Explanation
In a municipal portal that fans work across identical Cisco-API workers, the load balancer's primary job is distribution and indirection. It spreads inbound HTTP across healthy, interchangeable back-end instances and hides which process handled each request so clerks and upstream callers do not pin to a single worker hostname. That enables horizontal scale-out and rolling replacement without rewriting the parking or ops UI.
Acting as the OAuth authorization server for Meraki and DNA Center fails the role model: token issuance is an identity concern, not L7 fan-out. Serving as a blanket HTTP cache for all controller JSON fails because caching is an optional performance layer with freshness and authorization rules; it is not what defines the balancer. Becoming the failover owner of a shared inventory database fails because database HA and load balancing are different planes—the balancer forwards application traffic, it does not assume storage primary duties.
Exam caveat: sticky sessions can make a balancer appear to work while quietly defeating interchangeable workers; prefer shared or client-held session state so true fan-out remains possible.
Operational check: send successive requests without affinity and verify different worker instance IDs appear in access logs or response headers while the civic UI still functions.