isolation

Most candidates say 'rings' and stop. The interviewer is listening for who enforces the boundary, where the kernel must distrust its caller, and why one kernel bug undoes every process boundary at once.

Assume the parser will be exploited, then decide what the exploit gets. The scored design has a disposable worker with nothing worth stealing, no way out, and a narrow, validated return path.

Every platform that runs someone else's code (plugins, notebooks, AI agents, serverless) must pick a boundary. The right one depends on what the code may do and what a single bug in the boundary costs.

Validate tenant selection, enforce resource permissions, and test the boundaries that signed context and row-level security do not cover automatically. Follow one request through retrieval, caches and a queued job.

The question is really 'what does hostile code have to break to reach the host?' Answer that for each option and the choice follows.

Training jobs need privileged-looking things: device access, big volumes, fast networking. Hardening is about granting exactly those and nothing else.

Containers are a bundle of kernel features, each limiting a different thing. The scored answer explains what each restricts, what it does not, and how to combine them for an untrusted workload.

A customer model is customer code: loading it can execute anything, and serving it shares expensive hardware. The scored answer isolates execution, scans and constrains artefacts, and keeps tenants apart on GPUs and networks.

Most escapes are not clever kernel exploits. They are configuration that handed the container the host: a privileged flag, a mounted socket, a host path or a shared namespace.