Containerization — SY0-701

WHAT IT IS

A container is "a method for packaging and securely running an application within an application virtualization environment" (NIST SP 800-190). The broader practice — containerization — is the use of application virtualization, defined as "a form of virtualization that exposes a single shared operating system kernel to multiple discrete application instances, each of which is kept isolated from all others on the host" (NIST SP 800-190).

A container image is "a package that contains all the files required to run a container" (NIST SP 800-190). The host OS is "the operating system kernel shared by multiple applications within an application virtualization architecture" (NIST SP 800-190).

Mental model

Think of a container as a sealed shipping container on a cargo ship. The ship (host OS kernel) carries many containers; each container holds only the goods it needs. The containers do not know about each other. If one container is damaged, the others keep sailing — that is isolation: "the ability to keep multiple instances of software separated so that each instance only sees and can affect itself" (NIST SP 800-190).

When to use it

The exam regularly asks you to distinguish containerization from full machine virtualization. The key structural difference is what each approach shares and what it dedicates.

Property	Container (application virtualization)	Virtual machine (full virtualization)
What is shared	Host OS kernel (NIST SP 800-190)	Physical hardware only
What each instance has	Its own filesystem, processes, and libraries	Its own guest OS (NIST SP 800-125A)
Managed by	Host OS (application virtualization layer)	Hypervisor — "the virtualization component that manages the guest OSs on a host and controls the flow of instructions between the guest OSs and the physical hardware" (NIST SP 800-125)
Isolation mechanism	OS-level isolation per NIST SP 800-190	Full hardware-level separation per NIST SP 800-125
Attack surface implication	Shared kernel is a common boundary for all instances	Each VM has its own kernel boundary

The attack surface is "the set of points on the boundary of a system, a system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from" it (NIST SP 800-53 Rev. 5). A compromised host kernel in a containerized environment is therefore a shared risk across all containers running on that host.

COMMON MISCONCEPTION

Containers are not the same as virtual machines, and they do not provide the same degree of isolation.

Because both technologies run multiple workloads on one physical host, candidates often treat them as equivalent. They are not. A virtual machine "is a software-defined complete execution stack consisting of virtualized hardware, operating system (guest OS), and applications" (NIST SP 800-125A) — it carries its own OS. A container shares the host OS kernel (NIST SP 800-190). That shared kernel means:

• A vulnerability in the host OS kernel can affect every container on that host, not just one.
• Containers do not fulfill the principle of least privilege at the OS level the same way VMs do: least privilege requires that "each entity is granted the minimum system resources and authorizations that the entity needs to perform its function" (NIST SP 800-53 Rev. 5) — shared kernel boundaries make that harder to enforce across tenants.

The trap on the exam is a scenario where strong workload isolation is required (e.g., multi-tenant environments with differing trust levels) and containerization is offered as equivalent to a VM-based solution. It is not — the shared kernel is a narrower isolation boundary.

How it shows up on the exam

The cognitive target for this concept is analysis: given a scenario, identify whether the isolation and attack surface properties of containerization fit the stated security requirement.

Signal phrases to watch for:

• "shared OS kernel" — points directly to containerization, not VMs.
• "application isolation" or "workload isolation" — the question may be testing whether you know which technology provides stronger boundary separation.
• "container image" — NIST SP 800-190 defines this as the package of files needed to run a container; a question about supply-chain risk in images is a containerization question.
• "hypervisor" — its presence in a scenario anchors the answer in VM/full virtualization territory, not containerization.

A common misconception candidates bring to the exam is assuming containerization offers the same isolation as a hypervisor-managed VM. Questions exploiting this confusion typically describe a security goal (e.g., preventing one tenant from affecting another) and ask which architecture best meets it. Recognizing that application virtualization exposes a single shared kernel (NIST SP 800-190) while a VM includes a full guest OS (NIST SP 800-125A) is the discriminating fact.

Related concepts

• Cloud Architecture Models — containerization is a workload deployment pattern that maps onto cloud service and deployment models.
• Shared Responsibility Model — who secures the host OS kernel in a containerized environment depends on the deployment model and shared responsibility boundaries.
• Infrastructure as Code — container images and their orchestration are commonly defined and managed through infrastructure-as-code practices.