A utility exposes AI endpoints for customer self-service. Which availability protection best fits?
Select an answer to reveal the explanation.
Short Explanation
Self-service AI can get stampeded. Put DDoS and rate-limit protections on those utility endpoints so one flood doesn’t knock out everyone.
Full Explanation
Utility customer self-service AI endpoints need DDoS and rate-limit protections to preserve availability for legitimate account holders. Public AI endpoints are attractive flood targets; without limits, volumetric or application-layer abuse can exhaust model capacity, gateway threads, or downstream billing/account APIs. Rate limits also bound cost blowouts from runaway clients. Availability is a security property for civic self-service: if the assistant is down, residents lose a supported channel for outages, billing questions, or service requests.
Unlimited anonymous request floods with no rate limiting invite trivial denial of service. Intentionally removing capacity planning because “AI is always idle” ignores peak events and attack traffic. Disabling availability monitoring to reduce alert noise blinds operators to outages until customers complain en masse.
Exam caveat: availability protections (DDoS/rate limits) are in-scope AI security architecture for customer-facing endpoints—not optional “network team only” concerns.
Operational check: place WAF/DDoS and per-identity rate limits in front of utility AI endpoints, load-test expected peaks, alert on saturation and error spikes, and verify anonymous flood traffic is shed while authenticated customer traffic continues within policy.