A water utility deploys leak-prediction services in containers. Which runtime control set best fits?
Select an answer to reveal the explanation.
Short Explanation
Give the leak predictor a sandbox, not the keys to the plant. Harden the containers and cap resources so a runaway job can’t own the host.
Full Explanation
Water-utility leak-prediction services in containers should run in hardened images with runtime resource limits that constrain CPU, memory, and privileges. Hardening removes unnecessary packages, applies security profiles, runs as non-root where feasible, and locks down host mounts so a compromised AI job cannot freely own plant hosts. Resource limits contain runaway inference or training jobs that could starve SCADA-adjacent or shared utility workloads. Together, these runtime controls reduce blast radius for containerized civic AI without blocking the prediction mission.
Privileged containers with no resource limits or hardening grant near-host power and unbounded consumption—unacceptable near industrial or utility environments. Root-by-default images shared across unrelated workloads enlarge lateral movement and privilege inheritance. Disabling security profiles so the model “can do anything on the host” deliberately removes the sandbox that containerization is meant to provide.
Exam caveat: containerization alone is not security; hardened configuration plus limits are the control. Utility AI near operational technology especially needs constrained runtimes.
Operational check: deploy leak predictors with non-privileged service accounts, enforced seccomp/AppArmor/SELinux profiles as applicable, CPU/memory quotas, read-only root filesystems where possible, and alerts on privilege-escalation or limit-breach attempts.