Pick the Right Isolation Lab
“Just put it in a container” is a security decision, and often the wrong one. Given a workload and a threat model, you choose between a plain container, gVisor, Kata, a Firecracker microVM, or a full VM — weighing isolation strength against overhead. The strongest boundary is not always right, and a shared kernel is not always wrong. Match the boundary to the threat.
The real job. More noise, a tighter clock.
Match the boundary to the threat
Each round gives you a workload and a threat model. Pick the isolation primitive that fits — plain container, gVisor, Kata, Firecracker microVM, or a full VM — and then the reason it fits. Strongest is not always right: over-isolating trusted code costs density and latency for nothing. Score 3 per round (2 for the primitive, with partial credit for a defensible alternative, 1 for the rationale).
What this lab is
- A free, browser-based lab on choosing the right isolation for a workload: plain container, gVisor, Kata Containers, Firecracker microVM, or a full VM.
- Each round pairs a workload with a threat model — untrusted tenant code, a CI runner for forked PRs, an internal batch job, a legacy Windows app — and you pick the primitive and the reason it fits.
- You are scored on matching isolation strength to the actual threat, with partial credit for a defensible alternative: over-isolating trusted code (a VM per service) is a real waste of density and latency.
- It teaches the design facts that decide the call: shared-kernel containers vs. a hardware boundary, gVisor's syscall overhead and compatibility gaps, Firecracker's ms boot at serverless density, and when only a full VM will do.
- Fully client-side — no uploads, no account, nothing sent anywhere; after each round you see why the best choice is best.
Frequently asked questions
What is the Pick the Right Isolation Lab?
A free, in-browser decision drill. Each round describes a workload and its threat model, and you choose among five isolation primitives — a plain container (shared host kernel), gVisor (a user-space kernel that intercepts syscalls), Kata Containers (an OCI container inside a lightweight VM), a Firecracker microVM (a minimal KVM VM with ms boot), or a full VM — and then pick the rationale. You get immediate feedback and a graded debrief.
Firecracker vs gVisor vs Kata — how do I choose?
They trade isolation strength against overhead and compatibility. gVisor runs a user-space kernel that intercepts syscalls, shrinking the host-kernel attack surface without a VM, but it taxes syscall- and I/O-heavy workloads and does not implement every syscall. Kata and Firecracker both give a real hardware (VT-x/AMD-V) boundary: Firecracker is tuned for multi-tenant serverless density and millisecond boot, while Kata keeps full OCI/Kubernetes-native behaviour and a complete guest kernel. The lab makes you apply these trade-offs to concrete scenarios rather than memorise them.
When is a plain container actually fine?
When the code is trusted and first-party. A container shares the host kernel, so a kernel exploit escapes it — which matters enormously for untrusted code and not at all when there is no hostile party on the box. For internal, trusted, latency-critical services, a shared-kernel container is the right trade; wrapping it in a VM spends density and latency on a threat that is not present. Matching isolation to the real threat, rather than reaching for the strongest option, is exactly what the lab scores.
Does it run any sandboxes or need an install?
No. Nothing is executed, uploaded or installed. The scenarios and the properties of each primitive are authored from established design facts, and the lab runs entirely in your browser with no account. It is a judgement drill for architects and platform engineers, not a benchmark.