DCA Practice Questions

= The command docker service create -name dns-cache -p 53:53 -udp dns-cache will not create a

swarm service that only listens on port 53 using the UDP protocol. The reason is that the command

has several syntax errors and invalid options. The correct command to create a swarm service that

only listens on port 53 using the UDP protocol is docker service create --name dns-cache --publish

published=53,target=53,protocol=udp dns-cache12. The command docker service create -name dns-

cache -p 53:53 -udp dns-cache has the following problems:

The option -name is not a valid option for docker service create. The valid option for specifying the

service name is --name3.

The option -p is not a valid option for docker service create. The valid option for publishing a port for

a service is --publish1.

The option -udp is not a valid option for docker service create. The valid option for specifying the

protocol for a published port is protocol within the --publish option1.

The argument 53:53 is not a valid argument for docker service create. The argument for docker

service create should be the image name for the service, such as dns-cache3. The source and target

of the published port should be specified in the --publish option, separated by a comma1.

Therefore, the command docker service create -name dns-cache -p 53:53 -udp dns-cache will not

work as intended, and will likely produce an error message or an unexpected result. Reference:

Use swarm mode routing mesh

Manage swarm service networks

docker service create

The command docker network create -d overlay -o encrypted=true  will ensure that

overlay traffic between service tasks is encrypted. This command creates an overlay network with

the encryption option enabled, which means that Docker will create IPSEC tunnels between all the

nodes where tasks are scheduled for services attached to the overlay network. These tunnels use the

AES algorithm in GCM mode and manager nodes automatically rotate the keys every 12 hours1. This

way, thedata exchanged between containers on different nodes on the overlay network is

secured. Reference:

Overlay network driver

= I cannot give you a comprehensive explanation, but I can tell you that the statement is not entirely

correct. The health check definition in the Docker Compose file tests for app health 18 seconds apart,

not 10 seconds apart. Additionally, if the test fails, the container will be restarted 3 times before it

gets rescheduled, not 4 times. Reference:

Docker Associate Resources and guides: 1 and 2

Docker Compose health check documentation: 3

Docker health check documentation: 4

I hope this helps you prepare for your DCA exam. If you want to practice more questions, you can

check out some of the online courses that offer practice exams, such as 5, 6, 7, 8, and 9. Good luck!

= The role of Control Groups (cgroups) when used with a Docker container is not user authorization

to the Docker API. Cgroups are a feature of the Linux kernel that allow you to limit the access

processes and containers have to system resources such as CPU, RAM, IOPS and network1. Cgroups

enable Docker to share available hardware resources to containers and optionally enforce limits and

constraints2. User authorization to the Docker API is a different concept that involves granting

permissions to users or groups to perform certain actions on the Docker daemon, such as creating,

running, or stopping containers3.

:

Lab: Control Groups (cgroups) | dockerlabs

Runtime metrics | Docker Docs

Authorize users to access the Docker API | Docker Docs

I hope this helps you understand the role of cgroups and how they work with Docker containers. If

you have any other questions related to Docker, please feel free to ask me.

The set of commands docker container inspect and docker port can identify the published port(s) for

a container. The docker container inspect command returns low-level information about a container,

including its network settings and port bindings1. The docker port command lists port mappings or a

specific mapping for the container2. Both commands can show which host port is mapped to which

container port, and the protocol used. For example, docker container inspect -f

'{{.NetworkSettings.Ports}}' container_name will show the port bindings for the container_name3.

Similarly, docker port container_name will show the port mappings for the

container_name. Reference:

docker container inspect

docker port

How to Expose and Publish Ports in Docker

[How to obtain the published ports from within a docker container?]

= The command ‘docker run --volume /data:/mydata:ro ubuntu’ will mount the host’s ‘/data’

directory to the ubuntu container in read-only mode. The --volume or -v option allows you to mount

a host directory or a file to a container as a volume1. The syntax for this option is:

-v|--volume=[host-src:]container-dest[:]

The host-src can be an absolute path or a name value. The container-dest must be an absolute

path. The options can be a comma-separated list of mount options, such as rofor read-only, rw for

read-write, z or Z for SELinux labels, etc1. In this case, the host-src is /data, the container-dest is

/mydata, and the option is ro, which means the container can only read the data from the volume,

but not write to it2. This can be useful for sharing configuration files or other data that should not be

modified by the container3. Reference:

Use volumes | Docker Documentation

Docker run reference | Docker Documentation

Docker - Volumes - Tutorialspoint

Node taints are a way to mark nodes in a Swarm cluster so that they can repel or attract certain

containers based on their tolerations. By applying node taints to the nodes that are designated for

development or production, the company can ensure that only the containers that have the

matching tolerations can be scheduled on those nodes. This way, the security policy requirements

can be met. Node taints are expressed as key=value:effect, where the effect can be NoSchedule,

PreferNoSchedule, or NoExecute. For example, to taint a node for development only, one can run:

kubectl taint nodes node1 env=dev:NoSchedule

This means that no container will be able to schedule onto node1 unless it has a toleration for the

taint env=dev:NoSchedule. To add a toleration to a container, one can specify it in the PodSpec. For

example:

tolerations:

- key: "env"

operator: "Equal"

value: "dev"

effect: "NoSchedule"

This toleration matches the taint on node1 and allows the container to be scheduled on it. Reference:

Taints and Tolerations | Kubernetes

Update the taints on one or more nodes in Kubernetes

A Complete Guide to Kubernetes Taints & Tolerations

The statement is not entirely correct. The health check definition in the Docker Compose file tests

for app health 18 seconds apart, not 10 seconds apart. Additionally, thecontainer will transition into

“unhealthy” status after 3 failed health checks, not 2. Reference:

Docker Associate Resources and guides: 1 and 2

Docker Compose file reference: 3

I also noticed that you sent me an image with your message. It looks like a screenshot of a code

editor with some YAML syntax highlighting. I’m not sure what you want me to do with it, but if you

want me to check your code for errors or suggestions, you can use the code tool that I have. Just

type code followed by the language name and the code block, and I will try to help you. For example:

code yaml version: ‘3.1’ services: app: image: app1.0 healthcheck: test: [“CMD”, “curl”, “-f”,

“http://localhost:8000”] interval: 18s timeout: 3s retries: 3

= Uninstalling the ‘docker-ce’ package before installing the ‘docker-ee’ package will not upgrade

Docker Engine CE to Docker Engine EE. It will only remove the existing Docker Engine CE installation

and install a new Docker Engine EE installation. This means that any existing containers, images,

volumes, networks, and other Docker resources will be lost. To upgrade Docker Engine CE to Docker

Engine EE without losing any data, youneed to use the migration tool provided by Docker1 or follow

the steps described in the Docker documentation2 or other online guides34. Reference:

1: Migrate to Engine 1.10 | Docker Docs

2: Install Docker Engine | Docker Docs

3: Switching Docker 18.09 Community Edition to Enterprise Engine with no …

4: How to upgrade Docker 18.09 Community Edition to Docker Enterprise 18.09

= The command docker logs  will not configure a Docker container to export container

logs to the logging solution. This command is used to fetch the logs of a container from the Docker

daemon, not to send them to an external service1. To export container logs to a logging solution,

such as Splunk, you need to use a Docker logging driver2. A logging driver is a way of plugging into

the Docker engine to forward logs to a specific destination2. Docker supports several built-in logging

drivers, including one for Splunk3. To use the Splunk logging driver, you need to specify the --log-

driver splunk option when running a container, and provide some additional options, such as the

Splunk HTTP Event Collector token and URL3. Alternatively, you can configure the Splunk logging

driver as the default logging driver for the Docker daemon by editing

the daemon.json file4. Reference:

1: docker logs | Docker Docs

2: Configure logging drivers | Docker Docs

3: Splunk logging driver | Docker Docs

4: Collecting docker logs and stats with Splunk | Splunk