Docker Certified Associate (DCA): Current Mirantis Exam and Practical Study Guide

The Docker Certified Associate (DCA) remains a current certification exam administered by Mirantis. That current status is important because older articles sometimes describe DCA as discontinued after changes in Docker’s enterprise business. Mirantis acquired Docker’s Enterprise Platform business in 2019 and continues to sell and administer the DCA exam. Its current exam page lists 13 multiple-choice questions plus 42 discrete-option multiple-choice questions in a 90-minute remotely proctored assessment.

DCA sits within the Mirantis certification ecosystem and validates practical Docker knowledge rather than only familiarity with container terminology. Mirantis recommends roughly six to twelve months of Docker experience. That guidance matches the nature of the subject: candidates need to understand how images, containers, networks, storage, security, and orchestration behave when they are used together.

The most effective preparation is therefore operational. Build images, run containers, inspect networking, persist data, manage registries, troubleshoot failures, and practice secure configuration. Docker commands matter, but knowing why a container cannot resolve a service name or why a volume behaves differently from a bind mount is more valuable than memorizing a command list.

Images and containers are related artifacts with different lifecycles

A Docker image is an immutable package of filesystem layers and metadata used to create containers. A container is a running or stopped instance created from an image with its own writable layer and runtime configuration. DCA candidates should be comfortable building images with Dockerfiles, understanding layers and caching, tagging images, inspecting image history, and managing container lifecycle operations.

Good image design also involves choosing appropriate base images, reducing unnecessary layers and packages, handling build-time versus runtime configuration, and avoiding secrets in image history. These practices matter because image content affects attack surface, portability, storage, and deployment speed. A candidate who can explain why a particular Dockerfile is inefficient or risky is better prepared than one who only knows the syntax of common instructions.

Networking questions become easier when traffic paths are explicit

Docker networking includes bridge networks, host networking, overlay concepts, service discovery, ports, published mappings, and communication between containers. Troubleshooting starts by separating several questions: is the application listening, is the container attached to the expected network, is name resolution working, and is the port published to the correct host interface?

Default bridge behavior differs from user-defined networks, especially around automatic DNS-based container name resolution. Candidates should practice creating networks, attaching and disconnecting containers, inspecting addresses, and testing reachability from both host and container perspectives. These skills also transfer naturally to orchestration because container networking becomes even more important when workloads span multiple nodes.

Persistent data requires deliberate storage choices

Containers are designed to be replaceable, so important application data should not depend on a container’s writable layer. DCA preparation should distinguish named volumes, bind mounts, and temporary storage and understand when each model is appropriate. Volumes are managed by Docker and are commonly used for persistent application data; bind mounts expose specific host filesystem paths and therefore create tighter coupling to the host.

Permissions, ownership, backup, migration, and host security all matter when persistent data is introduced. A database in a container is only operationally useful if its data can survive container recreation and be protected appropriately. This is a good example of why hands-on practice matters: storage behavior that seems simple in a diagram becomes much clearer after recreating containers and verifying which data persists.

Registries and image distribution connect development to operations

Docker workflows rely on registries to distribute images. Candidates should understand tags, repositories, authentication, image push and pull operations, and the trust implications of using public or private sources. Tags are references, not cryptographic guarantees that content will never change, so production processes often need stronger control over exactly which image digest is deployed.

Registry practices also intersect with vulnerability management and software supply-chain security. Teams should minimize unnecessary content, scan images, control who can publish, and avoid embedding credentials. These concerns link DCA to the broader Docker, Kubernetes, and DevOps landscape, where container packaging is only one stage of a delivery pipeline.

Security starts with reducing privilege and unnecessary exposure

Containers share a host kernel, so isolation is not the same as a full virtual-machine boundary. DCA candidates should understand basic runtime security, users inside containers, capabilities, secrets, network exposure, filesystem permissions, and the risks of privileged containers or mounting sensitive host paths. Running a workload as root when it does not require root expands the consequences of a compromise.

Security also includes controlling the Docker daemon because daemon access is highly privileged. Image provenance, patching, host hardening, resource limits, and secure configuration all contribute to the overall posture. A strong answer to a security scenario normally reduces unnecessary authority and exposure rather than adding one defensive product while leaving broad permissions intact.

Orchestration knowledge explains how containers become services

DCA has historically covered orchestration concepts because production container environments need scheduling, scaling, service discovery, health management, and rolling change. Docker Swarm concepts remain relevant to the Docker-specific certification, while Kubernetes is now the dominant orchestration platform in many organizations. The key is to understand why orchestration exists: individual container commands do not provide a complete multi-node application platform.

Learners who work heavily with Kubernetes can deepen that branch through CKA for administration or CKAD for application development. The Kubernetes administration material is especially useful for seeing how familiar container ideas expand into pods, controllers, services, storage classes, cluster networking, and policy.

Troubleshooting should be practiced as a sequence, not improvised under pressure

Many container problems can be diagnosed with a consistent flow. Confirm that the container exists and is running, inspect its logs, examine configuration and environment, validate mounts, inspect network attachments and ports, check resource constraints, and then test the application from the correct network perspective. This sequence prevents candidates from jumping directly to a complex cause when a simple configuration error explains the symptom.

Practice should include deliberately broken environments: wrong port mappings, missing environment values, failed health checks, inaccessible mounts, DNS mistakes, and images that exit immediately because their main process ends. Troubleshooting these cases builds the operational judgment that a certification like DCA is intended to validate.

Resource management is another practical area worth exercising. Containers can compete for CPU, memory, and storage I/O, and unrestricted consumption can affect neighboring workloads or the host itself. Candidates should understand why resource constraints exist, how container processes behave when limits are reached, and why operational monitoring matters. A service that starts successfully but exhausts memory under load is still an unreliable deployment.

Docker Compose is useful in preparation because it expresses a multi-container application as configuration rather than as a long series of commands. A simple web application, database, network, and volume can be recreated consistently, making relationships easier to inspect. Even when a particular exam question is not about Compose syntax, declarative composition helps reinforce dependency, networking, environment, storage, and lifecycle concepts in one repeatable lab.

Logging and observability should also be part of troubleshooting practice. Container stdout and stderr, Docker logs, inspect output, events, and host-level resource information each answer different questions. If a container repeatedly restarts, the candidate should be able to separate an application crash from an orchestration restart policy, a missing dependency, or a resource problem. Building that diagnostic habit is more transferable than memorizing isolated troubleshooting commands.

Finally, understand the boundary between Docker knowledge and Kubernetes specialization. DCA validates Docker-oriented container skills, while Kubernetes certifications go much deeper into cluster objects, scheduling, control-plane behavior, and Kubernetes-native networking and storage. The concepts reinforce each other, but they are not interchangeable credentials. Keeping that boundary clear helps candidates spend their study time on the actual DCA role while still seeing where container expertise can grow next.

Dockerfile troubleshooting should include build context and caching. Copying a large directory early in a Dockerfile can invalidate later cache layers unnecessarily, while a poorly chosen build context can send sensitive or irrelevant files to the daemon. A .dockerignore file, deliberate instruction ordering, and multi-stage builds can reduce image size and make builds more repeatable. These practices also improve security by minimizing what reaches the final runtime image.

Container lifecycle signals are another useful operational topic. The main process determines whether a container remains running, and graceful shutdown depends on signals reaching the application correctly. Developers who wrap processes carelessly can interfere with signal handling and leave services slow to terminate. Understanding PID 1 behavior, restart policies, health checks, and controlled shutdown makes orchestration behavior easier to predict under deployment or failure conditions.

Before test day, rebuild the lab without notes and explain every command and configuration choice aloud. If an image, port, volume, network, registry, security option, or restart setting cannot be explained in terms of its operational effect, that topic deserves another hands-on pass.

DCA is best prepared through a compact lab environment and repeated rebuilds

A small local lab is enough to cover a large part of the exam’s practical foundation. Build a simple application image, run it with environment variables, attach it to a user-defined network, connect it to a second service, persist data in a volume, publish a port, push the image to a registry, and then recreate the environment from scratch. Add security constraints and intentionally break components so the recovery process becomes familiar.

This lab-first approach aligns with Mirantis’s experience recommendation. DCA is not valuable because it proves someone can recognize Docker vocabulary; it is useful when it reflects real container handling skills. Candidates who can explain image construction, runtime behavior, connectivity, data persistence, security, distribution, and orchestration as one operating system for applications are much better positioned for both the exam and production container work.