- A developer packages an app with its libraries and settings into a read-only template used to start many identical containers. What is this?
Answer: A container image
A container image bundles the app, its libraries and settings into a read-only template for starting containers. A VM snapshot is tempting, but it includes a whole guest operating system and kernel.
- Which explanation best accounts for these observations?
Answer: Each image supplies its own user-space environment, while both containers use the kernel running on the host.
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.
- A containerized web app runs as root with full Linux capabilities. Which change best limits harm if the app is compromised?
Answer: Run as non-root and drop unneeded capabilities
Running as a non-root user with minimal capabilities applies least privilege, limiting an attacker's options. Privileged mode may seem to fix permission errors, but it gives the container broad access to the host.
- Which comparison between the two deployments is most accurate?
Answer: Team 2 has reduced the paths available to an attacker, but its containers still depend on the security of a shared host kernel.
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.
- Which statement best explains the security effect of this configuration?
Answer: The network namespace isolates the container's network view, while port publication creates a controlled path into that view.
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.
- Which response best evaluates the application owner's argument?
Answer: The argument is incorrect because a containing PID namespace can see descendant processes while the child view remains restricted.
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.
- Which risk comparison is most accurate, assuming default container isolation and a correctly configured hypervisor?
Answer: A container may expose the host and sibling containers, while a guest-kernel compromise is normally bounded by the hypervisor.
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.
- Which conclusion best describes the resulting isolation?
Answer: Isolation is substantially weakened because the process can direct the daemon to create privileged workloads or host mounts.
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.
- A process in one container exploits a bug in the host's kernel, then reads files belonging to other containers on that host. What is this?
Answer: Container escape via the shared kernel
Containers share the host kernel, so a kernel flaw can let a process break out and reach the host and other containers. Escalation inside one container is tempting, but the attacker went beyond that container.
- What is the best interpretation of the process's authority?
Answer: It can act as root within its namespace, but it does not automatically possess host UID 0 authority.
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.
- Which assessment of the team's claim is most accurate?
Answer: The claim is incomplete because namespaces and control groups constrain views and resources but do not provide separate kernels.
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.
- Why is the image unlikely to run successfully in this environment?
Answer: Container images depend on compatible host-kernel services because they do not normally carry and boot a complete guest kernel.
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.
- Inside a container,
ps lists only the app's own processes and only its own network interfaces appear. Which kernel feature causes this? Answer: Namespaces
Namespaces partition what a process can see, such as process IDs and network interfaces. Cgroups are tempting because they also isolate, but they only limit how much CPU and memory a container can use.
- What is the most likely scope of the compromise?
Answer: The guest VM and its sibling containers may be compromised, while the physical host retains the hypervisor boundary.
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.
- A team runs a public image from an unknown publisher. It works, but the publisher had hidden code that sends app credentials out. What is this?
Answer: Software supply chain compromise
The threat came from the image source itself, which makes it a supply chain compromise. A man-in-the-middle attack is tempting, but that alters data in transit, while here the publisher built the backdoor in.
