Docker & Containers MCQ

Explanation

Containers package an application with its dependencies but share the host operating system's kernel, making them more lightweight than full virtual machines.

Explanation

An image is the immutable blueprint from which one or more containers can be created; the container is the running instance of that image.

Explanation

"docker build" reads instructions from a Dockerfile and builds an image, typically tagged with "-t name:tag".

Explanation

A Dockerfile defines step-by-step instructions (FROM, RUN, COPY, CMD, etc.) that Docker executes to produce an image.

Explanation

"docker run" creates and starts a new container from a specified image; "docker start" restarts an existing stopped container.

Explanation

"docker ps" lists running containers by default; adding "-a" shows all containers including stopped ones.

Explanation

FROM defines the starting point/base image for subsequent instructions, such as "FROM ubuntu:22.04" or "FROM node:20-alpine".

Explanation

COPY transfers files and directories from the build context (the directory passed to "docker build") into the image being built.

Explanation

CMD provides default arguments/command for the container that can be easily overridden, while ENTRYPOINT configures a command that is harder to override and CMD often supplies its default arguments.

Explanation

"docker stop" sends SIGTERM (then SIGKILL after a timeout) to stop the container's process gracefully; the container still exists and can be restarted with "docker start".

Explanation

"docker rm <container>" deletes a stopped container; a running container must be stopped first or removed with "-f" to force removal.

Explanation

"docker rmi <image>" deletes a local image; it fails if a container is currently using that image unless forced.

Explanation

Docker Hub is the default public registry where official and community images (like "nginx" or "ubuntu") are hosted and can be pulled with "docker pull".

Explanation

"docker pull <image>:<tag>" fetches an image (or a specific tag of it) from a registry such as Docker Hub.

Explanation

The "-p hostPort:containerPort" flag publishes a container's port to the host, so requests to host port 8080 are forwarded to port 80 inside the container.

Explanation

"-d" (detached) runs the container in the background and prints the container ID, returning control of the terminal immediately.

Explanation

Volumes provide persistent storage that exists outside a container's writable layer, so data survives container removal and can be shared between containers.

Explanation

"docker exec" runs an additional command inside a running container; "-it" allocates an interactive terminal, commonly used to open a shell for debugging.

Explanation

Docker uses Linux kernel features — namespaces for isolating views of resources (PIDs, network, mounts) and cgroups for limiting resource usage — to isolate containers.

Explanation

Similar to .gitignore, .dockerignore prevents unnecessary or sensitive files (like node_modules or .git) from being included in the build context, speeding up builds and reducing image size.

Explanation

Docker Compose lets you define multiple services, networks, and volumes in a "docker-compose.yml" file and start/stop them together with simple commands.

Explanation

Each entry under "services" defines a container — its image or build context, ports, volumes, environment variables, and dependencies.

Explanation

EXPOSE is documentation/metadata about which ports the application uses; actually publishing a port to the host still requires the "-p" flag on "docker run".

Explanation

Tags allow multiple versions of an image to coexist (e.g. "nginx:1.25", "nginx:latest"); if no tag is specified, Docker defaults to "latest".

Explanation

"docker logs <container>" fetches the stdout/stderr output of a container's main process; adding "-f" follows the log stream in real time.

Explanation

VMs virtualize hardware and run a complete guest OS via a hypervisor, which is heavier; containers virtualize at the OS level, sharing the host kernel, making them start faster and use fewer resources.

Explanation

WORKDIR sets (and creates if needed) the working directory inside the image for all following instructions, avoiding repeated absolute paths.

Explanation

"docker images" lists all images stored locally, showing repository name, tag, image ID, creation date, and size.

Explanation

ENV sets environment variables both during the build process and within containers started from the resulting image.

Explanation

A container's writable layer is ephemeral; without a volume or bind mount, any data written there is lost when the container is removed.

Explanation

"docker network" subcommands (create, ls, inspect, connect) manage virtual networks that containers use to communicate.

Explanation

The default bridge network creates an isolated internal network; containers on it get their own IP addresses and can reach external networks via NAT through the host.

Explanation

"docker tag <source> <target>" creates an additional reference to the same image, often used before pushing to a specific registry/repository.

Explanation

"docker push <repository>:<tag>" uploads a locally tagged image to a remote registry so it can be pulled by others.

Explanation

RUN executes commands at build time (like "apt-get install"), and the result is committed as a new image layer; this differs from CMD/ENTRYPOINT which run at container startup.

Explanation

Alpine Linux is a minimal distribution (a few MB), so Alpine-based images (e.g. "node:20-alpine") significantly reduce image size compared to larger base distributions.

Explanation

"docker container prune" removes containers that are in the "exited" or "created" state, helping clean up disk space.

Explanation

LABEL adds arbitrary metadata to an image (e.g. "LABEL maintainer=\"dev@example.com\""), useful for organization and automation tooling.

Explanation

While technically possible to run multiple processes, the convention of one process per container simplifies dependency management, scaling, and failure isolation in container orchestration.

Explanation

"docker inspect" returns a detailed JSON document describing a container's (or image's/volume's/network's) full configuration and current state.

Explanation

Multi-stage builds let you compile/build in one stage (with full toolchains) and copy only the final artifacts into a minimal runtime stage, significantly reducing the final image size.

Explanation

Volumes are fully managed by Docker (location abstracted away, portable), while bind mounts depend on the host's directory structure, giving direct access but tying the container to a specific host path.

Explanation

Layer caching means unchanged instructions don't need to be re-executed on rebuild, and multiple images sharing a base can reuse the same underlying layers on disk, saving space and build time.

Explanation

Since a cache miss on one layer invalidates all subsequent layers, placing stable steps (installing dependencies) early and frequently-changing steps (copying app code) later avoids unnecessary re-execution of expensive steps.

Explanation

The "-d" flag for Compose runs containers in the background (detached), similar to "docker run -d", freeing up the terminal.

Explanation

HEALTHCHECK instructions (or compose healthcheck config) let Docker monitor container health by periodically running a test command, which orchestration tools can use to restart unhealthy containers.

Explanation

depends_on controls startup/shutdown order at the container level; it does not wait for the application inside the container to be ready to accept connections — health checks or wait-scripts are needed for that.

Explanation

"--rm" automatically cleans up the container's filesystem and removes it from "docker ps -a" once it stops, useful for temporary/one-off containers.

Explanation

"docker-compose down" stops and removes containers and networks; adding "-v" additionally removes named volumes, which can permanently delete persisted data.

Explanation

Docker uses cgroups to enforce resource limits like "--memory" and "--cpus", preventing a single container from consuming all of the host's resources.

Explanation

ARG values (passed via "--build-arg") are accessible only during the build process by default; ENV values are baked into the image and available to containers at runtime.

Explanation

"docker system prune -a" aggressively reclaims disk space by removing all unused data, including images not referenced by any container, which could require re-downloading or rebuilding them later.

Explanation

On user-defined bridge networks, Docker provides automatic DNS resolution by container name, so services can reference each other by name (e.g. "db") instead of hardcoded IPs.

Explanation

Docker computes a checksum of each instruction (and file contents for COPY/ADD); if these match a previous build, the cached layer is reused, otherwise that layer and everything after it must be rebuilt.

Explanation

Exec form avoids an extra shell process, making the application PID 1 and able to receive signals (like SIGTERM from "docker stop") directly, while shell form runs the command through "/bin/sh -c", which may not forward signals properly.

Explanation

Compose supports layering multiple YAML files via "-f", commonly used to define a base configuration plus environment-specific overrides (e.g. for development vs production).

Explanation

"docker cp <container>:<path> <hostpath>" (or vice versa) copies files between a running or stopped container and the host filesystem.

Explanation

If "apt-get update" is its own cached layer, a later "apt-get install" might use a stale package index from the cached update step; chaining them with "&&" ensures both run together whenever either changes, avoiding "package not found" errors.

Explanation

Named volumes have a human-readable identifier that makes them easy to reuse and reference across containers/restarts, while anonymous volumes are given a generated hash name and are harder to manage explicitly.

Explanation

"docker stats" shows a real-time stream of resource usage metrics for one or more containers, useful for monitoring performance.

Explanation

Running as root inside a container increases the blast radius of a potential vulnerability, especially if container isolation is somehow bypassed; the USER instruction switches to a less-privileged user for defense in depth.

Explanation

PID 1 has special responsibilities (reaping zombie child processes, handling signals); lightweight init systems like tini handle these correctly when the main application isn't designed to run as PID 1.

Explanation

buildx with QEMU emulation can build images for architectures different from the host, and a multi-arch manifest list lets "docker pull" automatically select the image variant matching the pulling host's architecture.

Explanation

"--network host" makes the container use the host's network namespace directly — ports opened in the container are immediately available on the host without explicit "-p" mapping, but this reduces isolation.

Explanation

Volume plugins/drivers let Docker volumes be backed by various storage systems (e.g. cloud-based or networked storage), enabling persistent data to survive even if the host itself is replaced.

Explanation

"unless-stopped" restarts the container on failure or Docker daemon restart, but respects an explicit "docker stop" — the container will not be automatically restarted after that until manually started again.

Explanation

"COPY --from=builder /app/dist ./dist" lets a final, minimal stage include only compiled output from an earlier (often larger) build stage, keeping the final image small.

Explanation

docker stop gives the process a chance to clean up (close connections, flush data) before forcing termination, whereas docker kill terminates immediately without that grace period.

Explanation

Compose automatically loads "docker-compose.override.yml" alongside "docker-compose.yml" if present, letting developers customize behavior locally (e.g. enabling debug ports or live-reload mounts) without altering the shared base configuration.

Explanation

"--no-cache" ensures a completely fresh build, useful when cached layers (like "apt-get update" results or downloaded dependencies) might no longer reflect the current state of external resources.

Explanation

Since signals from "docker stop" target PID 1, applications (or wrapper scripts) that don't correctly handle SIGTERM as PID 1 may be forcefully killed after the timeout instead of shutting down cleanly.

Explanation

Compose automatically loads a ".env" file from the project root and substitutes its variables into the compose file using "${VAR}" syntax, useful for keeping configuration/secrets out of version control.

Explanation

Without cgroup memory limits, "/proc/meminfo" inside a container can report the host's total memory, which can cause memory-aware applications to size caches or heaps based on incorrect assumptions about available resources.

Explanation

"docker save <image> > image.tar" and "docker load < image.tar" allow moving images between systems offline, e.g. via a USB drive or air-gapped environment, without needing a registry.

Explanation

BuildKit, the default builder in recent Docker versions, improves on the legacy builder with more efficient caching, concurrent stage builds, and additional features like "--secret" for securely passing build-time credentials.

Explanation

"--scale" creates multiple container instances from the same service definition (useful with a load balancer in front), whereas defining separate services is appropriate when each instance needs different configuration.

Explanation

After "docker login", credentials are cached (ideally via a secure credential helper) so future operations against that registry don't require re-authentication; "docker logout" clears those cached credentials.

Explanation

"--env-file" reads key=value pairs from a file and sets them as environment variables in the container, convenient for managing many variables without long command lines.

Explanation

"docker-compose config" prints the fully resolved configuration (after merging files and substituting variables), useful for debugging what Compose will actually apply.

Explanation

A read-only root filesystem prevents an application (or attacker) from writing to most of the container's filesystem, a hardening technique; applications needing to write temporary files must be given explicit writable volumes or tmpfs mounts.

Explanation

Linux namespaces (PID, network, mount, UTS, IPC, user) give each container an isolated view of system resources; the PID namespace specifically isolates the process tree so containers have their own PID 1.

Explanation

While namespaces provide isolated views of resources, cgroups enforce limits on how much of those resources (CPU, memory, I/O bandwidth) a group of processes can consume, preventing one container from starving others.

Explanation

overlay2 implements the union filesystem that stacks image layers and a container's writable layer transparently, whereas bind mounts are a separate mechanism for exposing specific host paths inside the container, often used for persistent or shared data.

Explanation

The Docker daemon runs as root, so any process that can talk to its socket can create privileged containers, mount the host filesystem, and effectively gain root on the host — making this a significant privilege escalation risk if exposed to untrusted code.

Explanation

Unlike "docker run" which sets up new namespaces, "docker exec" enters the namespaces already established for the target container's init process, so the new process shares that container's filesystem, network, and process tree view.

Explanation

Because containers share the host kernel, a vulnerability in the kernel or an overly permissive configuration (privileged mode, dangerous capabilities, exposed sockets) can allow a process to break out of its container boundary and affect the host or other containers.

Explanation

By default containers run with a reduced capability set rather than full root privileges; explicitly dropping further unneeded capabilities (like "ALL" then adding back only what's required) follows the principle of least privilege, limiting what an attacker could do if the container is compromised.

Explanation

seccomp (secure computing mode) filters allow only a whitelisted set of syscalls; Docker's default profile blocks dangerous syscalls (like certain kernel module operations) that most containerized applications never legitimately need, reducing the kernel attack surface.

Explanation

The OCI Image Specification and Runtime Specification standardize how container images are packaged and how runtimes execute them, enabling tools across the ecosystem (Docker, Kubernetes/containerd, Podman) to interoperate.

Explanation

Because layers are immutable and stacked, deleting a file in a later layer doesn't remove it from the image's total size — it just hides it; combining install-and-cleanup into a single RUN avoids ever persisting the unwanted files, and multi-stage builds avoid shipping build-only layers altogether.

Explanation

The default bridge network lacks automatic DNS resolution between containers (historically requiring "--link", now deprecated), while user-defined networks automatically register container names in an embedded DNS server, making "--link" unnecessary.

Explanation

A manifest list (image index) groups multiple architecture-specific manifests under one tag/reference; the client's platform determines which underlying manifest (and thus image) is actually pulled, enabling a single tag to work across architectures.

Explanation

ulimits (like "nofile" for open file descriptors, or "nproc" for processes) are a Linux mechanism for per-process resource limits; containers inherit defaults that may be too low for high-concurrency applications, so they can be explicitly raised via "--ulimit".

Explanation

Build arguments (ARG) can be inspected via "docker history" or remain in intermediate layers, risking credential leakage; BuildKit's "--secret" mounts sensitive files transiently during a build step without writing them into any layer.

Explanation

Docker's restart policies operate within a single host's Docker daemon, while orchestrators provide cluster-wide scheduling, health-based rescheduling across nodes, scaling, and rolling updates — a fundamentally larger scope of "self-healing".

Explanation

Distroless images strip out shells, package managers, and other binaries not needed at runtime, minimizing both size and the tools available to an attacker who gains code execution, at the cost of making interactive debugging ("docker exec ... sh") harder.

Explanation

Cache mounts let build steps (like "npm install" or "pip install") reuse downloaded packages between builds via a persistent cache directory, without that cache becoming part of any image layer, combining fast rebuilds with small final images.

Explanation

Tags are mutable pointers that can be reassigned by the image publisher, so the same tag might resolve to different content over time; a content-addressed digest guarantees you always get the exact same bytes, important for reproducibility and supply-chain security.

Explanation

"docker events" provides a live stream of daemon-level events, which monitoring/automation tools can subscribe to in order to react to container lifecycle changes (e.g. automatically updating a reverse proxy configuration when containers start/stop).

Explanation

Mutable references (tags, "latest" dependency versions) and non-deterministic build steps (timestamps, network calls returning different data over time) can cause the same Dockerfile to produce different images on different days; pinning versions/digests and using lockfiles reduces this variability.