CCNA Container Virtualization Questions

Docker runs an embedded DNS server for user-defined networks, which listens on 127.0.0.11 and resolves container names and aliases. It allows containers on the same network to communicate using their names. This server is automatically configured in the container's /etc/resolv.conf. It is the correct mechanism for service discovery within a user-defined bridge network.

Rocket's daemonless design removes the long-running central daemon that Docker relied on, so containers launch directly via the rkt CLI without a persistent broker process. This satisfies the stem's architectural difference: no privileged daemon means a reduced attack surface and independent container lifecycle management.

Setting `jail_enable=YES` in `/etc/rc.conf` activates FreeBSD's `rc.d/jail` framework, which reads the `jail_list` variable and starts each named jail during the multi-user boot phase. This satisfies the stem's boot-persistence constraint directly, without requiring manual `jail` invocations or external schedulers.

Containers on the default bridge receive DNS configuration from the Docker daemon unless overridden per container. If the daemon's `dns` setting points to an unreachable resolver, name resolution fails inside the container even though the host resolves fine. Checking `/etc/docker/daemon.json` for a `dns` entry or the `--dns` daemon flag is the correct first step.

macvlan assigns each container its own MAC and IP address on the parent interface, making it appear directly attached to the physical network. This satisfies the stem's requirement for containers to hold their own IPs on the physical network, unlike bridge, which uses NAT.

USER sets the runtime user for all subsequent RUN, CMD and ENTRYPOINT instructions in the Dockerfile, satisfying the stem's user-context constraint. It changes the UID/GID used during build and at container start, unlike WORKDIR, which only alters the working directory.

--private-network gives the container its own isolated network namespace, separate from the host's interfaces and routing table. This satisfies the requirement to isolate container traffic, preventing direct host network access unless a virtual Ethernet link is explicitly configured.

The -p 8080:80 flag publishes host port 8080 to container port 80, where the web server actually listens per the Dockerfile. EXPOSE alone only documents the port; explicit publishing is required for external access, satisfying the stem's mapping requirement.

Docker's -p flag takes host-port:container-port order, so -p 8080:80 publishes host port 8080 and forwards it to port 80 inside the container. Reversing the pair would map the ports the wrong way round, failing the stem's stated mapping.

COPY transfers files or directories from the build context on the host into the image filesystem at the specified destination. Unlike ADD, it performs no URL fetching or archive extraction, making it the precise instruction for the stem's host-to-image copy requirement.

ADD copies files from a build context or remote URL into the image filesystem, creating a new layer that persists in the resulting image. This directly modifies image content, satisfying the question's requirement for instructions that change the filesystem, unlike metadata-only directives such as CMD or ENTRYPOINT.

By default, systemd-nspawn does not create a separate network namespace, so the container shares the host's network stack. If you omit all network options such as `--private-network` or `--network-interface`, the container uses the host's interfaces and routing directly. This is the intended way to achieve host network sharing with systemd-nspawn.

`lxc.cgroup.cpu.cfs_quota_us` sets the CFS bandwidth quota in microseconds per period, directly satisfying the stem's requirement for a CPU-time quota. Unlike `cpu.shares`, which only weights relative contention, this parameter enforces an absolute ceiling on runtime, so the container cannot exceed its allotted CPU time.

The bridge mode is Docker's default, creating a private internal network on the host and connecting containers to it through a virtual bridge interface. It is natively supported, making it one of the three networking modes the question requires.

systemd-nspawn by default creates a PID namespace for the container, which isolates its processes from the host's process tree. Processes inside the container only see other processes in the same container, not those on the host. This is a fundamental isolation feature and does not require an extra flag. While other options like --private-users add user isolation, PID namespace isolation is always active unless explicitly disabled with --private-pid or similar, which is not the case here.

PID namespaces give each container its own process ID numbering, so processes inside see themselves starting at PID 1 and cannot observe or signal host processes. This delivers the process isolation the question asks for, preventing cross-container visibility of the host process tree.

'docker rm' deletes a stopped container from the local Docker host, removing its writable layer and metadata. It does not touch images, volumes, or running containers unless forced with -f, distinguishing it from 'docker rmi', which removes images.

Docker adds rules to the NAT table for port forwarding and masquerading.

/etc/vz/conf/CTID.conf holds each OpenVZ container's configuration, including environment variables and resource limits, with CTID replaced by the container's numeric ID. This satisfies the stem's requirement for the file defining configuration and environment variables, since OpenVZ reads per-container settings from this path rather than a global file.

Using `machinectl export-tar` streams a running or stopped container's entire filesystem into a tar archive, which can later be imported as a template. This satisfies the stem's requirement to create a reusable image from a systemd-nspawn container, since nspawn containers are managed as machines via machinectl rather than Docker-style commits.

A registry acts as the central repository that stores versioned container images and serves them to hosts on request, satisfying the need to persist and distribute artefacts. It is not a build tool or runtime; its function is storage plus retrieval over the network, enabling consistent image pulls across environments.

User-defined networks in Podman allow containers to communicate with each other by name via an embedded DNS server. Creating a network with podman network create and then running the container with --network <name> enables inter-container communication. This is necessary because the default network may not provide name resolution or isolation. It fulfills the requirement for communication between containers on the same host.

During container initialization, runc attempts to mount a new proc filesystem at /proc inside the container's root filesystem. If the /proc directory does not exist in the container image, the mount call fails with 'no such file or directory'. This is a common issue when building minimal images from scratch without creating the standard directories. The solution is to ensure the image includes an empty /proc directory.

This option sets a CPU bandwidth limit using cgroup v2. The values represent quota and period in microseconds, so 50000 100000 means the container can use 50% of one CPU core. It is a valid and current way to restrict CPU usage in LXC when using cgroup v2, which is the default on modern systems.

Compose's declarative service definitions rely on YAML's indentation-based mapping, which expresses nested services, images and volumes without the verbosity of JSON or XML. The stem asks which format defines services, and Compose reads docker-compose.yml as YAML by default.

A bind mount maps a specific host directory path, chosen by the user, into the container, so data written there persists on the host filesystem at that exact location. Named volumes persist too, but Docker manages their path rather than the user defining it.

Source NAT for outbound container traffic is performed in the nat table's POSTROUTING chain, where MASQUERADE or SNAT rules rewrite the source address after routing. Inspecting this chain reveals whether the SNAT rule is present, correctly matched, or bypassed by an earlier rule.

docker rmi removes images from the local image store, deleting tagged references and, with -f, dependent layers. It is the dedicated image-removal command, directly satisfying the stem's requirement to delete an unused image rather than containers or volumes.

Kubernetes satisfies the orchestration requirement by automating container deployment, scaling and management across clusters. It provides declarative configuration, self-healing, service discovery and load balancing, which are the defining capabilities the question demands. Unlike standalone runtimes such as Docker Engine, Kubernetes coordinates workloads across multiple hosts, making it a valid orchestration platform.

docker tag assigns an additional repository name and tag to an existing local image, creating a new reference without rebuilding layers. This is an image-management operation, satisfying the stem's requirement for commands that manage images rather than containers or networks.

devicemapper is a Docker storage driver using thin provisioning on block devices via the kernel's device-mapper framework, controlling layers through snapshots. It satisfies the stem by being one of the drivers Docker documents and supports for managing image and container layers.

Containers share the host kernel and isolate processes via namespaces and cgroups, avoiding the full guest operating system a virtual machine must boot. This architectural difference yields smaller images and startup in seconds rather than the minutes a hypervisor-based VM typically needs.

docker manifest inspect queries the registry API directly, returning the image's manifest, layers, platform variants and digests without downloading layer blobs to the local daemon. That satisfies the stem's constraint of inspecting metadata without pulling the image.

Docker passes proxy settings into the build through --build-arg, which injects values such as HTTP_PROXY as environment variables available to RUN instructions. Without it, the build container cannot reach external repositories, so the RUN step fails despite valid host network access.

The jail utility is FreeBSD's standard administrative command for creating, starting, stopping and listing jails. Running 'jail' with a configuration or parameters starts the jail and executes its command, directly fulfilling the requirement to start a jail.

User Beancounters are per-container resource limits enforced by the OpenVZ kernel, controlling CPU, memory and disk quotas. They appear in the container's configuration file alongside other parameters, satisfying the requirement for a typical OpenVZ configuration item.

`docker system df -v` shows detailed disk usage of images, containers, volumes, and build cache, including which items consume space. Since the Docker data root is on a separate partition, `df -h` on the host root may not reflect it. This command reveals the actual consumption within Docker's storage area, helping identify the cause of the 'no space left' error.

The --device flag allows passing a host device into the container, making it accessible as /dev/sdb inside the container. This grants direct access to the block device, enabling I/O operations. It is the correct way to expose specific devices without using privileged mode. Other options do not provide device access.

Ingress mode publishes a service on the swarm's routing mesh, so every node accepts traffic on the published port and forwards it to healthy replicas regardless of placement. This provides the load-balancing across all healthy container replicas that the scenario requires.

The docker images command queries the local image cache and returns every stored image with repository, tag, image ID, creation time and size. It requires no running container and reads directly from the host's Docker daemon, satisfying the stem's request to list images on the host.

docker system prune removes stopped containers, unused networks and dangling images in a single invocation, matching the requirement to clean these resources in one step. Adding -a extends it to all unused images, but the base command already covers the three specified categories.

docker stats streams live CPU, memory, network and block I/O metrics for each running container, refreshed continuously. This directly satisfies the requirement to display resource usage of running containers, unlike docker ps, which only lists containers without consumption figures.

CPU shares are a cgroup CPU-scheduling control, letting LXC allocate relative processor time between containers. This satisfies the stem's requirement for a manageable cgroup item, since shares directly tune CPU distribution rather than merely reporting usage or configuring storage and networking.

`ARG` defines a build-time variable that can be passed with `--build-arg` and is available only during the build stage. It is not persisted in the image's environment or history in a way that exposes the value to running containers. This matches the requirement of a variable that is used during build but not retained in the final image.

APT leaves package index caches under /var/lib/apt/lists/* after installation; deleting them in the same layer prevents that metadata persisting into the final image. This directly satisfies the image-size reduction constraint, since those cached lists are otherwise retained in the layer.

The `--rm` flag tells Docker to automatically remove the container's filesystem when it exits. This is ideal for short-lived tasks where the container does not need to persist. It prevents accumulation of stopped containers and matches the requirement of self-removal after the command completes.

A sidecar runs alongside the main container in the same pod, sharing its network namespace and lifecycle, to handle auxiliary concerns such as log shipping, metrics collection or proxying. This offloads cross-cutting functions without altering the primary application image.

The overlay driver encapsulates container traffic in VXLAN, extending a single logical network across multiple Docker hosts. This satisfies the stem's multi-host constraint, which bridge and host drivers cannot meet since they are confined to one host.

docker inspect returns the container's full JSON metadata: configuration, network settings, mounts, environment variables and state. It reads the daemon's stored object rather than live process output, matching the stem's requirement to examine metadata and configuration of a running container.

The Docker daemon (dockerd) is the persistent background process that builds images, runs containers and manages Docker objects via the Docker API. It is a core architectural component, so it belongs in the correct three-part selection.

docker exec runs a new command inside a container that is already running, which is exactly the requirement. It differs from docker run, which starts a fresh container, and from docker attach, which merely connects to the existing main process.

`useradd -u 1000 -m appuser` creates the user with the specified UID and a home directory during the build, while running as root. The subsequent `USER appuser` instruction sets the runtime user for the rest of the build and the container. This order ensures the user exists before it is referenced, which is the correct and reliable pattern.

Network namespaces give each container its own isolated set of interfaces, routing tables, firewall rules and ports, so processes cannot see or interfere with the host's or other containers' networking. This satisfies the isolation requirement by virtualising the network stack per container.

COPY --from=builder references the earlier build stage by name, pulling only the compiled binary into the final image without dragging along the builder's toolchain or layers. This satisfies the stem's multi-stage requirement, keeping the runtime image minimal while the build dependencies stay confined to the discarded stage.

The cgroup devices controller filters access by major:minor numbers, so 'b 8:0 rwm' permits block device 8:0 (/dev/sda) with read, write and mknod rights. Without this allow rule, the container's device cgroup denies access, satisfying the requirement to expose the host block device.

The -d flag detaches the container, running it in the background and returning the container ID to the shell. This satisfies the detached-mode requirement, unlike -it which attaches an interactive TTY to the foreground process.

`lxc-snapshot -n container_name` invokes the LXC snapshot utility against the named container, capturing the root file system state through the container's backing storage. It satisfies the stem's requirement to snapshot an LXC container's root file system directly, without manual copy or export steps.

NUMPROC directly caps the process count within an OpenVZ container, satisfying the requirement to limit process creation. Set in the container configuration file, it enforces this per-container barrier independently of host-wide limits, unlike CPU or memory parameters that govern different resources entirely.

The `-D` flag sets the container's root directory, satisfying the requirement to specify a different root filesystem. It accepts a path to a directory tree or image, which systemd-nspawn then uses as the container's root, rather than defaulting to a machine-name-derived location under `/var/lib/machines`.

An image is an immutable, layered filesystem template stored locally or in a registry; a container instance is that image instantiated as a running process with a writable layer. This template-versus-process distinction directly answers the stem's request for the primary difference.

ENTRYPOINT sets the executable that runs when the container starts, satisfying the stem's requirement. Unlike CMD, which supplies default arguments that a docker run command can override, ENTRYPOINT fixes the process itself, with CMD values passed to it as parameters.

`docker logs [container]` retrieves stdout and stderr captured by the container's configured logging driver, streaming them to your terminal without entering the container. This satisfies the scenario's requirement to view a running container's logs directly, since Docker retains that output for the container's lifetime.

Combining update, install and cache removal in a single RUN layer prevents apt metadata persisting in the final image, directly satisfying the minimise-image-size constraint. Separate instructions would each commit a layer, retaining the lists irreversibly. The `rm -rf` executes before the layer is committed, so nothing is left behind.

Docker inspect returns the container's full configuration as JSON, including the NetworkSettings object with IP address, gateway, MAC address, port bindings and connected networks. That directly satisfies the stem's requirement to inspect container network settings, unlike commands that only list or alter them.

Rocket runs application containers grouped as pods, using a pluggable execution stage and signature-verified images to isolate workloads securely. This pod-centric, pluggable design satisfies the scenario's requirement for running pods in a secure, pluggable manner, distinguishing it from single-container runtimes.

docker inspect returns detailed JSON metadata about a container, including its network settings (IP address), environment variables, mounts, and much more. It is the primary tool for retrieving low-level configuration and runtime information. The output can be filtered with --format to extract specific fields. This command satisfies all the requirements in the scenario with a single invocation.

`docker history` reads an image's manifest and prints each layer with its ID, size and originating instruction, directly satisfying the requirement to show layer history. Unlike `docker inspect`, which returns JSON metadata about the whole image, it enumerates the individual build steps, making it the precise command for this scenario.

A bind mount maps an existing directory on the host directly into the container. Data written by the container appears immediately in that host directory, and it persists independently of the container lifecycle. This satisfies both requirements: data survives container removal and is directly accessible on the host filesystem without needing Docker-specific tools to locate it.

Named volumes are stored outside the container's writable layer, under Docker's managed volume directory, so data survives container deletion and can be mounted by several containers simultaneously via the same volume name — satisfying both the sharing and persistence constraints in the stem.

Using RUN to delete cache files in the same layer where they were created ensures the files are not persisted in the final image. If the deletion occurs in a separate RUN instruction, the cache files remain in the earlier layer and still contribute to the image size. Combining installation and cleanup in a single RUN instruction is the recommended practice.

docker history displays the intermediate layers of an image along with the commands that created them, their sizes, and creation timestamps. It provides a concise view of the image's build history, which is exactly what is needed to understand how the image was constructed. This command is specifically designed for this purpose and is the correct choice.

The Dockerfile supplies the declarative build instructions — base image, RUN commands, COPY directives and ENTRYPOINT — that docker build executes layer by layer. It defines the image contents, satisfying the requirement to specify how the container image is constructed.

overlay2 is a valid Docker storage driver that stacks image layers using the OverlayFS union filesystem, supporting copy-on-write between lower and upper directories. It is the default and recommended driver on modern Linux hosts, making it a legitimate answer for managing image layers.

CAP_NET_BIND_SERVICE allows a non-root process to bind to ports below 1024, including port 80. In rootless Podman, the container process runs as an unprivileged user on the host, so without this capability the bind to port 80 fails with a permission denied error. Adding this capability via --cap-add=NET_BIND_SERVICE grants exactly the needed privilege while keeping the rest of the container unprivileged.

Docker's default bridge network routes container traffic through the host's FORWARD chain, since packets are forwarded between the bridge and the external interface. A restrictive FORWARD policy (DROP) blocks that path even though the host itself has connectivity, making FORWARD the chain responsible for the container's failed internet access.