Containers and images, and why a container is not a small VM

Why this matters

CompTIA's verb for this objective is explaining containerization and its role in cloud environments. That is a deliberately modest verb, and it sets the depth: you are expected to understand what a container is, how it differs from a virtual machine, and what that difference implies for isolation, state and operations. You are not expected to write orchestrator controllers.

The difference that matters most is isolation. A virtual machine is isolated by a hypervisor and has its own kernel; a container is isolated by kernel features and shares the host's kernel. Almost every correct answer about container security, density, startup time and portability follows from that one sentence.

The lesson

Namespaces and cgroups: isolation by kernel feature rather than by hypervisor

A container is a process — or a small group of processes — running on the host kernel with a restricted view of the system. Two Linux kernel facilities do the work:

• Namespaces control what a process can see. Separate namespaces exist for process IDs, mounts, network interfaces, hostnames, users and inter-process communication. A container sees its own process tree starting at PID 1, its own filesystem root and its own network interfaces, because each is a separate namespace.
• Control groups (cgroups) control what a process can use: CPU shares and quotas, memory limits, block I/O and process counts.

Together they produce something that looks like a machine from inside and is a process from outside. On the host you can see the container's processes in the ordinary process list — which is a good way to convince yourself it really is not a virtual machine.

The consequences, and these are the exam's favourite comparison:

The last two rows are the ones worth memorising. A container cannot run a different operating system family than its host kernel — Windows containers need a Windows kernel — and where isolation strength is the requirement, particularly for untrusted or hostile workloads, a virtual machine boundary is the stronger answer. Some platforms bridge this with lightweight VMs per container precisely because a shared kernel is a shared attack surface.

Images, layers and the registry, and why a layer you added cannot be unadded

A container image is a stack of read-only filesystem layers plus metadata describing how to start the process. Each instruction in a build file that changes the filesystem produces a layer; a running container adds a thin writable layer on top.

Layering gives two useful properties: layers are shared between images that have a common base, so ten images from one base store that base once; and builds are cached, so only layers after the first change are rebuilt.

The property that catches people out is that layers are additive and immutable. If you copy a secret into an image in one layer and delete it in the next, the file is gone from the final filesystem view but the layer containing it is still in the image. Anyone who can pull the image can read it.

The rules that follow are practical and examinable:

• Never put secrets in an image, at any stage of the build. Inject them at run time — environment from a secret store, a mounted volume, or a platform identity. Objective 4.3 treats this as a security control.
• Order build steps from least to most frequently changed so the cache is useful.
• Use multi-stage builds so build tooling and source do not ship in the final image — smaller and less exposed.
• Pin base images. A tag like latest is a moving pointer, so the image you built yesterday and the one you build today may differ with no change on your side. Pin to an immutable digest where reproducibility matters.

A registry stores and distributes images, publicly or privately, with access control and usually vulnerability scanning.

The container lifecycle, and what happens to data when a container stops

The lifecycle is short: an image is pulled, a container is created and started, it runs a single foreground process, and when that process exits the container stops. Restart policies may then restart it.

Two consequences:

The container's writable layer is ephemeral. Anything written inside the container that is not on a mounted volume is lost when the container is removed — and containers are removed constantly, by design, because that is how updates and rescheduling work. Treating the writable layer as storage is the single most common beginner mistake.

One process, in the foreground. A container's lifetime is its main process's lifetime. If that process daemonises into the background the container exits immediately, which is a very common "it starts and instantly stops" troubleshooting scenario. Logs conventionally go to standard output rather than to files, so the platform can collect them.

Persistent volumes, bind mounts and the stateless assumption underneath both

To keep data, mount storage into the container.

• Bind mount. A path on the host mapped into the container. Simple, fast, and ties the container to that host — fine in development, a problem in a cluster where the container may be rescheduled elsewhere.
• Volume. Storage managed by the platform, with its own lifecycle independent of any container. The correct answer for data that must survive.
• Persistent volume with a claim. The orchestrated version: the workload declares the storage it needs and the platform binds it to something that satisfies it. Objective 1.5 covers the orchestration around this.
• Ephemeral / in-memory mounts. Deliberately temporary — scratch space, caches, and a sensible place for injected secrets.

The deeper point is the stateless assumption. Containers work well because the platform assumes it may kill and recreate one at any moment. Every benefit — rolling updates, self-healing, autoscaling, rescheduling after a node failure — depends on that being safe. State breaks the assumption, so the design rule is to push state outward: into managed databases, object storage or caches, rather than keeping it in the workload.

Stateful workloads in containers are possible and the platforms support them, with stable identities and attached volumes. They are simply harder, and an exam scenario weighing "should this database run in a container" is usually testing whether you know the trade rather than expecting a flat no.

When a container is the wrong answer and a virtual machine is not

Containers are a default, not a universal answer. Choose a virtual machine when:

• The workload needs a different kernel or operating system than the host.
• Isolation strength is the requirement — hostile multi-tenancy, untrusted code, or a compliance regime demanding hardware-level separation.
• The application needs kernel modules, specific drivers, or direct hardware access beyond what the platform exposes.
• It is a monolith with persistent local state, and containerising it would produce a container that cannot be rescheduled — all of the complexity and none of the benefit.
• Licensing is bound to a machine or socket and containers break the model.
• Nobody will operate the orchestrator. A cluster is an operational commitment; a small team running three services may be better served by instances or a managed platform service.

The honest framing for the exam: containers optimise for density, startup speed, portability and deployment velocity. If none of those is the scenario's driver, and isolation or compatibility is, the virtual machine is the answer.

What to take into the exam

• Containers share the host kernel; VMs have their own. Everything else follows: faster, smaller, denser, less isolated, kernel-compatible only.
• Image layers are immutable and additive. A secret deleted in a later layer is still in the image.
• latest is a moving tag. Pin for reproducibility.
• The writable layer is ephemeral; use a volume for anything that must survive.
• One foreground process per container. Daemonising causes immediate exit.
• Choose a VM for different kernels, strong isolation, hardware access, or stateful monoliths.