DCA Practice Questions

The ARG instruction defines a variable that is only available during the build process. It can be set at build time using the --build-arg flag. Unlike ENV, ARG variables are not persisted in the final image layers or accessible to containers running from the image, making them perfect for build-time secrets or metadata that shouldn't be leaked. Using ENV would persist the variable, which is not desired in this scenario.

Publishing in host mode bypasses the Swarm routing mesh. It directly binds the container's port to the specified port on the host node where the task is running. This provides higher performance but sacrifices the load balancing and location independence of the default ingress mode. In this case, each of the three nginx tasks will bind port 8080 on their individual hosts. If two tasks were scheduled on the same node, the second one would fail due to a port conflict.

In UCP's RBAC model, permissions are managed through Grants. A Grant is the binding of a Subject (a user or team) to a Role (a set of permissions, like 'View Only' or 'Full Control') over a Resource Set (a Collection of Docker resources like containers, services, etc.). The issue is likely that the 'dev' team either has no Grant or an incorrect Grant (wrong Role or wrong Collection) that prevents them from creating container resources.

The docker stack deploy command is the native Swarm method for deploying applications defined in a Compose file (or 'stack file'). It reads the docker-compose.yml file, translates the service definitions into Swarm services, and deploys them to the cluster. The -c or --compose-file flag is used to specify the file, and the final argument (myapp) gives the stack a name. docker-compose up is used for local development on a single Docker engine.

Docker images are composed of a series of read-only layers. Each instruction in a Dockerfile creates a new layer. When rm is run in a new layer, it only marks the file as deleted in that upper layer, but the actual file data still exists in the lower layer where it was added. The fix is to perform the file creation, usage, and deletion within the same RUN command, ensuring the temporary file never gets committed to a permanent layer. For example: RUN process_data.sh /app/largefile.tmp && rm /app/largefile.tmp.

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.