The certification Docker kept when the landscape consolidated

When Mirantis acquired Docker Enterprise in 2019, industry observers predicted the DCA would fade alongside Docker’s commercial products. The opposite happened. Container adoption accelerated, Kubernetes became the dominant orchestrator, and Docker’s role shifted from a platform-level competitor to a foundational layer that every Kubernetes practitioner depends on. The DCA found its permanent place as the credential that validates the container-level skills that CKA and CKAD assume you already have — Dockerfile authoring, image management, registry operations, networking models, volume lifecycle, and container security.

In 2026 the DCA is administered through Mirantis certification channels and is available as a remote-proctored exam. The credential is valid for two years from the date of passing. Unlike AWS or Kubernetes certification pathways, there is no associate-to-professional track — the DCA is a standalone professional credential. Engineering managers across cloud-native and platform engineering organisations consistently cite it as the most credible signal that a candidate has real, hands-on container expertise rather than theoretical familiarity with container concepts.

The DCA’s positioning relative to Kubernetes certifications is important to understand before deciding whether to pursue it. The CKA (Certified Kubernetes Administrator) and CKAD (Certified Kubernetes Application Developer) test Kubernetes orchestration at the cluster and application levels respectively. The DCA tests the container runtime and image layer beneath Kubernetes. Engineers who operate Kubernetes at scale frequently discover that their understanding of the Docker layer is shallower than they assumed — image layer caching, multi-stage build efficiency, registry authentication flows, network namespace behaviour, and volume mount semantics are all DCA domain knowledge that surfaces as day-two operational issues in Kubernetes environments.

The six DCA domains

Domain 1 — Orchestration (25%)

The heaviest domain by exam weight reflects the central importance of coordinating container workloads across multiple hosts. The DCA tests Docker Swarm as the orchestration layer — this is the key distinction from CKA, which tests Kubernetes. Swarm remains in production at organisations with simpler orchestration requirements, and the exam tests its design and operation comprehensively.

  • Docker Swarm mode: initialising a swarm with docker swarm init, joining worker and manager nodes, and understanding the quorum requirements that make a swarm cluster fault-tolerant. Manager nodes use the Raft consensus algorithm; a swarm with three managers tolerates one manager failure, five managers tolerates two. DCA questions regularly probe the relationship between manager count and fault tolerance.
  • Services and stacks: docker service create defines a replicated or global service across swarm nodes; docker stack deploy deploys multi-service applications defined in a Compose file. The exam tests service update strategies (rolling updates with --update-parallelism and --update-failure-action), rollback procedures, and drain/pause operations on nodes during maintenance windows.
  • Scheduling and placement: placement constraints (--constraint) and placement preferences (--placement-pref) direct where service tasks land within the swarm. The DCA tests the difference between hard constraints (a service will not schedule without a matching node) and soft preferences (the scheduler spreads tasks across matching node groups but tolerates failure to do so).
  • Health checks and self-healing: services maintain desired replica counts by rescheduling failed tasks on healthy nodes. The exam tests how health checks defined in a Dockerfile or service spec determine task health, how failed tasks trigger rescheduling, and how the --restart-condition flag controls when a task is considered permanently failed versus transiently failed.
  • Secrets and configs: docker secret create stores sensitive data in the Raft log and makes it available to service tasks at /run/secrets/<secret_name> — never in environment variables. Configs provide non-sensitive configuration files to services without baking them into images. The DCA tests the security model of secrets (encrypted at rest in the Raft log, only decrypted on worker nodes running tasks that need them) versus the weaker but still useful config mechanism.

Domain 2 — Image Creation, Management, and Registry (20%)

The image layer is where container expertise begins. The DCA tests the full lifecycle from Dockerfile authoring through image distribution — the knowledge that separates engineers who understand how containers work from those who only know how to run them.

  • Dockerfile best practices: multi-stage builds reduce final image size by using a full build environment in an early stage and copying only the compiled artifact to a minimal runtime image. Layer caching behaviour determines build performance — instructions that change frequently (COPY of application code) should appear after instructions that change rarely (RUN apt-get install) to maximise cache hit rate. The DCA tests the order of Dockerfile instructions as a performance question, not just a syntax question.
  • Image tagging and versioning: the :latest tag is mutable by default, making it unsuitable for production deployments that require reproducibility. The DCA tests tagging strategies that combine semantic versioning with commit SHAs or build numbers to provide both human readability and reproducibility. docker image tag, docker image push, and the relationship between repository, image name, and tag are foundational.
  • Registry operations: Docker Hub, Docker Trusted Registry (DTR, now Mirantis Secure Registry), and compatible third-party registries (AWS ECR, Azure ACR, GCR). The DCA tests authentication (docker login), push and pull operations across private registries, and the registry API concepts underlying those operations. Image signing with Docker Content Trust (DCT) provides supply-chain security by ensuring only signed images are pulled — the DCA tests enabling DCT and its impact on pull behaviour.
  • Image inspection and layer analysis: docker image inspect surfaces the full image metadata including environment variables, entrypoint, exposed ports, and layer digests. docker image history shows the commands that produced each layer and their sizes — critical for identifying bloated layers introduced by inefficient Dockerfile instructions. Understanding the union filesystem mechanics that compose layers into a container filesystem is testable at a conceptual level.
  • Pruning and space management: docker image prune removes dangling images (layers not referenced by any tag); docker system prune cleans up stopped containers, dangling images, unused networks, and (with --volumes) unused volumes. The DCA tests the scope of each prune command and the flags that expand or limit what is removed.

Domain 3 — Installation and Configuration (15%)

The operational foundation of Docker environments: installing and configuring the Docker Engine on Linux and understanding the daemon configuration options that determine how Docker behaves in production environments.

  • Docker Engine installation: the DCA tests the recommended installation path (Docker’s package repository, not distribution-default packages which are often outdated) and the configuration of the Docker daemon via /etc/docker/daemon.json. Key daemon configuration options tested include the default logging driver, storage driver selection (overlay2 is the default and preferred driver on modern Linux kernels), and the daemon’s live restore capability (containers continue running when the daemon restarts).
  • Namespaces and cgroups: containers are isolated using Linux namespaces (PID, network, mount, UTS, IPC, user) and resource-constrained using cgroups. The DCA tests these at a conceptual level — what each namespace type isolates, and how cgroup limits on CPU and memory translate to docker run flags (--cpus, --memory). Understanding that containers share the host kernel while being namespace-isolated is the foundational concept.
  • Logging drivers: Docker supports multiple logging drivers including json-file (default, writes logs to the host filesystem), syslog, journald, fluentd, awslogs, and others. The DCA tests how to configure logging at the daemon level (default for all containers) or at the container level (overrides daemon default), and the trade-offs between local logging (simple, disk consumption risk) and forwarding drivers (operational complexity, no local storage).
  • Docker Context: contexts allow switching between multiple Docker endpoints — local daemon, remote SSH daemon, or Docker Desktop settings — without changing environment variables. The DCA tests creating, listing, and switching contexts as a configuration management topic. Context-based management is particularly relevant for engineers managing multiple environments (development, staging, production) from a single workstation.

Domain 4 — Networking (15%)

Container networking is one of the most misunderstood areas of Docker expertise and one of the most consequential for production reliability. The DCA tests both the networking models Docker supports and the practical implications of choosing between them.

  • Network drivers: bridge (default for standalone containers — creates a virtual network on the host), host (removes network isolation; container uses host networking stack directly), none (fully isolated, no networking), overlay (multi-host networking for swarm services, uses VXLAN encapsulation), and macvlan (assigns a MAC address from the host network to the container, useful for legacy applications expecting a direct physical presence on the network). The DCA tests when to use each driver and the security implications of each choice.
  • Container DNS: containers on user-defined bridge networks get automatic DNS resolution for other containers on the same network using container names as hostnames. Containers on the default bridge network do not get this automatic name resolution — they must use IP addresses or the legacy --link option. The DCA tests this distinction as a design consideration: user-defined networks are preferred over the default bridge network for exactly this reason.
  • Port publishing and service discovery: docker run -p 8080:80 publishes container port 80 to host port 8080. Swarm services use the routing mesh to publish ports across all swarm nodes — a request arriving at any node’s published port is load-balanced to a running service task, regardless of which node the task is on. The DCA tests the routing mesh behaviour and the difference between ingress (routing mesh) and host mode port publishing for swarm services.
  • Network inspection and troubleshooting: docker network inspect surfaces connected containers, their assigned IP addresses, and network driver configuration. The DCA tests using inspect output to diagnose connectivity issues — understanding which containers are on which networks and why two containers cannot reach each other (they are on different networks and no routing connects them) is a common scenario question.

Domain 5 — Security (15%)

Container security is the domain where the DCA most directly overlaps with security certifications, but its focus is container-specific: the mechanisms Docker provides for reducing the attack surface of containerised workloads, not general security principles.

  • Image security and content trust: Docker Content Trust (DCT) uses Notary to sign images, ensuring that pulled images were signed by a trusted publisher. Enabling DCT (export DOCKER_CONTENT_TRUST=1) prevents pulling unsigned images. The DCA tests DCT enablement, the roles involved in the signing workflow (root key, targets key, snapshot key), and the operational implications of operating with DCT enabled in a team environment where multiple engineers push images.
  • Capabilities and privilege: Linux capabilities allow fine-grained control over what privileged operations a container process can perform. By default, Docker drops a set of capabilities from containers and adds none that are not needed. The DCA tests --cap-add and --cap-drop as mechanisms for adjusting capabilities, the security risk of --privileged (grants all capabilities and removes seccomp restrictions — equivalent to root on the host), and why --privileged should never appear in production workloads.
  • Seccomp and AppArmor: seccomp profiles filter which system calls a container process can make, reducing the kernel attack surface. Docker applies a default seccomp profile that blocks over 40 system calls. The DCA tests how to apply custom seccomp profiles, how to disable seccomp (and why that is generally inadvisable), and how AppArmor profiles provide a complementary MAC layer on systems where AppArmor is available.
  • User namespaces and rootless containers: user namespace remapping maps container root (UID 0) to an unprivileged UID on the host, preventing a container breakout from yielding root access on the host. The DCA tests enabling user namespace remapping in the daemon configuration and its operational implications (volume permissions change because the host UIDs are different). Rootless Docker (running the daemon itself as a non-root user) provides defence-in-depth for environments where daemon compromise is a threat model.
  • Secrets management in Swarm: as covered in Domain 1, Docker secrets are stored encrypted in the Raft log and only decrypted in memory on worker nodes running tasks that require them. The DCA tests the security model relative to alternatives (environment variables, bind-mounted files) and why environment variables are a poor mechanism for secret distribution — they appear in docker inspect output, process listings, and crash dumps.

Domain 6 — Storage and Volumes (10%)

The smallest domain by exam weight but foundational to stateful container workloads. The DCA tests Docker’s three data persistence mechanisms and the trade-offs between them.

  • Volumes: Docker-managed volumes are the preferred mechanism for persistent data. Volumes are stored in a Docker-managed location (/var/lib/docker/volumes/ on Linux), are independent of the container lifecycle (data survives container deletion), and support volume drivers that back storage with NFS, cloud block storage, or other external systems. The DCA tests creating named volumes, mounting them into containers, and using volume drivers for production storage scenarios.
  • Bind mounts: bind mounts map a specific host filesystem path into a container. They are useful for development workflows (mounting source code into a container so the container sees live file changes) but introduce host-path coupling that makes them poorly suited for production deployments or swarm services. The DCA tests the distinction between volumes (portable, managed by Docker) and bind mounts (host-path specific, not portable across swarm nodes).
  • tmpfs mounts: tmpfs mounts store data in the host’s memory, never writing to disk. They are used for sensitive temporary data that must not persist to disk — session tokens, decrypted secrets processed during application startup. The DCA tests tmpfs as the correct choice when data must not survive a container restart and must not appear in disk forensics.
  • Storage drivers: the storage driver determines how image layers and the writable container layer are managed on the host filesystem. overlay2 is the recommended driver for modern Linux kernels and provides good performance and copy-on-write efficiency. The DCA tests storage driver selection as a configuration decision and understanding that writing to the container layer (as opposed to a mounted volume) is ephemeral and performance-constrained relative to volume-backed storage.

Exam format and preparation

The DCA consists of 55 questions delivered in a 90-minute proctored exam window, yielding approximately 98 seconds per question. Questions are multiple-choice and multiple-response scenario-based, testing applied knowledge rather than memorisation of command flags. The passing score is not publicly disclosed by Mirantis, but the exam is calibrated to separate practitioners with genuine hands-on experience from those who have only read documentation.

The preparation profile that consistently produces passing scores combines two elements: systematic domain study using the official Mirantis study guide and practice question banks, and hands-on lab work in a real Docker environment. Setting up a three-node Docker Swarm on cloud VMs or locally using VirtualBox, deploying multi-service stacks with secrets and configs, creating custom bridge networks, and exercising the full image build and push workflow are the lab exercises that translate most directly to exam readiness. Candidates who have operated Docker in production for six months or more at depth across all six domains typically require four to six weeks of focused exam preparation.

The most common DCA failure pattern: candidates who operate Docker daily but only within a narrow workflow. A backend engineer who builds and runs containers for development may have deep image-authoring skills but shallow swarm orchestration and security knowledge. The exam is intentionally broad across all six domains — the 25% orchestration weight and 15% security weight together represent 40% of the exam, and candidates who only work with standalone containers in development environments frequently underestimate both domains.

DCA in the container certification landscape

Understanding how the DCA relates to adjacent credentials prevents over-investment or under-investment relative to career goals:

Why it matters for cert candidates

The Docker DCA fills a specific gap in the container certification landscape: it validates container-level expertise that Kubernetes certifications assume but do not test. Engineers who hold CKA or CKAD and add DCA demonstrate command of the full container stack from runtime to orchestration. For candidates entering the container practitioner space, DCA is a strong first credential that provides a foundation for subsequent Kubernetes certifications. The official Mirantis DCA exam page contains the current domain breakdown, exam blueprint, and registration information.

Practice Docker Certified Associate exam questions — container runtime, Swarm orchestration, image management, networking, and security.

Practice DCA Questions →