DevOpsMarch 20, 202617 min read

7 Things the Docker DCA Exam Tests That You Probably Don't Use Daily

Maintained by the ExamCert editorial team • About our team

Plus 40+ free practice questions to find out where you actually stand.

You run docker build and docker run fifty times a week. You've written Dockerfiles in your sleep. But can you explain how Docker content trust works? Or design a multi-manager Swarm cluster with proper quorum? Yeah, me neither — until I had to study for the DCA.

The Docker Certified Associate (DCA) exam is sneaky. About 60% of it covers stuff you probably already know from daily work. The other 40%? Swarm orchestration details, Docker Enterprise features, security configurations, and networking internals that most developers never touch.

Docker DCA practice test with container and DevOps concepts

Here are the 7 things that tripped me up — and practice questions to test whether they'd trip you up too.

1. Docker Swarm Orchestration (Most People's Weak Spot)

Unless your company is one of the few still running Docker Swarm in production, you probably haven't thought about Swarm mode since 2019. Bad news: it's roughly 25% of the exam.

What You Need to Know

  • Manager quorum — odd numbers of managers, fault tolerance formula: (N-1)/2
  • Service types — replicated vs. global services
  • Rolling updates — parallelism, delay, failure action, rollback
  • Secrets and configs — how they're stored, accessed, and rotated
  • Drain, pause, active states — node availability management

Question 1: A Docker Swarm cluster has 5 manager nodes. What is the maximum number of manager failures the cluster can tolerate?

A. 1
B. 3
C. 2
D. 4
Answer: C. The formula is (N-1)/2. With 5 managers: (5-1)/2 = 2. You need a majority (quorum) to maintain cluster operations, so 3 of 5 managers must be healthy. This is why Docker recommends 3, 5, or 7 managers — always odd numbers. Even numbers give you no advantage (4 managers still only tolerates 1 failure).

Question 2: What is the difference between a replicated service and a global service in Docker Swarm?

A. A replicated service runs a specified number of replicas; a global service runs one instance on every node
B. A global service runs across multiple Swarm clusters; a replicated service runs in one cluster
C. A replicated service uses more resources than a global service
D. There is no functional difference; they are aliases
Answer: A. A replicated service lets you specify how many task replicas to run (e.g., 3 replicas), and Swarm distributes them across available nodes. A global service automatically runs exactly one task on every node in the Swarm — useful for monitoring agents, log collectors, or antivirus scanners. New nodes automatically get a global service task.

Question 3: How do you update a running service's image without downtime using Docker Swarm?

A. docker service stop && docker service start
B. docker service restart --image new-image:tag
C. docker service rm && docker service create
D. docker service update --image new-image:tag service-name
Answer: D. docker service update --image triggers a rolling update that replaces containers one batch at a time based on the configured update parallelism and delay. This ensures zero downtime. The other options either don't exist as valid commands or would cause downtime by removing the service entirely.

2. Docker Networking Internals

You use bridge networks every day without thinking about it. But the DCA expects you to understand all the network drivers and when to use each one.

The Network Drivers You Need to Know

  • bridge — default for standalone containers. NAT-based isolation.
  • host — container shares the host's network namespace. No isolation.
  • overlay — multi-host networking for Swarm services. Encrypted with --opt encrypted.
  • macvlan — gives containers their own MAC address. Appears as a physical device on the network.
  • none — no networking. Container is completely isolated.

Question 4: Which Docker network driver should you use to allow containers on different hosts to communicate in a Swarm cluster?

A. bridge
B. overlay
C. host
D. macvlan
Answer: B. Overlay networks span across multiple Docker hosts, which is exactly what Swarm needs. They use VXLAN encapsulation to create a virtual network on top of the physical network. Bridge networks are limited to a single host. Host networking bypasses Docker networking entirely. Macvlan could work across hosts but isn't designed for Swarm service discovery.

Question 5: What happens when you create a container with the --network host option?

A. The container gets its own isolated network namespace with host-like permissions
B. The container can only communicate with the host, not other containers
C. The container shares the host's network namespace directly
D. Docker creates a virtual bridge between the container and host
Answer: C. With --network host, the container uses the host's network stack directly. No port mapping needed — if the container listens on port 80, it's port 80 on the host. This eliminates network overhead but sacrifices isolation. Useful for performance-critical applications where the NAT overhead of bridge networking is unacceptable.

3. Docker Security (Content Trust, Secrets, Scanning)

Security is about 15% of the DCA and it's the area where hands-on experience is rarest. Most developers don't configure Docker Content Trust or set up image scanning in their daily workflow.

Key Security Concepts

  • Docker Content Trust (DCT) — cryptographically signs images for integrity verification
  • Docker secrets — encrypted secret storage in Swarm (files mounted into containers)
  • User namespaces — remapping container root to non-root on the host
  • seccomp profiles — limiting syscalls available to containers
  • Read-only filesystem — --read-only flag

Question 6: What does enabling Docker Content Trust (DCT) do?

A. Only signed images can be pulled and run
B. All container traffic is encrypted
C. Images are automatically scanned for vulnerabilities
D. Docker daemon requires TLS authentication
Answer: A. Docker Content Trust uses digital signatures (based on The Update Framework/TUF) to verify image integrity and publisher identity. When DCT is enabled (DOCKER_CONTENT_TRUST=1), Docker will only pull and run images that have been signed. It doesn't encrypt traffic (that's TLS), scan images (that's a scanning tool), or handle daemon authentication.

Question 7: How are Docker secrets made available to a container in Swarm mode?

A. As environment variables
B. As files mounted in /run/secrets/
C. Via the Docker API only
D. Stored in a Docker volume
Answer: B. Docker secrets are mounted as files in the /run/secrets/ directory inside the container. They're stored encrypted in the Swarm Raft log, transmitted encrypted to worker nodes, and mounted as tmpfs (in-memory) — never written to disk on the worker. This is more secure than environment variables, which can leak via logs, process listings, and child processes.

4. Storage and Volumes

You probably use volumes. But do you know the difference between volumes, bind mounts, and tmpfs mounts? The DCA cares about these distinctions.

Question 8: Which storage option is BEST for persisting data generated by a Docker container?

A. Writing to the container's writable layer
B. Using a bind mount to a host directory
C. Using a Docker volume
D. Using a tmpfs mount
Answer: C. Docker volumes are the recommended way to persist container data. They're managed by Docker, work on both Linux and Windows, can be shared between containers, and support volume drivers for remote storage. Bind mounts depend on the host's directory structure. The writable layer is lost when the container is removed. Tmpfs is in-memory and also lost when the container stops.

Question 9: What is the purpose of a multi-stage Dockerfile build?

A. To run multiple containers from one Dockerfile
B. To build images for multiple architectures
C. To enable parallel image building
D. To reduce the final image size by separating build and runtime stages
Answer: D. Multi-stage builds use multiple FROM statements in a single Dockerfile. You compile/build in an early stage (with all build tools), then copy only the final artifacts to a lean runtime image. This dramatically reduces image size — a Go application built in a multi-stage Dockerfile might go from 800MB (with build tools) to 15MB (just the binary in scratch/alpine).

5. Image Management & Registry

Beyond docker pull and docker push, the DCA tests deeper image management concepts.

Question 10: What is the correct command to tag a local image for pushing to a private registry at registry.example.com?

A. docker tag myapp:latest registry.example.com/myapp:latest
B. docker push myapp:latest --registry registry.example.com
C. docker image rename myapp:latest registry.example.com/myapp:latest
D. docker tag --target registry.example.com myapp:latest
Answer: A. To push to a private registry, you first tag the image with the registry's address as a prefix: docker tag myapp:latest registry.example.com/myapp:latest. Then docker push registry.example.com/myapp:latest. Docker uses the image name's prefix to determine which registry to push to. The other command syntaxes don't exist.

6. Docker Compose & Stack Files

Docker Compose is for development. Docker Stack is Compose for Swarm. The DCA tests both, and the differences matter.

Key Differences

  • Compose uses docker-compose up — runs on a single host, supports build: directive
  • Stack uses docker stack deploy — runs on Swarm, ignores build:, supports deploy: key
  • Stack files use the same YAML format but different features are supported

Question 11: Which Compose file key is ONLY supported in Docker Stack deployments (not docker-compose up)?

A. build
B. deploy
C. volumes
D. networks
Answer: B. The deploy key (which includes replicas, resources, restart_policy, placement, update_config) is only used by docker stack deploy and ignored by docker-compose up. Conversely, build is only used by docker-compose and ignored by docker stack. Volumes and networks work in both contexts.

7. Docker Enterprise & DTR (Yes, Still on the Exam)

Here's an unpopular opinion: Docker Enterprise (now Mirantis Kubernetes Engine) is still tested on the DCA, and it probably shouldn't be. But it is, so you need to know the basics.

What You Need to Know

  • UCP (Universal Control Plane) — web-based management UI for Swarm and Kubernetes
  • DTR (Docker Trusted Registry) — private image registry with security scanning
  • RBAC — role-based access control in UCP
  • Client bundles — how users authenticate to UCP from CLI

Question 12: What is the purpose of a UCP client bundle?

A. To install Docker Engine on client machines
B. To distribute application configuration to containers
C. To provide TLS certificates and environment variables for CLI authentication to UCP
D. To bundle multiple Docker images for offline deployment
Answer: C. A UCP client bundle contains TLS certificates (ca.pem, cert.pem, key.pem) and environment configuration that lets users run docker and kubectl commands against the UCP cluster from their local machine. When you source the bundle's env.sh, it sets DOCKER_HOST, DOCKER_TLS_VERIFY, and DOCKER_CERT_PATH to authenticate your CLI session.

DCA Exam Quick Reference

DetailDocker DCA
Questions55 questions
Time90 minutes
FormatMultiple choice + DOMC (Discrete Option Multiple Choice)
Cost$195 USD
Passing Score~65% (not officially published)
Validity2 years

DCA vs CKA: The Real Talk

Everyone asks this. Here's my honest take:

If your goal is maximum job market value, get the CKA (Certified Kubernetes Administrator). Kubernetes is where the industry went. Most job postings asking for container expertise want Kubernetes skills.

If your goal is proving strong container fundamentals, get the DCA first. Docker is the foundation everything else is built on. Understanding Docker deeply makes Kubernetes, Podman, containerd — everything — easier to learn.

My recommendation? DCA first, then CKA. Takes about 3 months total if you're focused. The Docker knowledge transfers directly to Kubernetes container runtime concepts.

Study Resources That Work

  • ExamCert Docker DCA Practice Exam — free scenario-based questions covering all domains
  • Docker official documentation — comprehensive and well-written. Read the networking, storage, and security sections.
  • Docker DCA Complete Guide — our full breakdown of the certification
  • Hands-on labs — Play with Docker (play-with-docker.com) for free Swarm cluster practice
  • Docker DCA Exam Guide 2026 — updated tips and exam format info

Frequently Asked Questions

How many questions are on the Docker DCA exam?

The Docker DCA exam has 55 questions. You get 90 minutes to complete it. Questions include multiple choice and DOMC (Discrete Option Multiple Choice) format where you see one option at a time.

Is the Docker DCA exam hard?

Moderate difficulty. If you use Docker daily, you know about 60% of the material already. The remaining 40% covers Swarm orchestration, Enterprise features, and security topics that most people don't use in day-to-day work.

Docker DCA vs CKA: which should I get?

If your company uses Kubernetes (most do now), get CKA. For maximum marketability, CKA has more job postings. But DCA proves stronger container fundamentals and is faster to prepare for.

How long should I study for Docker DCA?

With daily Docker experience: 3-4 weeks. Without much Docker experience: 6-8 weeks. Focus on Swarm orchestration and Docker security, as these are the most commonly missed topics.

Is the Docker DCA certification still relevant in 2026?

Yes, but with caveats. Containers are everywhere, and Docker is the foundation. Most enterprise orchestration has moved to Kubernetes, but Docker DCA validates strong container fundamentals that transfer to any platform. Pair it with a broader container certification path.

Practice Docker DCA Questions Free

Test your container knowledge with real exam-style questions and detailed explanations across all DCA domains.

Start Free DCA Practice Test

Plan Your Container Certification Path

Use our free tools to map your journey