Containers and Orchestration Questions and Answers

Answer: A

Correct answer: shares the host kernel

A container is a process on the host, isolated by namespaces and limited by cgroups, and it uses the host’s kernel rather than booting one of its own. That is why it starts in milliseconds and costs a few megabytes, where a virtual machine must boot a complete operating system on virtual hardware - and it is also why the isolation is weaker, as the next item makes explicit.

Answer: B

Correct answer: Both A and R are true, and R is the correct explanation of A

Both are true and the reason gives the mechanism. A virtual machine’s escape must get through the hypervisor, a small and narrow interface; a container’s escape need only get through the kernel’s system call surface, which is very large. A kernel vulnerability therefore exposes every container on the host at once, which is why untrusted multi-tenant workloads are given a virtual machine boundary or a sandboxed runtime.

Answer: C

The container is an assembly of ordinary kernel features rather than a distinct object. Knowing which feature does what is essential when isolation has to be reasoned about. None of them is new. The container is an assembly of old parts.

Answer: D

Namespaces handle what a process can see, and the two mechanisms together make a container. Limits on memory and processor time both come from control groups. Visibility and limits are separate. Both are needed to make a container.

Answer: A

Correct answer: layers of filesystem changes

Each instruction in the build produces a layer recording the filesystem changes it made, and the image is those layers stacked by a union filesystem. The arrangement is what makes images cheap to store and transfer: an unchanged layer is neither rebuilt nor re-sent, so an application layer of a few megabytes on a shared base is all that moves between builds.

Answer: B

Correct answer: Both A and R are true, and R is the correct explanation of A

Both are true and the reason gives the mechanism. Each layer is identified by the hash of its content, so two images referencing the same base layer refer to the same object, which is stored once on the host and in the registry and pulled once. Ordering a Dockerfile so that the rarely changing layers come first is how that saving is deliberately maximised.

Answer: C

Correct answer: 1 and 2 only

Statements 1 and 2 are correct: built layers are immutable, and a running container gets a thin writable layer above them through copy-on-write. Statement 3 is wrong - that writable layer belongs to the container instance and is discarded when it is removed. Changes become part of an image only through a deliberate build or commit.

Answer: D

Correct answer: False

The writable layer is part of the container, not of the image, so removing the container removes everything written inside it. Anything that must outlive the container has to be placed on a mounted volume - which is a deliberate design choice rather than an oversight, since it is what makes containers disposable and interchangeable.

Answer: A

Containers in a pod share an address and can reach one another on localhost. The pod rather than the container is the smallest unit Kubernetes schedules. Localhost reaches the siblings. Containers in a pod share an address.

Answer: B

The objects compose rather than replace one another, and a typical application uses all four. Understanding which object owns which concern is most of learning the system. Each has a single concern. They compose rather than replace one another.