I85PREP
⌘ K
DCA study materials
DCA study resources

Docker Certified Associate practice questions

One question at a time. Build your DCA understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Orchestration

Which command turns the current Docker host into the first manager of a brand-new swarm?

  1. docker swarm init Correct answer.
  2. docker node promote
  3. docker swarm join
  4. docker service create

Explanation

`docker swarm init` bootstraps a new swarm on the local host, makes it the first manager and prints the join commands for other nodes. It generates the manager and worker join tokens used later. Commands such as `docker swarm join` only make sense once a swarm already exists.

Question 2Orchestration

What does the command `docker swarm join-token manager` print?

  1. The join command with the manager token embedded Correct answer.
  2. A list of the manager nodes in the swarm
  3. A replacement token that invalidates the old one
  4. The swarm's CA certificate in PEM format

Explanation

The subcommand prints a ready-to-run `docker swarm join --token SWMTKN-... <ip>:2377` line for the requested role, so an operator can paste it on a new host. The token itself is not changed by printing it.

Question 3Orchestration

A replicated service publishes port 8080 on the ingress network. Which hosts accept connections on port 8080?

  1. Only containers attached to the same overlay network
  2. Only the manager nodes of the swarm
  3. Only nodes that are currently running a task of the service
  4. Every node in the swarm, including nodes with no task of the service Correct answer.

Explanation

Ingress publishing uses the routing mesh: every node listens on the published port and forwards traffic to a healthy task, wherever that task actually runs. A node with no local task still acts as an entry point.

Question 4Orchestration

Which service mode places exactly one task on every node that satisfies the service's placement constraints?

  1. ingress
  2. replicated
  3. global Correct answer.
  4. host

Explanation

`--mode global` schedules one task per eligible node and keeps that relationship as nodes are added or removed. `replicated` instead maintains a fixed number of tasks anywhere in the swarm.

Question 5Orchestration

Which node availability value both blocks new tasks from being assigned to the node and shuts down the tasks already running on it?

  1. drain Correct answer.
  2. down
  3. active
  4. pause

Explanation

`drain` marks a node as unavailable for scheduling and evicts its tasks so they are rescheduled on other nodes, which is the standard way to take a node out for maintenance. `pause` only stops new tasks from being placed.

Question 6Orchestration

Which command sets the desired replica count of the running service `api` to 6?

  1. docker service scale api=6 Correct answer.
  2. docker service create api --replicas 6
  3. docker node update api --replicas 6
  4. docker service update api --scale 6

Explanation

`docker service scale` changes the desired replica count of existing services using `service=count` pairs. The equivalent low-level flag is `--replicas` on `docker service update`, not `--scale`.

Question 7Orchestration

Which command creates a swarm stack named `web` from the file `docker-compose.yml`?

  1. docker stack deploy -c docker-compose.yml web Correct answer.
  2. docker service deploy -c docker-compose.yml web
  3. docker stack up -c docker-compose.yml web
  4. docker compose deploy -c docker-compose.yml web

Explanation

`docker stack deploy` reads a Compose file with `-c` and a stack name, then creates one swarm service per service defined in the file. The stack name becomes the prefix of every created object.

Question 8Orchestration

Which network driver provides a swarm-scoped network that containers on different nodes can use to communicate?

  1. bridge
  2. host
  3. overlay Correct answer.
  4. none

Explanation

Overlay networks use VXLAN encapsulation so every task gets an address that is reachable from any node in the swarm, which is what multi-host container communication relies on. The other drivers are scoped to a single host or remove networking altogether.

Question 9Orchestration

A service has 5 replicas and an `update_config` with `parallelism: 2` and `delay: 10s`. How does a rolling update proceed?

  1. It replaces two tasks, waits 10 seconds, then replaces the next two, and so on Correct answer.
  2. It stops all five tasks at once, then waits 10 seconds before starting replacements
  3. It replaces one task every 10 seconds until all five are replaced
  4. It replaces two tasks and fails the update if they are not healthy within 10 seconds

Explanation

`parallelism` caps how many tasks are updated at the same time and `delay` is the pause between consecutive batches, so a 5-replica service updates as 2, then 2, then 1. The pause exists so a broken release is caught before it affects every task.

Question 10Orchestration

A rolling update of the service `web` produced failing tasks. Which command returns `web` to the specification it had before that update?

  1. docker service revert web
  2. docker stack rollback web
  3. docker service rollback web Correct answer.
  4. docker service update web --revert

Explanation

`docker service rollback` restores the previous version of the service specification and rolls it out again. Docker keeps the prior spec as part of the service's version history specifically for this purpose.

Question 11Orchestration

Where does Docker place a swarm secret inside a service's containers by default?

  1. In a file under /run/secrets Correct answer.
  2. In an entry of the container's /etc/hosts file
  3. In a file under /etc/docker/secrets
  4. In an environment variable named after the secret

Explanation

Secrets are mounted as a tmpfs file at `/run/secrets/<secret-name>` inside the container, so the value is available to the process without being baked into the image. Applications read that file at runtime.

Question 12Orchestration

A swarm has three manager nodes. How many of them can fail while the swarm still keeps a Raft quorum?

  1. 0
  2. 3
  3. 1 Correct answer.
  4. 2

Explanation

Raft requires a strict majority of managers, which is 2 of 3, so a single manager failure is tolerated. With two failures only one manager remains, no majority can be formed, and cluster-management requests such as deploying services stop working.

Question 13Orchestration

Some nodes are labelled with `disktype=ssd`. Which `docker service create` option restricts the service's tasks to those nodes?

  1. --label 'node.labels.disktype=ssd'
  2. --constraint 'node.labels.disktype==ssd' Correct answer.
  3. --placement 'disktype==ssd'
  4. --reserve-node 'disktype=ssd'

Explanation

`--constraint` takes expressions matched against node attributes, using forms such as `node.labels.<key>==<value>`, `node.role==manager` or `node.hostname==...`. A task is only placed on a node for which every constraint expression evaluates to true.

Question 14Orchestration

Which statement about a swarm secret created with `docker secret create` is true?

  1. Any container on any node can read it by mounting it
  2. It is encrypted in the Raft log and sent only to nodes that need it Correct answer.
  3. It is written to /var/lib/docker/secrets in plaintext on every manager
  4. Its plaintext value is shown by `docker secret inspect`

Explanation

The secret value is encrypted at rest inside the Raft log and delivered over TLS only to nodes running a task that references it. `docker secret inspect` returns metadata such as ID, name and timestamps but never the value.

Question 15Orchestration

How does a task on an overlay network reach another service by that service's name?

  1. The name is resolved through the node's /etc/hosts file
  2. Each task broadcasts an ARP request for the service name
  3. The swarm DNS resolves the name to a load-balanced virtual IP Correct answer.
  4. The name is published as an environment variable holding a container IP

Explanation

Each container gets an embedded DNS resolver that knows about swarm services; a service name resolves to the service's virtual IP, and the virtual IP load-balances connections across healthy tasks. The DNS entry is kept current as tasks are rescheduled.

Question 16Orchestration

A service is published with `--publish mode=host,published=8080,target=80`. What does that mean for clients?

  1. Port 8080 is exposed only inside the overlay network, not on the host
  2. Every node accepts traffic on 8080 and forwards it to a task
  3. Only nodes running a task of the service accept traffic on 8080 Correct answer.
  4. Only manager nodes accept traffic on 8080 and proxy it to workers

Explanation

`mode=host` bypasses the routing mesh and binds the published port directly in the task's network namespace, so only nodes that run a task listen on 8080. The port must be free on those nodes, and an external load balancer is normally placed in front.

Question 17Orchestration

Which command deletes the stack `web` together with the services and networks it created?

  1. docker service rm web
  2. docker stack down web
  3. docker stack delete web
  4. docker stack rm web Correct answer.

Explanation

`docker stack rm` removes every service belonging to the stack plus the networks, secrets and configs the stack created, as long as they are not declared external. Objects that existed before the stack was deployed are left alone.

Question 18Orchestration

What does initialising a swarm with `docker swarm init --autolock` change?

  1. The Raft log is written to disk without encryption
  2. Restarted managers stay locked until the unlock key is supplied Correct answer.
  3. Workers must present a TLS token every time they run a task
  4. Services cannot be created until a manager has been unlocked

Explanation

Autolock means the manager's Raft log is encrypted at rest and the key is not kept on disk, so a restarted manager must be unlocked with `docker swarm unlock` before it can participate. Service operations run normally once the node is unlocked.

Question 19Orchestration

Which `update_config` setting starts each new task before stopping the old one, so the service does not fall below its replica count during an update?

  1. order: stop-first
  2. order: start-first Correct answer.
  3. parallelism: 1
  4. failure_action: rollback

Explanation

`update_config.order` accepts `stop-first` (the default) or `start-first`. With start-first the replacement task is launched before the old task is removed, which avoids downtime but requires spare capacity on the nodes.

Question 20Orchestration

Which flag makes `docker service create` wait until the service has converged instead of returning immediately?

  1. --detach=false Correct answer.
  2. --block
  3. --sync
  4. --wait

Explanation

`docker service create` runs detached by default; setting `--detach=false` makes the CLI stream progress and block until the service converges or a failure is reported. This is useful in scripts that must know the rollout succeeded.

Question 21Orchestration

A swarm runs four manager nodes. How many of them can fail while the swarm still keeps a Raft quorum?

  1. 0
  2. 3
  3. 2
  4. 1 Correct answer.

Explanation

A Raft quorum is a strict majority, calculated as floor(n/2)+1, so four managers need three available members and tolerate only one failure. That is the same fault tolerance as three managers, which is why even manager counts are discouraged.

Question 22Orchestration

In a three-manager swarm, two managers are permanently lost and the survivor reports that it is not part of a quorum. How can the cluster be recovered?

  1. Run `docker node rm --force` for each lost manager on the survivor
  2. Run `docker swarm init` on a new host and join the survivor to it
  3. Run `docker swarm init --force-new-cluster` on the survivor node Correct answer.
  4. Run `docker swarm unlock` on the survivor to reset the Raft log

Explanation

`--force-new-cluster` makes the surviving manager the only member of a new swarm built from its current state, which recreates the Raft membership with a size it can satisfy. The other nodes can then rejoin or be re-promoted. Administrative actions that merely delete node records do not restore quorum.

Question 23Orchestration

All four replicas of a service stay in the `pending` state and `docker service ps` reports 'no suitable node'. The service was created with `--constraint node.labels.zone==eu`. What is the most likely cause?

  1. The overlay network used by the service has not converged
  2. No node in the swarm carries the label `zone=eu` Correct answer.
  3. The image cannot be pulled on the worker nodes
  4. The service exceeds the maximum number of replicas per node

Explanation

Constraints are evaluated against node labels when the scheduler looks for a placement, so if no node matches, every task stays pending with 'no suitable node'. The fix is to label a node or relax the constraint, not to investigate images or networking.

Question 24Orchestration

A service is updated with `--update-failure-action pause`, and one new task fails to start during the rollout. What happens to the service?

  1. The update continues on the remaining tasks and reports the failure at the end
  2. The update halts and old and new tasks stay mixed until an operator acts Correct answer.
  3. The failed task is retried automatically until the update succeeds
  4. The service is automatically rolled back to its previous specification

Explanation

`update_config.failure_action` accepts `pause` (the default), `continue` or `rollback`. With `pause` the rollout stops where it is, leaving a partially updated service until an operator fixes the problem or runs `docker service update --rollback`.

Question 25Orchestration

A global service runs on every node of the swarm. One node is set to availability `drain`. What happens to the service's task on that node?

  1. It is shut down and not rescheduled until the node is active again Correct answer.
  2. The task keeps running but stops receiving routing-mesh traffic
  3. A replacement task is started on the drained node after a short delay
  4. The task keeps running because global services ignore availability

Explanation

Draining a node evicts every task on it, including tasks of global services, and the scheduler will not place new global tasks there while the node is unavailable. The task returns only when the node's availability is set back to `active`.

Question 26Orchestration

A swarm has one manager and two worker nodes. Which command turns the worker `node2` into a manager?

  1. docker swarm join-token manager
  2. docker node promote node2 Correct answer.
  3. docker node update --availability active node2
  4. docker node ls --filter role=manager

Explanation

`docker node promote` changes an existing worker's role to manager and demotes are done with `docker node demote`. The node must already be a member of the swarm, so no join token or re-registration is involved. `docker node update --role manager` is an equivalent alternative, but it is not among the options offered.

Question 27Orchestration

You need the exact command line that a new worker machine must run to join an existing swarm. Which command produces it?

  1. docker swarm join-token worker Correct answer.
  2. docker node ls --filter role=worker
  3. docker swarm init --force-new-cluster
  4. docker node inspect self --pretty

Explanation

`docker swarm join-token worker` (and `join-token manager`) prints the full `docker swarm join --token ... <manager-ip>:2377` string for the requested role. The token itself is an identifier; the printed line already includes the manager's advertise address. Tokens can be rotated later with `docker swarm join-token --rotate`.

Question 28Orchestration

Which command lists the services that were created by the stack named `web`?

  1. docker stack ps web
  2. docker stack services web Correct answer.
  3. docker service ls --stack web
  4. docker stack ls --services

Explanation

`docker stack services <stack>` shows every service that carries the stack's namespace label, together with replica counts and ports. Filtering by stack from the service command is done with `--filter label=com.docker.stack.namespace=web`, because `docker service ls` has no `--stack` flag. `docker stack ps` shows the tasks, not the service objects.

Question 29Orchestration

A service is created with `--endpoint-mode dnsrr`. How do other containers reach its tasks?

  1. Through a proxy process running on a manager node
  2. Through a virtual IP that the swarm load balances across tasks
  3. Directly, because DNS returns the address of every task Correct answer.
  4. Through the ingress routing mesh on the published port

Explanation

With DNS round-robin (`dnsrr`) the service name resolves to the IP addresses of the individual tasks, and the client's own resolver picks one. The default `vip` mode instead resolves the name to a single virtual IP that the kernel-level load balancer fans out to tasks. Because there is no VIP, clients see task addresses and must handle failover themselves.

Question 30Orchestration

An existing node is set to availability `pause`. What is the effect on that node?

  1. Running tasks are stopped and rescheduled elsewhere
  2. The node stops taking part in Raft consensus voting
  3. The node is removed from the swarm after a grace period
  4. New tasks are not placed there; running tasks stay Correct answer.

Explanation

`pause` marks a node as unschedulable for new tasks while leaving any tasks that are already running in place. Only `drain` evicts existing tasks and reschedules them onto other nodes. Neither setting changes the node's membership or role in the swarm.

Question 31Orchestration

Which statement about a swarm config created with `docker config create` is true?

  1. It is mounted into the container as a read-only file Correct answer.
  2. It is visible only to tasks running on manager nodes
  3. It is stored encrypted in the Raft log, exactly like a secret
  4. It can be edited in place by a running service

Explanation

Configs are delivered to a task's filesystem as files under `/<config-name>` by default and are mounted read-only, like secrets. Unlike secrets, configs are not encrypted at rest in the Raft log, so they suit non-sensitive data such as configuration files. A config is also immutable: changing it means creating a new config and updating the service to reference it.

Question 32Orchestration

A service is created with no `--restart-condition` flag, and one of its tasks exits with status 0. What happens next?

  1. The service is paused until an operator resumes it
  2. The task is not restarted, because a zero exit means success
  3. The task is restarted, since the default condition is `any` Correct answer.
  4. The whole service is rolled back to the previous spec

Explanation

The default restart condition is `any`, so a task is restarted even when its container exits successfully. `on-failure` restarts only on a non-zero exit code, and `none` never restarts. Restart policy is configured per service at creation or update time.

Question 33Orchestration

A service is created with `--placement-pref spread=node.labels.zone` and the swarm's nodes are distributed unevenly across three zones. What is the result?

  1. Tasks are balanced as evenly as possible across the three zones Correct answer.
  2. Each node is allowed to run at most one task of the service
  3. Tasks are refused on nodes that do not carry a zone label
  4. Each task is pinned to the zone its image layer was pulled from

Explanation

A placement preference spreads tasks across the distinct values of the given node label, so with three zones the scheduler aims for roughly equal task counts per zone rather than per node. Preferences are best-effort and never block scheduling, unlike constraints. `replicas-max-per-node` is the setting that caps tasks per node.

Question 34Orchestration

An overlay network is created with `docker network create --driver overlay --opt encrypted`. What does this option protect?

  1. Calls made to the Docker API over the manager socket
  2. Raft traffic between manager nodes
  3. Application traffic between tasks on different hosts Correct answer.
  4. Secret values stored in the swarm's Raft log

Explanation

The `encrypted` option turns on IPSec encryption for the data plane of that overlay network, so container-to-container packets crossing host boundaries are encrypted. Control-plane traffic between managers is already protected separately by Raft/TLS and is not affected by this option. Secrets at rest are handled by swarm secret encryption, not by network options.

Question 35Image Creation, Management, and Registry

Which Dockerfile instruction defines the base image that a build stage starts from?

  1. BASE
  2. PARENT
  3. FROM Correct answer.
  4. IMAGE

Explanation

FROM initializes a build stage and names the image the stage starts from, for example FROM ubuntu:22.04. Every Dockerfile must contain at least one FROM, and only ARG may appear before it.

Question 36Image Creation, Management, and Registry

Which command builds the Dockerfile in the current directory and names the resulting image myapp:1.0?

  1. docker run -t myapp:1.0 .
  2. docker build -t myapp:1.0 . Correct answer.
  3. docker create -t myapp:1.0 .
  4. docker image -t myapp:1.0 .

Explanation

docker build reads the build context and Dockerfile, and the -t flag assigns the repository:tag name to the produced image. The trailing dot sets the build context to the current directory.

Question 37Image Creation, Management, and Registry

When a tag is omitted, as in docker pull nginx, which tag does Docker use?

  1. main
  2. latest Correct answer.
  3. stable
  4. default

Explanation

Docker assumes the tag latest whenever a reference has no explicit tag, so docker pull nginx is identical to docker pull nginx:latest. The same rule applies to docker build, docker run and docker tag.

Question 38Image Creation, Management, and Registry

Which file at the root of the build context lists paths that should be excluded from what is sent to the daemon?

  1. Dockerfile.exclude
  2. .dockerignore Correct answer.
  3. .gitignore
  4. .buildignore

Explanation

A .dockerignore file in the context root is read by the client and excluded paths are not transmitted to the daemon. This keeps contexts small and prevents files such as local secrets or VCS data from entering the build.

Question 39Image Creation, Management, and Registry

Which command lists an image's layers together with the instruction that created each one and the size it added?

  1. docker inspect myapp:1.0
  2. docker history myapp:1.0 Correct answer.
  3. docker diff myapp:1.0
  4. docker layers myapp:1.0

Explanation

docker history shows one row per layer with the corresponding Dockerfile instruction, the command that produced it and the space it consumes. It is the usual first step when tracking down oversized layers.

Question 40Image Creation, Management, and Registry

Which Dockerfile instruction records that the containerized process listens on port 8080?

  1. EXPOSE 8080 Correct answer.
  2. PORT 8080
  3. LISTEN 8080
  4. PUBLISH 8080

Explanation

EXPOSE 8080 writes metadata into the image stating that the container listens on 8080/tcp. It documents the port but does not publish it; publishing requires -p or --publish at run time.

Question 41Image Creation, Management, and Registry

Which command deletes dangling images?

  1. docker system df
  2. docker image rm
  3. docker container prune
  4. docker image prune Correct answer.

Explanation

docker image prune removes dangling images, meaning untagged layers that no image reference and no container uses. Adding -a widens the operation to every image not used by an existing container.

Question 42Image Creation, Management, and Registry

By default, where does docker login persist registry credentials?

  1. ~/.docker/config.json Correct answer.
  2. ~/.docker/credentials.json
  3. /etc/docker/passwd
  4. /var/lib/docker/auth

Explanation

docker login writes a base64-encoded auth entry into the auths section of the user's ~/.docker/config.json. If a credential helper such as secretservice or pass is configured, the credential is stored in that external store instead.

Question 43Image Creation, Management, and Registry

What is the main benefit of a multi-stage build?

  1. Only copied artifacts end up in the final image Correct answer.
  2. Each stage is pushed to the registry as a separate tag
  3. Build stages run in parallel, so builds finish sooner
  4. Intermediate stages are cached on the daemon for reuse

Explanation

A multi-stage Dockerfile declares several FROM stages, but only the files copied forward with COPY --from=<stage> reach the final stage. Compilers, package managers and other build-only tooling stay behind in the earlier stages.

Question 44Image Creation, Management, and Registry

Which ordering best preserves build cache when containerizing a Node.js application?

  1. Run npm install before any files are copied into the image
  2. Copy package.json, run npm install, then copy the source Correct answer.
  3. Copy all source files first, then run npm install
  4. Install dependencies and start the app in one RUN step

Explanation

Docker keys each layer's cache on the instruction and the checksum of the files copied by it. Copying only the dependency manifest first means npm install is reused until that manifest changes, so ordinary source edits do not trigger a full reinstall.

Question 45Image Creation, Management, and Registry

How does ADD differ from COPY?

  1. ADD preserves ownership; COPY resets it to root
  2. ADD is only allowed inside multi-stage builds
  3. ADD also unpacks local tar archives and fetches URLs Correct answer.
  4. ADD creates a new layer per file; COPY does not

Explanation

COPY transfers files from the build context verbatim. ADD performs the same transfer but additionally extracts recognized local tar archives into the image and can download content from a remote URL.

Question 46Image Creation, Management, and Registry

Which pair of commands writes an image to a tar file and restores it later with all layers and metadata intact?

  1. docker save / docker load Correct answer.
  2. docker push / docker pull
  3. docker export / docker import
  4. docker commit / docker load

Explanation

docker save serializes an image including every layer, its history and its configuration, and docker load reads that archive back. docker export instead flattens a container's filesystem and discards image metadata.

Question 47Image Creation, Management, and Registry

A local image is already tagged devops/app:1.0. Which command publishes it to Docker Hub?

  1. docker upload devops/app:1.0
  2. docker publish devops/app:1.0
  3. docker save devops/app:1.0
  4. docker push devops/app:1.0 Correct answer.

Explanation

docker push sends the image to the registry embedded in its reference; for a bare repository name that registry is Docker Hub. The user must be authenticated first, and the reference must already carry the target repository and tag.

Question 48Image Creation, Management, and Registry

Which statement correctly contrasts ARG with ENV?

  1. Both ARG and ENV are available only during the build
  2. ARG applies only at build time; ENV persists at runtime Correct answer.
  3. ENV must be declared before FROM, ARG cannot be
  4. ARG values persist in the running container; ENV values do not

Explanation

ARG defines a variable that exists only while the image is being built and can be supplied with --build-arg. ENV defines a variable that is written into the image configuration and is therefore present in every container started from it.

Question 49Image Creation, Management, and Registry

A Dockerfile contains WORKDIR /app but nothing has created /app. What happens?

  1. The build fails because the directory must already exist
  2. It creates /app and uses it for subsequent instructions Correct answer.
  3. It mounts an anonymous volume at /app
  4. It only sets a shell variable for later RUN steps

Explanation

WORKDIR sets the directory used by later RUN, CMD, ENTRYPOINT, COPY and ADD instructions and creates it if it is missing. Using WORKDIR is preferred over chaining cd inside RUN commands.

Question 50Image Creation, Management, and Registry

An image declares ENTRYPOINT ["/app/server"] and CMD ["--port","8080"]. What process runs for docker run myimage --port 9090?

  1. /app/server --port 8080 --port 9090
  2. /app/server --port 9090 Correct answer.
  3. The container fails because CMD cannot be overridden
  4. --port 9090 replaces the ENTRYPOINT entirely

Explanation

Arguments given on the docker run command line replace the image's CMD and are appended to an exec-form ENTRYPOINT. The default CMD is discarded, so the resulting process is /app/server --port 9090.