Docker Certified Associate Free Sample Questions

In a Docker Swarm using a Raft consensus algorithm, a quorum (majority of managers) is required to make any changes to the cluster state. When a manager is isolated and cannot communicate with the majority, it can no longer participate in the consensus. Its log becomes effectively read-only, and it cannot commit new tasks or changes. The partition with the majority of managers (in this case, two out of three) maintains the quorum and continues to operate the cluster, electing a new leader if necessary.

A bind mount is the most appropriate choice for this scenario. It mounts a file or directory from the host machine directly into the container. This avoids copying the data into the container's storage, saving space and I/O. Since the dataset is large and read-only, a bind mount is highly efficient. The host path must exist on every Swarm node where the service task might run. A volume mount would create a Docker-managed volume, which would involve copying the data into it initially. A tmpfs mount is in-memory and not persistent, making it unsuitable for this use case.

Kubernetes Secrets are the standard, secure way to handle sensitive information like passwords, tokens, and keys. They are stored in the cluster (often base64 encoded, but can be encrypted at rest) and can be easily updated without rebuilding images. They can be exposed to pods as environment variables or mounted as files, isolating sensitive data from the application image and configuration files. ConfigMaps are for non-sensitive configuration data. Baking credentials into an image is a major security vulnerability.

To achieve complete isolation, you should create a dedicated overlay network (isolated-net). Then, create both services and attach them ONLY to this network. Crucially, you must NOT publish any ports (-p flag) for either service. This ensures that the services can communicate with each other via their service names over the isolated-net, but no traffic can reach them from outside the Swarm cluster or from services on other networks.

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.