DCA Sample Questions & Answers

This statement is true. The COPY instruction was specifically enhanced for multi-stage builds with the --from flag to allow copying files from a named previous stage. The ADD instruction, while having more features like URL and tar extraction, does not support the --from flag and cannot be used to copy artifacts between build stages.

To set a default logging driver for all containers on a host, the configuration must be applied to the Docker daemon itself. This is done by modifying the daemon.json file (typically located at /etc/docker/daemon.json on Linux) to include the logging driver and its options. For example: {"log-driver": "splunk", "log-opts": {"splunk-token": "..."}}. This ensures any container started without a specific --log-driver flag will inherit the daemon's default.

A multi-stage build, which uses multiple FROM instructions in a single Dockerfile, is the standard and most efficient way to solve this. The first stage (e.g., FROM golang:1.19 as builder) can be used to install dependencies and build the binary. A subsequent stage (e.g., FROM alpine:latest) can then use COPY --from=builder /app/binary /app/binary to copy ONLY the compiled artifact into a clean, minimal base image. This ensures the final image does not contain any build-time dependencies, resulting in a significantly smaller size.

The command docker node update --availability drain is specifically designed for this purpose. Setting the availability to drain does two things: 1) it prevents the scheduler from assigning new tasks to the node, and 2) it gracefully stops and reschedules any existing tasks from that node onto other available nodes in the cluster. pause only prevents new tasks but leaves existing ones running. active is the normal state. rm is for removing the node from the swarm entirely.

The docker logs command is only functional for containers that use the json-file or journald logging drivers. If the Docker daemon or the specific container is configured to use a different driver (e.g., splunk, syslog, gelf), the logs are sent directly to the specified endpoint and are not stored in a way that docker logs can access. The other options are less likely; even a quickly exiting container would produce some log output if it used the default driver, and an application logging to a file would not prevent docker logs from showing startup errors sent to stdout/stderr before file logging began.

To run a task on every eligible node, you must use --mode global. To restrict this deployment to only the nodes with a specific label, you must add a --constraint. The correct syntax for constraining based on a node label is 'node.labels.LABEL == VALUE'. Combining --mode global with the appropriate constraint ensures the service runs one task on every node that matches the criteria, and only on those nodes.

The docker run command provides a --dns flag specifically to specify custom DNS servers for the container to use. By default, a container inherits the DNS settings from the host's /etc/resolv.conf. To override this and point to a specific internal DNS server, the --dns flag is the correct and direct method. The other options are incorrect; --add-host is for static host entries (like a /etc/hosts file), --ip sets the container's IP, and -p is for port mapping.

This statement is true. The standard docker system prune command removes stopped containers, unused networks, and dangling images. The -a (or --all) flag extends this to remove all unused images, which includes any image not associated with at least one running or stopped container. This is a more aggressive cleanup than the default.

Docker Content Trust (DCT) is the feature designed for this exact purpose. It uses digital signatures to provide trust for image content. When enabled (by setting the DOCKER_CONTENT_TRUST=1 environment variable), the Docker client will verify the signature of any image being pulled and will sign any image being pushed. This ensures that the image has not been tampered with and originates from a trusted publisher.

The most robust and correct method for using shared storage like NFS with Swarm services is to use a Docker volume with a specific volume-driver and options. By specifying volume-driver=local and providing the NFS-specific options (type=nfs, device=..., o=...), you instruct Docker on each node how to mount the shared storage into a managed volume. This is superior to a simple bind mount because it leverages the Docker volume ecosystem and is more explicit and configurable. A simple bind mount would work but is less idiomatic for services, while a standard volume would be local to a single node and not suitable for rescheduling.