County IT reviews a proposed civic web app that calls a vendor LLM. Which finding is the clearest architecture anti-pattern?
Select an answer to reveal the explanation.
Short Explanation
If the vendor API key ships in the browser, every resident—and every scraper—owns your bill and your access. Caching responses in your browser local storage, doing redaction in your browser before the county gateway checks it, or loading a vendor widget with broad DOM access don't hand every viewer a shared key the way embedded keys do—you'll want to harden them, but they're not the clearest anti-pattern.
Full Explanation
When a civic web app calls a vendor LLM, secret handling is an architecture finding, not a frontend convenience. The clearest anti-pattern is embedding long-lived vendor API keys in browser-side JavaScript delivered to residents’ browsers: any user, scraper, or XSS path can extract the key, burn quota, impersonate the city to the vendor, and potentially access associated project data. Municipal LLM integration should keep credentials server-side behind a gateway with short-lived, rotated secrets.
Caching vendor LLM responses in browser local storage to support resident session continuity is not the clearest anti-pattern—it keeps only that resident's own responses on their device for convenience, and while it needs XSS and sensitivity review, it doesn't expose a shared vendor secret or quota to everyone. Performing resident prompt redaction in browser-side JavaScript before county gateway submission is not the clearest anti-pattern—it can reduce what leaves the device as a convenience, but because client controls are bypassable it must still be re-enforced at the gateway, and it doesn't directly leak credentials like embedded keys do. Loading a vendor chat widget via third-party script tag with broad resident DOM permissions is not the clearest anti-pattern for this question—it does raise supply-chain and DOM-access risk that should be sandboxed, but it doesn't automatically publish a long-lived vendor credential to every browser the way embedded keys do.
Exam caveat: Client-side long-lived vendor LLM keys in civic apps are a high-signal architecture anti-pattern; caching vendor LLM responses in browser local storage to support resident session continuity is not the expected alternative.
Operational check: Remove any browser-embedded vendor keys, avoid caching sensitive vendor LLM responses in browser local storage, don't trust browser-side redaction alone before county gateway submission, and avoid loading a vendor chat widget via third-party script with broad resident DOM permissions.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.