Cyber Security Quiz: Container Security And Isolation
10 questions · exam conditions
0:00
Container Security And IsolationQuestion 1 of 10

A process runs as UID 0 inside a container. User namespaces are enabled, and container UID 0 is mapped to unprivileged host UID 100000. The container is not privileged and has no sensitive host directories mounted into it.

What is the best interpretation of the process's authority?

It has unrestricted host-root authority because UID 0 has the same meaning across every namespace.
It has no administrative authority inside the container because UID mappings disable all root-related operations.
It has virtual-machine-level isolation because assigning a different host UID creates a separate guest kernel.
It can act as root within its namespace, but it does not automatically possess host UID 0 authority.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Container Security And Isolation

Practice Container Security And Isolation in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Container Security And Isolation, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A process runs as UID 0 inside a container. User namespaces are enabled, and container UID 0 is mapped to unprivileged host UID 100000. The container is not privileged and has no sensitive host directories mounted into it.

What is the best interpretation of the process's authority?

  1. It has unrestricted host-root authority because UID 0 has the same meaning across every namespace.
  2. It has no administrative authority inside the container because UID mappings disable all root-related operations.
  3. It has virtual-machine-level isolation because assigning a different host UID creates a separate guest kernel.
  4. It can act as root within its namespace, but it does not automatically possess host UID 0 authority. (correct answer)
Explanation: When you see a question about container security and UID mappings, you should immediately think about the distinction between namespace-local identity and host-level identity — these are not the same thing, and confusing them is the core trap this question is testing. User namespaces in Linux allow a process to appear as UID 0 (root) inside a container while being mapped to an unprivileged UID on the host — in this case, UID 100000. That mapping is the key. Inside the container, the process genuinely holds root-like privileges: it can manage files, configure networking within the namespace, and perform operations that require elevated permissions within that namespace's scope. However, if that process somehow escapes the container, it lands on the host as UID 100000, an ordinary unprivileged user — not host root. This makes D the correct interpretation: root authority is real but namespace-scoped, not host-global. Choice A is dangerously wrong — it reflects the pre-namespace mental model where UID 0 was universally privileged. User namespaces were specifically designed to break that assumption. Choice B overcorrects in the opposite direction: UID mapping does not strip all administrative capability; the process still has meaningful root-equivalent power inside the container. Choice C introduces a fundamental misunderstanding — user namespaces do not create a separate kernel or anything resembling VM-level isolation; the container still shares the host kernel. As a study tip, remember this framing: namespaces scope identity, not eliminate it. On security exams, questions about containers often test whether you understand that "root inside a container" and "root on the host" are meaningfully different claims when user namespaces are properly configured.

Question 2

A web server in a container has its own IP address and cannot see the host's physical network interfaces from inside its network namespace. The runtime publishes the container's TCP port 443 on the host's TCP port 8443.

Which statement best explains the security effect of this configuration?

  1. The separate IP address proves that the container has an independent kernel network stack equivalent to a VM.
  2. The published port encrypts traffic between the host and container, preventing interception by other local processes.
  3. The network namespace isolates the container's network view, while port publication creates a controlled path into that view. (correct answer)
  4. The port mapping places the container in the host network namespace, eliminating all remaining network separation.
Explanation: When you see a question about container networking, anchor your thinking around two distinct mechanisms: isolation (what the container can and cannot see) and controlled access (what paths are deliberately opened into that isolated environment). These concepts work together but are not the same thing. A network namespace is a Linux kernel feature that gives a container its own private view of networking — its own interfaces, routing tables, and IP address. Critically, this is a kernel-level isolation primitive, not a separate kernel itself. Port publication (or "port mapping") then acts as a deliberate pinhole: the container runtime forwards traffic arriving on the host's port 8443 to the container's port 443, creating a controlled, intentional entry point. Answer C captures exactly this two-part reality — namespace isolation plus selective, managed access through publication. Answer A is tempting but wrong. A separate IP address does not mean a separate kernel. Containers share the host kernel; VMs do not. This is one of the most important distinctions in container security, and conflating them reflects a fundamental misconception. Answer B introduces a fictional capability. Port publication (NAT/forwarding) performs no encryption whatsoever — it simply redirects packets. Traffic interception by local processes remains a real concern unless TLS is configured at the application layer. Answer D describes the opposite of what happens. Placing a container in the host network namespace (via --network=host) would eliminate separation, but port publishing preserves the namespace boundary while adding a forwarding rule — it does not collapse it. Remember this pattern: isolation and access controls are complementary, not mutually exclusive. Watch for distractors that conflate them or invent capabilities (like automatic encryption) that the described mechanism does not provide.

Question 3

A host administrator can see container processes in the host's process listing. Inside the container, however, an application sees only the processes assigned to its PID namespace. The application owner argues that the host's visibility proves PID isolation has failed.

Which response best evaluates the application owner's argument?

  1. The argument is correct because effective process isolation requires the host and container to have mutually invisible process lists.
  2. The argument is incorrect because a containing PID namespace can see descendant processes while the child view remains restricted. (correct answer)
  3. The argument is correct because a host-visible process must be executing outside the container's resource controls.
  4. The argument is incorrect because host-side visibility is a symptom of control-group accounting, not a sign that PID namespace restrictions have been bypassed.
Explanation: When studying Linux container security, you need to understand that PID namespaces are hierarchical, not mutually exclusive. The host kernel maintains a global view of all processes, including those inside containers, precisely because containers are built on top of the host kernel — they share it. Isolation means restricting what the container sees inward, not hiding processes from the privileged host outward. This is why B is correct. A parent PID namespace can always observe processes in child namespaces — that's by design. The container's application, however, only sees the PIDs within its own namespace, which may start at PID 1. Both behaviors coexisting is the intended, working state of PID namespace isolation. The host's visibility is a feature of the parent-child namespace hierarchy, not evidence of a breach. A is wrong because it misdefines isolation. "Mutual invisibility" would actually break legitimate host administration, monitoring, and security tooling. Isolation was never intended to blind the host. C is wrong because host visibility of a process says nothing about whether that process is inside or outside resource controls — cgroups and namespaces are orthogonal mechanisms that can both apply simultaneously. D is tempting but misleading: host-side process visibility is a namespace property, not a cgroup accounting artifact. Mixing up these two subsystems (namespaces vs. cgroups) is a classic distractor. As a study tip, always distinguish between namespaces (what a process can see) and cgroups (what resources it can use) — exam questions frequently conflate them to test whether you know they are separate kernel mechanisms.

Question 4

Two teams run identical containers. Team 1 permits the containers broad Linux capabilities and unrestricted system calls. Team 2 drops unnecessary capabilities, applies a seccomp allowlist, and enforces a mandatory access-control policy. Both teams use the same host kernel.

Which comparison between the two deployments is most accurate?

  1. Team 2 has reduced the paths available to an attacker, but its containers still depend on the security of a shared host kernel. (correct answer)
  2. Team 2 has created separate guest kernels because seccomp assigns an independent system-call implementation to each container.
  3. Team 1 has stronger isolation because broad capabilities prevent applications from attempting unauthorized kernel operations.
  4. Both deployments have identical risk because controls applied above a shared kernel cannot affect container security.
Explanation: When evaluating container security, you need to think in two layers: the controls applied within the container boundary, and the shared infrastructure those containers ultimately depend on. These layers are independent — hardening one doesn't eliminate the other. Team 2's approach is genuinely stronger. Dropping Linux capabilities removes privileges a compromised process could abuse (like CAP_NET_ADMIN or CAP_SYS_PTRACE). A seccomp allowlist restricts which system calls the container can invoke, shrinking the kernel's attack surface dramatically. A mandatory access-control policy (like AppArmor or SELinux) adds a third enforcement layer. Together, these controls mean an attacker who compromises a container faces far fewer paths to escalate privileges or pivot. That's exactly what answer A captures — meaningful risk reduction, while honestly acknowledging that all these containers still share one host kernel. If a zero-day exists in that kernel, both teams are exposed. Answer B is wrong because seccomp does not create separate kernels. It filters which system calls a process may invoke against the same kernel — there is no independent system-call implementation per container. Containers are not virtual machines. Answer C inverts the logic entirely. Broad capabilities don't prevent unauthorized operations; they expand what a process is permitted to do, giving an attacker more tools if they gain code execution. Answer D is a classic nihilism trap. Controls above a shared kernel absolutely affect security posture — they reduce attack surface, limit blast radius, and slow or stop privilege escalation. Shared infrastructure creates a ceiling on isolation, not a floor. Remember: on questions about container hardening, always ask "what does this control reduce?" and "what residual risk remains?" Both matter.

Question 5

A container runs as a non-root user with a read-only root filesystem and limited Linux capabilities. For deployment convenience, the administrator mounts the socket of a rootful host container daemon into the container. The daemon accepts commands from any client that can access the socket.

Which conclusion best describes the resulting isolation?

  1. Isolation remains strong because the container's process lacks UID 0 and cannot modify its own root filesystem.
  2. Isolation is substantially weakened because the process can direct the daemon to create privileged workloads or host mounts. (correct answer)
  3. Isolation becomes equivalent to a virtual machine because the daemon socket replaces direct access to host system calls.
  4. Isolation is affected only for networking because container daemon sockets control port publication but not host resources.
Explanation: When evaluating container isolation, you need to look beyond the container's own restrictions and ask what privileged pathways remain accessible from inside it. Individual hardening measures — non-root UID, read-only filesystem, dropped capabilities — only limit what the container process can do directly. They say nothing about what it can do indirectly through a privileged service it can reach. That's the core issue here. A rootful container daemon (like Docker or Podman in root mode) runs on the host with elevated privileges and takes instructions over its socket. If that socket is mounted into the container, the container process becomes a client that can issue commands to the daemon — commands like "start a new container with --privileged, mount /etc from the host, or bind the host's root filesystem as a volume." The daemon faithfully executes those instructions using its own host-level privileges. The container's own restrictions become irrelevant because the attack path bypasses them entirely. B is correct for this reason. A is wrong because it commits exactly the trap described above — assuming that UID restrictions and a read-only filesystem are sufficient. They restrict direct actions, not indirect ones through a privileged intermediary. C is wrong because daemon socket access doesn't create VM-like isolation — it destroys container isolation. VMs provide stronger separation through hardware-level virtualization, not weaker. D is wrong because container daemon sockets control far more than networking. They govern filesystem mounts, privilege levels, process namespaces, and direct host resource access. As a study habit, whenever you see a scenario mixing hardened containers with mounted privileged sockets or APIs, treat the socket as a privilege escalation vector regardless of the container's own restrictions.

Question 6

An administrator launches two containers from different Linux distribution images on the same host. The containers have different package managers and system libraries, but both report the same kernel release when the administrator runs uname -r.

Which explanation best accounts for these observations?

  1. Each image contains a private kernel, but the runtime synchronizes its reported version with the host.
  2. Each image supplies its own user-space environment, while both containers use the kernel running on the host. (correct answer)
  3. The containers share a user-space environment, while namespaces present different package managers to each container.
  4. The containers use separate guest kernels, but the hypervisor assigns the same release identifier to both kernels.
Explanation: Whenever you see a question about containers versus virtual machines, anchor yourself to one core architectural distinction: containers share the host's kernel, while VMs run their own guest kernels. A Linux container is essentially a set of isolated processes running on the host machine. The isolation comes from kernel features — namespaces and cgroups — that restrict what each container can see and use. Crucially, the kernel itself is not duplicated. This is exactly why both containers report the same uname -r output: they're literally querying the same running kernel. What does differ between them is the user-space layer — the libraries, package managers, and utilities bundled inside each image. One image might carry apt (Debian-based), another might carry dnf (RHEL-based), yet both sit atop the identical host kernel. That's precisely what B describes, making it correct. A is wrong because containers don't contain private kernels at all — the premise is false. The runtime doesn't "synchronize" kernel versions; there's simply one kernel shared by all. C gets the relationship backwards. Containers differ in user-space (that's the whole point of distinct images) and share the kernel — not the other way around. Namespaces isolate process views, not package managers. D describes a hypervisor/VM scenario, not containers. Separate guest kernels and hypervisor assignment are VM concepts. Containers don't use hypervisors or guest kernels. As a study tip, remember this mantra: containers share the kernel, VMs share the hardware. Exam questions often try to blur this line by mixing VM vocabulary into container scenarios — spotting that swap is the key to avoiding the trap.

Question 7

A development team builds an application as a Linux container image. The team then attempts to run the image directly on a host that provides only a Windows kernel and no Linux compatibility layer or Linux virtual machine.

Why is the image unlikely to run successfully in this environment?

  1. Container images depend on compatible host-kernel services because they do not normally carry and boot a complete guest kernel. (correct answer)
  2. Container registries encrypt Linux system libraries with keys that can be generated only by a Linux host kernel.
  3. Control groups require the application and host to use identical user-space distributions and package managers.
  4. Network namespaces prevent a container image built on one operating system from being downloaded by another operating system.
Explanation: When you see a question about containers failing to run across operating systems, the core concept being tested is how containers differ from virtual machines. Unlike VMs, containers do not bundle a complete guest kernel — they share the host's kernel directly. This is the fundamental architectural fact that unlocks the whole question. Because a Linux container image relies on Linux kernel interfaces (system calls, kernel modules, cgroups, namespaces — all Linux-specific), running it on a host that exposes only a Windows kernel means those required services simply aren't there. The container image assumes it can reach out to a Linux kernel underneath it, and when it can't, execution fails. This is exactly what A describes: container images depend on compatible host-kernel services because they don't carry their own guest kernel. B is false because container registries do not encrypt system libraries with OS-specific keys. Registries store and distribute images using standard cryptographic methods unrelated to which kernel downloads them — this answer invents a mechanism that doesn't exist. C confuses what control groups (cgroups) actually do. Cgroups are a Linux kernel feature for resource limiting and isolation; they have nothing to do with requiring matching user-space distributions or package managers between host and container. D misrepresents network namespaces, which are a kernel-level isolation mechanism for networking within a running system. They have no role in controlling which OS can pull an image from a registry. As a study tip, remember the one-liner: containers share the kernel, VMs bring their own. Any exam question about cross-OS container compatibility almost certainly hinges on this distinction.

Question 8

A company operates an untrusted document-processing service in a container. A newly discovered vulnerability allows a process to execute arbitrary code in the Linux kernel. The company is deciding whether to keep the service in a container or place it in a dedicated virtual machine.

Which risk comparison is most accurate, assuming default container isolation and a correctly configured hypervisor?

  1. A container limits the exploit to its image because kernel code is copied into each container at startup.
  2. A virtual machine is equally exposed because guest and host operating systems necessarily execute the same kernel.
  3. A container may expose the host and sibling containers, while a guest-kernel compromise is normally bounded by the hypervisor. (correct answer)
  4. A virtual machine removes the risk because code running inside a guest cannot exploit any kernel vulnerability.
Explanation: When comparing container and VM isolation, the core question is: what does a kernel vulnerability actually cross? Containers share the host's Linux kernel — every container on the same host calls into the same kernel code. A VM, by contrast, runs its own guest kernel, separated from the host by a hypervisor that enforces a hardware-level privilege boundary. This makes C the most accurate comparison. If an attacker exploits a kernel vulnerability from within a container, they've compromised the kernel that every other container and the host itself relies on — the blast radius is the entire host. In a VM, a kernel exploit compromises only the guest kernel. A correctly configured hypervisor (using hardware virtualization extensions like Intel VT-x) keeps guest kernel execution isolated, so the damage is normally bounded within that VM. A is wrong because Linux kernels are not copied into each container at startup — containers share a single kernel instance. This is a fundamental misunderstanding of how containerization works versus full virtualization. B is wrong because guest and host operating systems do not execute the same kernel. VMs run independent guest kernels; that separation is precisely what makes VM isolation stronger against kernel-level exploits. D is wrong because VMs don't remove the risk entirely — they reduce and bound it. A sufficiently severe vulnerability or a misconfigured hypervisor could still allow a VM escape. The word "removes" is an absolute claim that doesn't hold up. For the exam, remember: containers = shared kernel = wider blast radius; VMs = isolated guest kernel + hypervisor boundary = contained blast radius. Anytime you see kernel-level threats, think about what the isolation boundary actually separates.

Question 9

A cloud tenant runs several containers inside one virtual machine. An attacker in one container exploits the kernel used by those containers and gains control of that kernel. No hypervisor vulnerability is involved.

What is the most likely scope of the compromise?

  1. Only the attacking container is affected because each container has a private copy of the virtual machine's kernel.
  2. The physical host is necessarily compromised because a guest-kernel exploit automatically crosses the hypervisor boundary.
  3. Only sibling containers are affected because the guest operating system itself remains isolated from its own kernel.
  4. The guest VM and its sibling containers may be compromised, while the physical host retains the hypervisor boundary. (correct answer)
Explanation: When analyzing container and virtualization security questions, you need to think in layers: containers share a kernel, VMs are isolated by a hypervisor, and physical hosts sit beneath both. Understanding which boundary was breached tells you exactly how far the damage can spread. Here, the attacker compromises the guest VM's kernel — the shared OS kernel that all sibling containers depend on. Since containers don't have their own isolated kernels (they share the host OS kernel of that VM), owning the kernel means owning everything running on top of it. That makes D correct: all sibling containers within that guest VM are exposed, and the VM itself is fully compromised. However, because the attack targeted only the guest kernel and no hypervisor vulnerability was involved, the hypervisor boundary holds, protecting the physical host and other tenant VMs. A reflects a fundamental misconception — containers do not get private kernel copies. Kernel sharing is literally what defines and distinguishes containers from VMs. B gets the direction of escalation wrong; compromising a guest kernel doesn't automatically cross the hypervisor boundary. That would require a separate hypervisor exploit (a VM escape), which the question explicitly rules out. C is internally contradictory — you cannot say "the guest OS remains isolated from its own kernel." The guest OS is the kernel; they aren't separate entities that can be isolated from each other. A useful mental model: think of containers as rooms in a house (the VM), and the hypervisor as the property boundary. Breaking into the house's foundation (kernel) gives you all the rooms, but you're still inside the fence.

Question 10

A platform team configures PID, mount, and network namespaces for every container. It also uses control groups to limit each container to a fixed amount of memory and CPU time. The team claims these settings provide the same security boundary as running each workload in a separate virtual machine.

Which assessment of the team's claim is most accurate?

  1. The claim is incomplete because namespaces and control groups constrain views and resources but do not provide separate kernels. (correct answer)
  2. The claim is correct because a memory control group prevents processes from invoking kernel functions outside the group.
  3. The claim is correct because a PID namespace creates a private kernel scheduler for each container.
  4. The claim is incomplete only because containers require different image formats before they can equal virtual machines.
Explanation: When comparing containers to virtual machines, the critical question is: where does isolation actually occur? Virtual machines each run their own kernel on top of a hypervisor, meaning a vulnerability in one guest's kernel doesn't automatically compromise another. Containers, by contrast, share the host kernel — and that shared boundary is the fundamental security distinction. This makes A the correct assessment. Linux namespaces (PID, mount, network) control what a process sees — its process tree, filesystem, network stack — while control groups limit resource consumption. Neither mechanism provides a separate kernel. A malicious or buggy container process can still make system calls directly to the shared host kernel, potentially exploiting kernel vulnerabilities that affect all containers on that host. A VM's guest kernel acts as an additional layer, so a kernel exploit in one VM typically stays contained there. B is wrong because memory control groups only cap how much memory a container can use — they have no mechanism to filter or block which kernel functions (syscalls) a process can invoke. That's the job of tools like seccomp. C is wrong because a PID namespace creates an isolated view of process IDs, not a private kernel scheduler. The host kernel's scheduler still manages all container processes; they simply appear with different PIDs inside the namespace. D is wrong because image format (OCI, Docker, etc.) is a packaging concern, not a security boundary concern. Switching image formats wouldn't close the shared-kernel gap. Study tip: On security exams, always ask "what kernel is running?" — containers share one; VMs don't. That single fact resolves most container-vs-VM isolation questions.