A school-district Kubernetes cluster colocates student GenAI tutoring apps with unrelated finance workloads on shared nodes. What isolation concern should platform security raise?
Select an answer to reveal the explanation.
Short Explanation
Student GenAI next to finance on the same nodes is like homework and payroll sharing one unlocked locker. Isolate those tenants. Shared GPU folklore, automatic law compliance from colocation, and ditching network policies are wishful thinking.
Full Explanation
A school-district Kubernetes cluster that colocates student GenAI tutoring with unrelated finance workloads on shared nodes raises tenant and workload isolation concerns: noisy neighbor effects, shared kernel/GPU attack surface, and accidental cross-access paths between student-related GenAI and financial systems. Platform security should flag insufficient workload isolation between sensitive GenAI tenants and other civic systems, and push for node pools, namespaces with strong network policies, or stronger separation aligned to data sensitivity.
Finance pods will not learn math better by sharing GPU cache with tutors—that is folklore, not an isolation control. Colocation does not automatically satisfy student-data minimization laws; legal compliance depends on purpose limitation, access control, and data handling, not shared scheduling. Shared nodes do not eliminate the need for network policies; they increase the importance of east-west controls.
Exam caveat: isolation can be graduated (soft multi-tenancy vs dedicated pools); the failure mode is treating colocation as free of isolation risk for student GenAI. Operational check: identify node membership for tutoring versus finance, review network policies and RBAC across namespaces, and confirm GPU/device plugins do not create unintended cross-tenant access.