CCNA Container Virtualization Questions — Page 2 of 2

MCQeasy

Which command provides system-wide information about the Docker installation?

A.docker inspect

B.docker status

C.docker info

D.docker version

AnswerC

docker info queries the daemon directly, returning host-wide details such as storage driver, kernel version, CPU and memory totals, and running container counts. This satisfies the stem's system-wide scope, unlike docker version, which reports only client and server version numbers.

Why this answer

The `docker info` command provides system-wide information about the Docker installation, including the number of containers and images, storage driver, logging driver, kernel version, operating system, CPU and memory resources, and Docker root directory. It is the standard command for a high-level overview of the Docker daemon's configuration and state.

Exam trap

The trap is confusing `docker info` (system-wide daemon information) with `docker version` (client/server version details) or `docker inspect` (per-object metadata) — candidates must match the scope of the command to the question's request.

How to eliminate wrong answers

Option A is wrong because `docker inspect` is used to inspect a specific container, image, network, or volume — it returns detailed JSON metadata for a single object, not system-wide information. Option B is wrong because `docker status` is not a valid Docker CLI command. Option D is wrong because `docker version` shows the version information of the Docker client and server (daemon), including API version and Go version, but not system-wide configuration details like storage driver or resource counts.

Practice this question →

MCQmedium

You need to run a container that requires access to the host's network namespace directly to perform packet capture. Which Docker run flag should you use?

A.--cap-add NET_ADMIN

B.--privileged

C.--net bridge

D.--network host

AnswerD

`--network host` places the container directly in the host's network namespace, so its interfaces and packet-capture capabilities are the host's own. This satisfies the stem's requirement for direct namespace access, unlike bridge or overlay networks, which isolate the container behind NAT and a separate stack.

Why this answer

The --network host flag attaches the container directly to the host's network namespace, meaning the container shares the host's network stack (interfaces, routing table, and loopback). This is exactly what is required for packet capture tools like tcpdump or Wireshark to see host-level traffic without NAT or bridge isolation. Unlike capability grants, this flag changes the network namespace itself, which is the actual requirement stated in the question.

Exam trap

The trap here is confusing capability grants (NET_ADMIN, --privileged) with namespace sharing — candidates assume that granting more privileges automatically gives host network visibility, when only --network host changes the namespace.

How to eliminate wrong answers

Option A is wrong because --cap-add NET_ADMIN only grants the capability to perform network administration tasks (like configuring interfaces or enabling promiscuous mode) but does not place the container in the host's network namespace, so it still sees only its own isolated bridge network. Option B is wrong because --privileged grants all capabilities and disables most isolation, but it does not by itself change the network namespace — the container still uses the default bridge unless --network host is also specified. Option C is wrong because --net bridge is the default Docker network mode that places the container on an isolated bridge network with NAT, which is the opposite of what packet capture on host traffic requires.

Practice this question →

MCQeasy

Which flag is used to run a container in the background?

A.-t

B.-b

C.-d

D.-i

AnswerC

The -d flag detaches the container, running it in the background so the terminal returns immediately instead of attaching to the process output. This matches the stem's requirement precisely; without it, docker run stays in the foreground.

Why this answer

The `-d` (or `--detach`) flag tells `docker run` to start the container and immediately return control to the shell, running the container in the background. Without it, the container runs in the foreground and attaches its STDOUT/STDERR to your terminal, blocking the prompt until the process exits. This is the standard way to launch long-running services like web servers or databases.

Exam trap

The trap is mixing up the interactive flags (`-i`, `-t`) with the detach flag (`-d`) — candidates who memorise 'i for interactive, t for terminal' sometimes wrongly assume one of those backgrounds the container.

How to eliminate wrong answers

Option A is wrong because `-t` (or `--tty`) allocates a pseudo-TTY for the container, which is typically paired with `-i` for interactive shells — it does not detach the container. Option B is wrong because `-b` is not a valid `docker run` flag for background execution; there is no such short option in the Docker CLI. Option D is wrong because `-i` (or `--interactive`) keeps STDIN open for the container, which is used for interactive sessions, not for backgrounding — it must be combined with `-d` or `-t` to be useful.

Practice this question →

MCQmedium

What is the purpose of the 'ENTRYPOINT' instruction in a Dockerfile?

A.To run build-time commands

B.To copy files

C.To configure the container as an executable

D.To set environment variables

AnswerC

ENTRYPOINT defines the fixed executable launched when the container starts, letting the image run as a self-contained command. Unlike CMD, its arguments are not overridden by docker run parameters, so the container behaves as the packaged application itself.

Why this answer

ENTRYPOINT configures the container to run as an executable by defining the command that executes when the container starts. Arguments passed on 'docker run' are appended to ENTRYPOINT rather than replacing it, which is what makes the container behave like a standalone binary. This is distinct from CMD, which provides overridable defaults.

Exam trap

The trap is mixing up ENTRYPOINT with RUN or CMD — candidates see 'executable' and pick RUN (build-time) or pick CMD thinking it is the same, missing that ENTRYPOINT is the non-overridable runtime executable definition.

How to eliminate wrong answers

Option A is wrong because build-time commands are executed with RUN during image build, not ENTRYPOINT at runtime. Option B is wrong because copying files into the image is done with COPY or ADD. Option D is wrong because environment variables are set with ENV (or passed via --env at runtime), not ENTRYPOINT.

Practice this question →

MCQhard

You are configuring an OpenVZ container. Which command is used to set the hostname of the container from the host?

A.vzctl set CTID --hostname

B.vzcfg

C.hostnamectl

D.openvz-edit

AnswerA

vzctl set applies configuration changes to a running or stopped OpenVZ container from the host, and the --hostname parameter sets the container's hostname directly. This avoids entering the container, satisfying the requirement to configure it from the host.

Why this answer

The `vzctl set <CTID> --hostname <name>` command sets the hostname of an OpenVZ container from the host. The `--hostname` option updates the container's configuration and applies the change, optionally with `--save` to persist it to the configuration file.

Exam trap

The trap is confusing host-level tools (`hostnamectl`) with OpenVZ-specific management commands (`vzctl`) — candidates must know that OpenVZ containers are managed from the host via `vzctl`, not via in-container systemd tools.

How to eliminate wrong answers

Option B is wrong because `vzcfg` is not a valid OpenVZ command — there is no such utility. Option C is wrong because `hostnamectl` is a systemd utility that sets the hostname of the local system (or a container if run inside it), but it cannot target a remote OpenVZ container from the host. Option D is wrong because `openvz-edit` is not a valid OpenVZ command — configuration is edited via `vzctl set` or by directly editing `/etc/vz/conf/<CTID>.conf`.

Practice this question →

MCQhard

In a Docker environment, you are observing that container logs are consuming too much disk space. Which logging driver should you configure to limit the number and size of log files?

A.none

B.json-file

C.syslog

D.journald

AnswerB

The json-file driver writes each container's stdout/stderr to JSON files and honours max-size and max-file options, capping both individual file size and retained file count. This directly satisfies the stem's requirement to limit log number and size.

Why this answer

The json-file logging driver is Docker's default and supports the max-size and max-file options, which limit the size of each log file and the number of rotated files. Configuring these options prevents container logs from consuming excessive disk space. Other drivers either discard logs or forward them without built-in rotation controls.

Exam trap

305-300 often tests whether candidates know that log rotation options (max-size, max-file) are specific to the json-file (and local) driver, so the trap is choosing syslog or journald assuming they offer the same Docker-level rotation controls.

How to eliminate wrong answers

Option A is wrong because the none driver disables logging entirely, which loses logs rather than limiting their size. Option C is wrong because syslog forwards logs to a syslog server and does not provide local file rotation limits. Option D is wrong because journald sends logs to systemd-journald, where rotation is managed by journald configuration, not Docker's max-size/max-file options.

Practice this question →

Multi-Selecthard

Which TWO of the following are true regarding container orchestration platforms?

Select 2 answers

A.They replace the container runtime

B.They automate container deployment

C.They only run on bare metal

D.They manage container health monitoring

E.They require a single container image

AnswersB, D

Container orchestration platforms schedule containers onto nodes and manage their lifecycle automatically, satisfying the stem's requirement for automated deployment. The scheduler evaluates resource requests, affinity rules and node health before placing workloads, then restarts or reschedules failed containers without manual intervention, which is precisely the automation the question asks about.

Why this answer

Option B is correct because container orchestration platforms such as Kubernetes, Docker Swarm, and Amazon ECS are specifically designed to automate the deployment, scheduling, and scaling of containers across a cluster of hosts. Option D is correct because these platforms continuously monitor container health through liveness and readiness probes (e.g., Kubernetes livenessProbe/readinessProbe) and automatically restart or reschedule unhealthy containers to maintain the desired state. Option A is incorrect because orchestration platforms sit above and consume a container runtime such as containerd or CRI-O rather than replacing it.

Option C is incorrect because orchestration platforms can run on bare metal, virtual machines, or cloud instances. Option E is incorrect because orchestration platforms are designed to manage many different container images simultaneously, not a single image.

Exam trap

The trap is conflating orchestration with the container runtime — candidates pick 'they replace the container runtime' because orchestration feels like a higher-level replacement, when in fact it depends on the runtime underneath.

Practice this question →

MCQmedium

You are building a Docker image for a Python web application. The Dockerfile currently contains: FROM python:3.9-slim COPY . /app WORKDIR /app RUN pip install -r requirements.txt CMD ["python", "app.py"] After building, you notice that every time you change app.py, the entire pip install step re-runs, making builds slow. Which change to the Dockerfile will best address this?

A.Add a .dockerignore file that excludes app.py so that changes to it do not invalidate the cache.

B.Use a multistage build with a separate stage for dependencies, and copy the installed packages from the builder stage into the final stage.

C.Combine the COPY and RUN instructions into a single RUN instruction using a shell command to copy files and install dependencies.

D.Move the COPY instruction to after the RUN pip install instruction, and copy only requirements.txt before the RUN.

AnswerD

Placing COPY requirements.txt before RUN pip install allows Docker to cache the dependency layer. When only app.py changes, the cached pip install layer is reused, drastically speeding up rebuilds. Copying the rest of the source after the RUN ensures that source changes do not invalidate the dependency installation layer, which is the core optimization for build caching.

Why this answer

Docker builds images layer by layer and caches each layer based on the instruction and the files it references. By copying only requirements.txt and running pip install before copying the rest of the source, the expensive dependency installation layer remains cached as long as requirements.txt is unchanged. Subsequent changes to application code only invalidate later layers, resulting in much faster rebuilds.

Exam trap

The trap here is assuming that any COPY instruction invalidates all subsequent layers, when in fact Docker's cache is keyed to the specific files referenced by each COPY, so ordering matters.

Practice this question →

MCQeasy

Which command is used to stop all running containers?

A.docker kill --all

B.docker stop $(docker ps -q)

C.docker rm -f *

D.docker prune

AnswerB

docker ps -q lists only the IDs of running containers, and command substitution feeds that list to docker stop, halting each one. This satisfies the stem's requirement to stop all running containers in a single command.

Why this answer

docker stop $(docker ps -q) uses command substitution: docker ps -q lists only the IDs of running containers, and those IDs are passed to docker stop, which gracefully sends SIGTERM then SIGKILL after a timeout. This is the idiomatic way to stop all running containers from the shell. The other options either don't exist, target the wrong resource, or perform a different operation.

Exam trap

The trap is that docker kill --all looks like a valid bulk operation, but docker kill has no --all flag — candidates must know the correct command-substitution idiom.

How to eliminate wrong answers

Option A (docker kill --all) is wrong because docker kill does not support an --all flag; it requires explicit container names or IDs and sends SIGKILL immediately without graceful shutdown. Option C (docker rm -f *) is wrong because docker rm removes containers (forcefully if running) rather than stopping them, and the shell glob * would expand to filenames in the current directory, not container IDs. Option D (docker prune) is wrong because docker prune (e.g., docker system prune) removes unused data like stopped containers, networks, and dangling images — it does not stop running containers.

Practice this question →