Container Virtualization practice questions

ext4-driver

Why it fails: ext4-driver is not a Docker storage driver; ext4 is a filesystem, and Docker's overlay2, devicemapper and btrfs drivers sit above it. It is tempting because ext4 underpins many Docker hosts, but Docker never exposes it as a selectable driver name.

vfs

Why it fails: vfs is a valid Docker storage driver, so it cannot be an incorrect option here; it is the fallback driver used when no copy-on-write filesystem is available, operating without layering optimisations. It would be the correct choice on systems lacking overlay2, btrfs or zfs support.

--share-system

Why it fails: This is not a valid systemd-nspawn flag.

--clock-passthrough

Why it fails: This flag does not exist in systemd-nspawn.

--bind=/dev/rtc

Why it fails: Binding the RTC device is not the standard way to manage container time synchronization.

lxc.cap.keep

Why it fails: This manages Linux capabilities, not device access.

lxc.mount.entry

Why it fails: This is used for mounting filesystems, not granting device node access.

lxc.hook.pre-start

Why it fails: This is for running scripts, not direct device exposure.

lxc.mount.auto = proc:mixed sys:mixed

Why it fails: This handles pseudo-filesystems but not device isolation.

lxc.namespace.share = 0

Why it fails: This is not a valid LXC configuration key.

lxc.cap.drop = sys_admin

Why it fails: This drops capabilities, not device access.

--private-network=false

Why it fails: This is not the correct syntax for sharing the network.

--network-veth

Why it fails: --network-veth creates a virtual Ethernet pair linking container and host, giving the container its own namespace, the opposite of sharing the host's. It tempts because veth is the standard nspawn networking setup, and it is correct when you want isolated container networking bridged to the host rather than identical host interfaces.

--share-net

Why it fails: --share-net is not a systemd-nspawn flag; nspawn uses --network-host to place the container in the host network namespace. It tempts because the name reads like the obvious toggle, and similar-sounding sharing options exist elsewhere, but nspawn rejects it, so the command fails rather than sharing interfaces.

mount -t nullfs

Why it fails: nullfs mounts a directory from the host into the jail's tree, which exposes host paths rather than confining the jail to its own subtree. It is tempting because nullfs is used for sharing host directories into jails, and would be correct when the goal is to make external data visible inside the jail.

jail_root_dir

Why it fails: jail_root_dir is not a real jail configuration parameter; the path is set with the path= option in jail.conf or via the jail command. It is tempting because the name describes exactly what the task needs, and would be correct if such a keyword existed in the jail(8) configuration syntax.

chroot

Why it fails: chroot changes the root directory of a process but provides no process, network or user isolation, so it does not confine a jail's filesystem access as the question requires. It is tempting because chroot is the historical ancestor of jails, and would be correct for a simple filesystem-root restriction without isolation.

eth0

Why it fails: This is the host's primary interface.

virbr0

Why it fails: This is created by libvirt.

none

Why it fails: This is a valid network driver, but not the default bridge.

lxc-check

Why it fails: lxc-check does not exist as a configuration-inspection command; configuration is read with lxc-config or the container's config file. It is tempting because the name suggests validating a container, and a genuine check command would suit verifying prerequisites before creating or starting containers.

lxc-ls

Why it fails: lxc-ls enumerates containers and their states, printing names rather than configuration keys. It is tempting because listing containers is a natural first step when locating 'web', and it would be the right command if the task were discovering which containers exist rather than reading one container's settings.

lxc-config

Why it fails: lxc-config is not a command; LXC container configuration is inspected by reading the container's config file, typically with lxc-info or by editing /var/lib/lxc/web/config. The name resembles lxc-* tooling, which is why it tempts, but no such binary exists for dumping configuration.

Wrong kernel version

Why it fails: A mismatched kernel version would prevent the container starting or break syscalls generally, not selectively deny /dev/null. It is tempting because kernel compatibility genuinely causes LXC failures, and would be the answer when containers refuse to boot after a host kernel upgrade.

Host kernel panic

Why it fails: A host kernel panic halts the entire machine, so no container would run at all, let alone fail on one device node. It is tempting because kernel faults do break containers, and would be correct if every container and host process had simultaneously become unresponsive.

Insufficient RAM

Why it fails: Insufficient RAM causes OOM kills or allocation failures, not a specific permission denial on /dev/null. It is tempting because resource exhaustion is a common container fault, and would be the answer if the container were being terminated under memory pressure rather than blocked from a device node.

systemctl start

Why it fails: This starts the unit, not the shell.

systemd-nspawn -run

Why it fails: This is not a valid command.

nsenter

Why it fails: nsenter is generic, but machinectl is the native tool for nspawn.

BGP

Why it fails: BGP is a routing protocol for exchanging reachability between autonomous systems; Docker Swarm overlay control and data plane traffic uses VXLAN. It is tempting because BGP underpins some SDN fabrics, and would be correct when peering routing domains rather than encapsulating Swarm overlay packets.

IPsec

Why it fails: IPsec encrypts IP packets at the network layer; Swarm overlay traffic is encapsulated with VXLAN, with optional IPsec added for encryption. It is tempting because it secures node-to-node traffic, and would be correct when confidentiality of overlay data is the stated requirement.

GRE

Why it fails: GRE is a generic tunnelling protocol, but Docker Swarm overlay networks encapsulate traffic using VXLAN. It is tempting because GRE also carries encapsulated packets between hosts, and would be correct when building a tunnel that is not Docker's overlay implementation.

The host kernel

Why it fails: The kernel is not part of the context.

Remote images

Why it fails: These are not part of the build context.

Running containers

Why it fails: These are independent of the build context.

--max-mem=512M

Why it fails: systemd-nspawn has no --max-mem flag, so it is rejected as an unknown option and no limit is applied. It is tempting because the syntax mirrors resource flags, but memory capping is done with --property=MemoryMax=512M, which sets the systemd unit's cgroup limit.

--cgroup-memory=512M

Why it fails: systemd-nspawn has no --cgroup-memory flag; memory limits are set with --property=MemoryMax=512M, which writes to the cgroup v2 memory controller. The name is tempting because cgroup memory limits are real, but that syntax belongs to systemd-run or direct cgroup manipulation, not nspawn's own option set.

--limit-mem=512M

Why it fails: No --limit-mem flag exists in systemd-nspawn; memory capping is done via --property=MemoryMax=512M. The name is tempting because it sounds like a natural resource-limit switch, and similar --limit-* style options appear in other container tools, but nspawn exposes cgroup settings through systemd unit properties instead.

--link

Why it fails: --link is a legacy container-to-container alias mechanism for name resolution and environment injection; it creates no storage path and survives no reboot. It is tempting because it appears in older tutorials about connecting containers, and would be relevant when one container must reach another by hostname, not for persistent shared data.

--tmpfs

Why it fails: --tmpfs mounts a memory-backed filesystem whose contents are discarded when the container stops and never written to disk, so nothing persists across a host reboot. It is tempting because it offers fast scratch space, and would be correct for sensitive temporary files that must never touch persistent storage.

--volume-driver=none

Why it fails: --volume-driver=none disables plugin-based volume provisioning, leaving no managed storage path for containers to share, so persistence across reboot is not provided. It is tempting when avoiding third-party drivers, and would be correct where only bind mounts to host directories are intended.

--memory

Why it fails: --memory sets a cgroup limit on RAM available to a container; it configures runtime resource constraints, not a storage path, so it cannot provide persistent shared data. It is tempting because it appears among docker run flags, and would be correct when capping a container's memory usage to protect the host.

--cpu-limit

Why it fails: Docker has no --cpu-limit flag; the daemon rejects it outright, so the container never starts. It is tempting because the name mirrors the --memory limit syntax, and a hard ceiling on total CPU time is what --cpus actually provides.

--cpus

Why it fails: --cpus sets a hard ceiling on total CPU time (for example 1.5 CPUs), not relative shares. It is tempting because it does cap CPU, but the stem asks for shares, which --cpu-shares weights during contention.

--max-cpu

Why it fails: --max-cpu is not a recognised Docker run flag, so the command fails with an unknown flag error. It is tempting because the name suggests a hard CPU ceiling, which --cpus genuinely enforces as an absolute quota.

--cpu-weight

Why it fails: This is not a valid flag.

OverlayFS

Why it fails: OverlayFS is a union filesystem providing layered image storage, not the isolation mechanism namespaces rely on. It is tempting because containers do use it for copy-on-write layers, and it is a genuine kernel feature, but namespace isolation comes from the namespace subsystem itself, not from the filesystem stacking driver.

Seccomp

Why it fails: Seccomp filters syscalls a process may invoke; it restricts available kernel operations rather than isolating namespaces. It is tempting because it is a real container-hardening feature and often enabled alongside namespaces, but it does not create the separate views of PIDs, mounts, or networks that namespace isolation requires.

Cgroups

Why it fails: Cgroups account for and limit resource consumption such as CPU and memory; they do not provide the isolated views of system resources that namespaces deliver. It is tempting because cgroups and namespaces are frequently paired in container runtimes, but the question asks specifically about the isolation mechanism, which is the namespace feature.

AppArmor

Why it fails: AppArmor is a mandatory access control framework confining programs via security profiles; it does not create namespace isolation. It is tempting because it is a genuine container security layer often enabled by Docker and Kubernetes, but it restricts file and capability access rather than providing separate PID, mount, or network views.

lxc-pause

Why it fails: lxc-pause suspends a running container's processes rather than managing lifecycle transitions such as create, start, stop or destroy. It is tempting because freezing is a genuine LXC operation, and it would be the right command when you need to temporarily halt a container without stopping it.

lxc-reboot

Why it fails: lxc-reboot does not exist; LXC lifecycle commands are lxc-start, lxc-stop, lxc-create and lxc-destroy. It is tempting because rebooting is a familiar container operation, and a reboot command would be correct if LXC shipped one for restarting a container in place.

--memory-swap

Why it fails: --memory-swap controls the amount of memory and swap a container can use combined. It is used in conjunction with --memory to limit swap usage. It does not set a memory limit by itself; it modifies swap behavior. Thus, it is not a primary option for limiting memory usage.

--blkio-weight

Why it fails: --blkio-weight sets the relative weight for block I/O, not CPU or memory. It controls bandwidth allocation for block devices. It does not enforce CPU or memory limits. Therefore, it is not relevant for the scenario of limiting CPU and memory.

--cpu-shares

Why it fails: --cpu-shares sets the relative weight of CPU time for a container compared to others. It does not enforce a hard limit on CPU usage. It only influences scheduling when there is contention. Therefore, it cannot strictly limit CPU usage as required. It is not a hard constraint.

Use 'links' in the web service definition to point to the db service, and remove the shared network.

Why it fails: 'links' is a legacy feature that creates a one-way dependency and adds an entry to the web container's /etc/hosts, but it does not provide network-level isolation. The db container would still be on the same default network and could resolve and connect to the web container. Removing the shared network without defining a new one would break name resolution entirely, so this does not meet the requirement.

Attach the web container to a second user-defined network 'frontend_net', and attach the db container only to 'app_net'.

Why it fails: Adding a second network to the web container does not prevent the db container from reaching it on the shared 'app_net' network. Both containers would still have interfaces on 'app_net', and Docker's embedded DNS would resolve 'web' from the db container, allowing db to initiate connections. This approach expands connectivity rather than restricting it, so it does not satisfy the requirement.

Place the db container on an internal-only network and the web container on both the internal network and a frontend network.

Why it fails: An 'internal' network in Docker Compose prevents external access to the network, but it does not prevent containers on that network from communicating with each other. The db container could still reach the web container on the internal network. This configuration addresses external connectivity, not lateral movement between containers, so it fails to enforce the desired one-way restriction.

Set the environment variable LOG_DIR=/var/log/app and expect the application to create it

Why it fails: Setting an environment variable does not create the directory or set its permissions. If the application attempts to create /var/log/app as a non-root user, it will fail because /var/log is typically owned by root and not writable by unprivileged users. The image must explicitly create the directory and assign ownership; relying on the application to do so is not a valid solution.

Add a VOLUME instruction for /var/log/app so the directory is writable at runtime

Why it fails: VOLUME creates an anonymous volume at runtime, but the ownership of the volume is typically root unless the image already has the directory owned by the non-root user. It does not change permissions or ownership, so the non-root user may still be unable to write. VOLUME also complicates image layering and is not the correct tool for setting directory ownership.

Use the --chown flag with a COPY instruction to copy a placeholder file into /var/log/app

Why it fails: The --chown flag on COPY sets ownership of copied files and their parent directory only if the parent directory is created by the copy. If /var/log/app already exists in a previous layer, COPY --chown may not change the directory ownership. This is unreliable and does not guarantee the directory is writable by the non-root user. A dedicated RUN chown is more explicit and predictable.