Docker
Intermediate
DCA
Docker Certified Associate
The Docker Certified Associate (DCA) certification validates the skills and knowledge required to work with Docker Enterprise Edition in a production environment. This certification is designed for DevOps engineers, system administrators, and developers who use Docker for containerizing and deploying applications.
The exam covers six key domains consolidated into five: Container Orchestration (25%), Image Creation, Management, and Registry (20%), Installation and Configuration (15%), Networking and Security (30%), and Storage and Volumes (10%). Candidates must demonstrate proficiency with Docker Swarm orchestration, Dockerfile best practices, Docker registry management, Docker Engine installation and configuration, container networking models, network security, storage drivers, and volume management.
The DCA exam consists of 55 multiple-choice and discrete option questions administered over 90 minutes, with a passing score of 65%. This certification is ideal for professionals responsible for containerizing applications, managing Docker infrastructure, and implementing container orchestration in production environments. Hands-on experience with Docker in real-world scenarios is strongly recommended before attempting the exam.
Updated 2024
DevOps
55
Fragen
6
Übungstests
65%
Bestehensgrenze
67
Aufrufe
0
Versuche gesamt
0%
Durchschn. Punktzahl
0%
Bestehensquote
0
Diskussionen
DCA Practice Exam 1
Comprehensive 50-question practice exam covering all five DCA domains: Container Orchestration, Image Creation and Management, Installation and Configuration, Networking and Security, and Storage and Volumes.
50 Q
90 Minuten
65%
DCA Practice Exam 2
Comprehensive 50-question practice exam covering all five DCA domains with advanced container orchestration, image management, networking, security, and storage scenarios.
50 Q
90 Minuten
65%
DCA Practice Exam 3
Comprehensive 50-question practice exam covering all five DCA domains.
50 Q
90 Minuten
65%
DCA Practice Exam 4
Comprehensive 50-question practice exam covering all five DCA domains.
50 Q
90 Minuten
65%
DCA Practice Exam 5
Comprehensive 50-question practice exam covering all five DCA domains.
50 Q
90 Minuten
65%
DCA Practice Exam 6
Comprehensive 50-question practice exam covering all five DCA domains.
50 Q
90 Minuten
65%
Alle Inhalte freischalten für DCA
6 Übungstest(s) + Flash Cards — 3 Monate Zugang
€39.99
€26.99
30% sparen
oder enthalten im Monatsabo / Inhaltspaket
Vorschau (10 / 120)
What command initializes a Docker Swarm cluster?
docker swarm init. This command creates a new Swarm cluster and designates the current node as the first manager. It generates join tokens that worker and manager nodes use to join the cluster. You can specify --advertise-addr to set the address other nodes use to connect.
How does a worker node join an existing Docker Swarm?
By running docker swarm join with the worker join token and the manager's address and port. The join token is generated during swarm init and can be retrieved later with docker swarm join-token worker. Worker nodes execute tasks but do not participate in Raft consensus or cluster management decisions.
What is the difference between a manager node and a worker node in Docker Swarm?
Manager nodes maintain the cluster state using the Raft consensus algorithm, schedule services, and serve the Swarm API. Worker nodes receive and execute tasks assigned by managers. Managers can also run tasks unless drained. Every Swarm must have at least one manager node to function.
What is the Raft consensus algorithm in Docker Swarm?
Raft is the distributed consensus protocol used by Swarm managers to agree on the cluster state. It elects a leader among managers and requires a quorum (majority) of managers to be available for the cluster to accept updates. Raft ensures consistency even if some manager nodes fail.
What is quorum in a Docker Swarm and why does it matter?
Quorum is the minimum number of manager nodes that must be available to maintain cluster operations. It is calculated as (N/2)+1 where N is the total number of managers. For example, a 5-manager cluster requires 3 managers to be healthy. Losing quorum makes the cluster unable to process new tasks or updates.
What is the difference between a replicated service and a global service?
A replicated service runs a specified number of identical task replicas distributed across the Swarm according to scheduling constraints. A global service runs exactly one task on every node in the cluster that meets placement constraints. Global services are useful for monitoring agents, log collectors, and similar per-node workloads.
What is a task in Docker Swarm orchestration?
A task is the atomic scheduling unit in Swarm. Each task represents a single running container instance that is part of a service. The Swarm manager assigns tasks to nodes, and the node's worker component executes them. Tasks have states including new, pending, assigned, accepted, preparing, running, complete, and failed.
How do you scale a service in Docker Swarm?
Use docker service scale SERVICE_NAME=REPLICA_COUNT to change the number of running replicas. Swarm automatically distributes additional tasks across available nodes or removes excess tasks. You can also update the replicas field using docker service update --replicas. Scaling respects placement constraints and resource limits.
How do rolling updates work in Docker Swarm?
Rolling updates gradually replace old task replicas with new ones when you update a service image or configuration. Swarm stops a batch of old tasks, starts new ones, and waits for them to become healthy before proceeding. This minimizes downtime by ensuring some replicas are always running during the update process.
How do you perform a rollback in Docker Swarm?
Use docker service rollback SERVICE_NAME or docker service update --rollback SERVICE_NAME. Swarm reverts the service to its previous specification including the image, environment variables, and other settings. Rollback behavior can be configured with --rollback-delay, --rollback-parallelism, and --rollback-monitor during the original service creation or update.
Flash Cards
Karten zu wichtigen 120-Konzepten DCA
oder enthalten im Monatsabo / Inhaltspaket
110 weitere Karten nach Freischaltung verfügbar
Verfügbare Sprachen
English
Prüfungsthemen
1
14 Q
Container Orchestration
Configure and manage Docker Swarm mode, create and manage services, scale services, and implement rolling updates and rollbacks.
2
11 Q
Image Creation and Management
Create efficient Dockerfiles, manage image layers, tag and publish images, and use Docker registries including Docker Hub and DTR.
3
8 Q
Installation and Configuration
Install Docker Engine, configure daemon settings, manage logging drivers, and implement Docker Enterprise Universal Control Plane.
4
17 Q
Networking and Security
Configure container networking using bridge, overlay, and host networks, implement network security with encryption and ingress controllers, and apply least privilege access controls.
5
5 Q
Storage and Volumes
Configure storage drivers, manage volumes and bind mounts, implement persistent storage strategies, and optimize storage performance.
DCA Cheat Sheet
Kurzreferenz - 6 Abschnitte
Docker Certified Associate (DCA)
The Docker Certified Associate (DCA) exam validates your proficiency with the Docker Enterprise platform and containerization technologies across development and production environments. This certification is designed for Docker practitioners with at least six months of real-world experience building, shipping, and running containerized applications. The DCA covers a comprehensive range of Docker topics including container orchestration with Docker Swarm and Kubernetes, image creation and management using Dockerfiles and registries, installation and configuration of Docker Engine across multiple operating systems, container networking with bridge, overlay, and host network drivers, security practices including Docker Content Trust, secrets management, and role-based access control, as well as persistent storage using volumes, bind mounts, and storage drivers. The exam also tests your understanding of Docker Trusted Registry (DTR) and Universal Control Plane (UCP), which are enterprise-grade components for managing and securing containerized workloads at scale. Candidates are expected to understand both the conceptual underpinnings and hands-on CLI commands for managing Docker environments. Passing the DCA demonstrates your ability to deploy, manage, and troubleshoot Docker-based applications in production, making it a valuable credential for DevOps engineers, platform engineers, and container infrastructure specialists working with Docker Enterprise or Mirantis Kubernetes Engine.
Exam Details
| Exam Code | DCA |
| Duration | 90 minutes |
| Number of Questions | 55 questions |
| Passing Score | 65% (approximately 36 correct answers) |
| Cost | $195 USD |
| Validity | 2 years from the date of passing |
| Question Types | Multiple choice, multiple select, discrete option multiple choice (DOMC) |
| Certification Level | Associate |
Domain Weights
| Domain | Weight |
|---|---|
| Orchestration | 25% |
| Image Creation, Management, and Registry | 20% |
| Installation and Configuration | 15% |
| Networking | 15% |
| Security | 15% |
| Storage and Volumes | 10% |
Study Tips
- Orchestration is the heaviest domain at 25%; master Docker Swarm service creation, scaling, rolling updates, and node management commands inside and out, as well as the basics of Kubernetes pod, deployment, and service objects
- Hands-on practice is absolutely essential; spin up a multi-node Docker Swarm cluster and practice deploying stacks with docker stack deploy, managing services, draining nodes, and promoting workers to managers
- Image management is 20% of the exam; thoroughly understand Dockerfile instructions (FROM, RUN, COPY, ADD, CMD, ENTRYPOINT, ARG, ENV, EXPOSE, VOLUME, WORKDIR, USER, HEALTHCHECK), multi-stage builds, image layer caching, and tagging strategies
- Know the differences between bridge, overlay, host, macvlan, and none network drivers; understand when each is appropriate and how overlay networking enables cross-node communication in Swarm mode
- Security topics include Docker Content Trust (image signing with Notary), secrets management in Swarm, UCP client bundles, RBAC in UCP, and security scanning in DTR; understand how namespaces, cgroups, and seccomp profiles provide container isolation
- For storage, understand the distinction between volumes (managed by Docker), bind mounts (host filesystem paths), and tmpfs mounts (memory only); know the storage drivers (overlay2, devicemapper, aufs) and when each is appropriate
- Pay close attention to DOMC (Discrete Option Multiple Choice) questions where you see options one at a time and cannot go back; read each option carefully before committing your answer
Docker Swarm Architecture
| Component | Description |
|---|---|
| Manager Nodes | Maintain the cluster state using the Raft consensus algorithm; accept and dispatch service tasks to worker nodes; perform orchestration and scheduling decisions; recommended odd number (3, 5, or 7) for fault tolerance; a Swarm with N managers tolerates (N-1)/2 manager failures; the leader manager handles all Swarm management operations while followers proxy requests to the leader; managers also run workloads by default unless drained with docker node update --availability drain |
| Worker Nodes | Execute container tasks assigned by manager nodes; report task state back to managers; do not participate in Raft consensus or scheduling decisions; can be promoted to managers with docker node promote; drain a worker with docker node update --availability drain to gracefully stop tasks before maintenance; workers connect to managers over port 2377 (cluster management), 7946 (node discovery TCP/UDP), and 4789 (overlay network UDP) |
| Raft Consensus | Distributed consensus protocol ensuring all manager nodes agree on cluster state; requires a quorum (majority) of managers to be available for write operations; with 3 managers, quorum is 2 (tolerates 1 failure); with 5 managers, quorum is 3 (tolerates 2 failures); if quorum is lost, the swarm cannot process new commands but existing tasks continue running; recover quorum with docker swarm init --force-new-cluster on a surviving manager |
| Swarm Initialization | Initialize with docker swarm init --advertise-addr <IP>; generates join tokens for managers and workers; join workers with docker swarm join --token <worker-token> <manager-ip>:2377; join managers with docker swarm join --token <manager-token> <manager-ip>:2377; rotate tokens with docker swarm join-token --rotate worker or manager; view tokens with docker swarm join-token worker |
Exam Tip: The maximum recommended number of manager nodes is 7. Beyond that, the Raft consensus overhead outweighs the fault tolerance benefit. For production, use 3 or 5 managers. Remember that managers can also run workloads unless explicitly drained. The docker swarm init --force-new-cluster command is the key recovery mechanism when quorum is lost.
Services, Tasks, and Stacks
| Concept | Description |
|---|---|
| Replicated Services | Run a specified number of identical tasks (replicas) across the Swarm; docker service create --replicas 5 --name web nginx creates 5 replicas distributed across available nodes; scale with docker service scale web=10; the scheduler distributes tasks across nodes based on resource availability and placement constraints |
| Global Services | Run exactly one task on every node in the Swarm; created with docker service create --mode global; ideal for monitoring agents, log collectors, or antivirus daemons that need to run on every node; new nodes automatically receive a task when they join the Swarm; cannot be scaled manually since replicas are determined by node count |
| Rolling Updates | Update service images or configurations with zero downtime; docker service update --image nginx:1.25 web; control update behavior with --update-parallelism (tasks updated simultaneously), --update-delay (wait between batches), --update-failure-action (pause, continue, or rollback on failure), and --update-order (stop-first or start-first); start-first ensures new tasks start before old ones stop, providing higher availability |
| Rollbacks | Revert a service to its previous specification with docker service rollback web; automatic rollback when --update-failure-action rollback is set and task failures exceed --update-max-failure-ratio; rollback configuration (parallelism, delay, order) set independently with --rollback-* flags; Swarm stores the previous service spec for one-step rollback |
| Docker Stacks | Deploy multi-service applications from a Docker Compose YAML file (version 3+); docker stack deploy -c docker-compose.yml myapp; manages services, networks, volumes, secrets, and configs as a single unit; docker stack ls lists stacks, docker stack services myapp lists services in a stack, docker stack rm myapp removes the entire stack; stack deploy is idempotent and can be rerun to update the stack; does NOT support the build key, only pre-built images |
Kubernetes Basics in Docker Enterprise
| Object | Description |
|---|---|
| Pods | Smallest deployable unit in Kubernetes; one or more containers sharing the same network namespace and storage volumes; containers within a pod communicate via localhost; defined in YAML manifests with kind: Pod; managed by higher-level controllers (Deployments, ReplicaSets) rather than created directly in production |
| Deployments | Declarative controller for managing ReplicaSets and Pods; define desired state (image, replicas, resource limits) in a YAML manifest; kubectl apply -f deployment.yaml creates or updates; supports rolling updates, rollbacks (kubectl rollout undo), and scaling (kubectl scale deployment web --replicas=5); tracks revision history for easy rollback to any previous version |
| Services | Stable network endpoint for accessing a set of Pods; types: ClusterIP (internal only, default), NodePort (expose on each node's IP at a static port 30000-32767), LoadBalancer (provisions external load balancer in cloud environments); services use label selectors to discover backend pods; kube-proxy handles traffic routing and load balancing across pod replicas |
| Namespaces | Virtual clusters for resource isolation and multi-tenancy; default namespaces: default, kube-system, kube-public, kube-node-lease; apply resource quotas and limit ranges per namespace; RBAC policies can be scoped to namespaces for fine-grained access control; use kubectl -n <namespace> to operate within a specific namespace |
Exam Tip: Docker Enterprise (UCP) supports both Swarm and Kubernetes orchestrators simultaneously. Know the key differences: Swarm uses services and tasks while Kubernetes uses pods, deployments, and services. For the DCA exam, Swarm commands are tested more heavily, but you must understand basic Kubernetes concepts and kubectl commands.
Placement and Scheduling
- Placement Constraints: Restrict tasks to specific nodes using node labels; docker service create --constraint node.role==worker limits tasks to worker nodes; custom labels: docker node update --label-add datacenter=us-east node1, then --constraint node.labels.datacenter==us-east; supports == (equals) and != (not equals) operators; multiple constraints use AND logic
- Placement Preferences: Spread tasks evenly across a label value with --placement-pref spread=node.labels.datacenter; soft preference that attempts even distribution but does not prevent scheduling if balance is not perfect; useful for distributing replicas across availability zones or racks for high availability
- Resource Reservations: Reserve CPU and memory for tasks with --reserve-cpu 0.5 --reserve-memory 256M; the scheduler only places tasks on nodes with sufficient unreserved resources; resource limits (--limit-cpu, --limit-memory) cap the maximum resources a task can consume; reservation is a guarantee, limit is a ceiling
- Node Availability: Three states: active (accepts new tasks), pause (does not accept new tasks, existing tasks continue), drain (reschedules existing tasks to other nodes, does not accept new tasks); use drain before node maintenance: docker node update --availability drain node1; return to active after maintenance
Dockerfile Instructions
| Instruction | Description |
|---|---|
| FROM | Sets the base image for subsequent instructions; every Dockerfile must start with FROM (except ARG which can precede it); use specific tags (FROM node:18-alpine) instead of latest for reproducibility; FROM scratch creates an image from an empty filesystem used for statically compiled binaries; multi-stage builds use multiple FROM instructions |
| RUN | Executes commands in a new layer on top of the current image; shell form: RUN apt-get update (runs in /bin/sh -c); exec form: RUN ["apt-get", "update"] (no shell processing); combine multiple commands with && to reduce layers: RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* to keep image size small |
| COPY vs ADD | COPY copies files and directories from the build context into the image; ADD does the same but also supports URL downloads and automatic tar extraction; best practice is to use COPY for simple file copying (more explicit and predictable) and only use ADD when you specifically need tar auto-extraction; COPY --from=<stage> copies from a previous build stage in multi-stage builds |
| CMD vs ENTRYPOINT | CMD sets the default command to run when the container starts; can be overridden by docker run arguments; ENTRYPOINT configures the container to run as an executable; cannot be easily overridden (requires --entrypoint flag); best practice: use ENTRYPOINT for the main executable and CMD for default arguments: ENTRYPOINT ["python"] CMD ["app.py"]; only the last CMD and ENTRYPOINT in the Dockerfile take effect |
| ENV vs ARG | ENV sets environment variables available during build AND at runtime in the container; persists in the image metadata; ARG defines build-time variables only, not available at runtime; ARG values set with --build-arg during docker build; ARG declared before FROM is only available in the FROM instruction; ENV overrides ARG of the same name during the build |
| EXPOSE | Documents which ports the container listens on at runtime; does NOT actually publish the port; serves as documentation between the image builder and the container runner; publish ports at runtime with docker run -p 8080:80 (host:container) or -P to publish all exposed ports to random host ports; EXPOSE 80/tcp or EXPOSE 53/udp |
| VOLUME | Creates a mount point and marks it as holding externally mounted data; data written to the volume path is persisted outside the container's writable layer; volumes declared in Dockerfile create anonymous volumes at runtime if not explicitly mounted; useful for database data directories such as VOLUME /var/lib/mysql |
| HEALTHCHECK | Tells Docker how to test if the container is healthy; HEALTHCHECK --interval=30s --timeout=5s --retries=3 CMD curl -f http://localhost/ || exit 1; container states: starting, healthy, unhealthy; Swarm uses health checks to determine if tasks need to be restarted; HEALTHCHECK NONE disables health checking inherited from the base image |
| USER & WORKDIR | USER sets the user and optionally group for subsequent RUN, CMD, and ENTRYPOINT instructions; best practice: create a non-root user and switch to it (RUN adduser --disabled-password appuser then USER appuser) for security; WORKDIR sets the working directory for subsequent instructions; creates the directory if it does not exist; can be set multiple times |
Exam Tip: Know the difference between shell form (RUN command) and exec form (RUN ["command", "arg"]). Shell form runs through /bin/sh -c, which enables variable substitution but adds a shell process. Exec form runs the command directly without a shell. CMD and ENTRYPOINT should use exec form in production to ensure proper signal handling (PID 1). Only the last CMD instruction takes effect if multiple are present.
Multi-Stage Builds
| Concept | Description |
|---|---|
| Purpose | Dramatically reduce final image size by separating the build environment from the runtime environment; compile code in a stage with all build tools installed, then copy only the compiled artifact to a minimal runtime image; eliminates build dependencies, source code, and intermediate files from the production image; a Go application built in a golang:1.21 image (800MB+) can produce a final alpine image under 15MB |
| Syntax | Use multiple FROM instructions with optional AS aliases: FROM golang:1.21 AS builder followed by build commands, then FROM alpine:3.18 with COPY --from=builder /app/binary /usr/local/bin/; each FROM starts a new stage with a clean filesystem; stages are numbered from 0 or referenced by alias name |
| Target Stages | Build up to a specific stage with docker build --target builder .; useful for creating separate images for development (with debug tools) and production (minimal); CI/CD pipelines can build different targets for testing vs deployment; stages after the target are not executed |
| External Images | COPY --from can reference external images, not just build stages: COPY --from=nginx:latest /etc/nginx/nginx.conf /etc/nginx/; useful for borrowing configuration files or binaries from existing images without adding them as build stages |
Image Layer Caching and Best Practices
- Layer Caching: Each Dockerfile instruction creates a layer; Docker caches layers and reuses them when the instruction and all previous layers are unchanged; once a cache miss occurs, all subsequent layers are rebuilt; order instructions from least frequently changed (base image, system packages) to most frequently changed (application code) to maximize cache hits
- Minimize Layers: Combine related RUN commands with && to reduce the number of layers; clean up temporary files in the same RUN instruction (apt-get install && rm -rf /var/lib/apt/lists/*); each layer adds to the image size even if files are deleted in a subsequent layer due to the union filesystem
- .dockerignore: Exclude files and directories from the build context to speed up builds and prevent sensitive data from being included; syntax similar to .gitignore; common entries: .git, node_modules, *.md, Dockerfile, .env; reduces the size of the build context sent to the Docker daemon
- Image Tagging: Use semantic versioning (v1.2.3) or commit hashes rather than latest; tag images for each environment (dev, staging, prod); latest is just a convention and is not automatically updated; docker tag myapp:latest myapp:v1.0.0; push multiple tags for the same image to the registry
Docker Trusted Registry (DTR) and Image Management
| Feature | Description |
|---|---|
| DTR Overview | Enterprise-grade private image registry that integrates with UCP for access control; stores Docker images on-premises or in your cloud infrastructure; provides a web UI for browsing repositories, tags, and vulnerability scan results; high availability through multiple DTR replicas; supports image mirroring for multi-datacenter deployments and promotion policies for automated image promotion between repositories |
| Image Scanning | Scans images for known CVEs (Common Vulnerabilities and Exposures) against a regularly updated vulnerability database; scan on push (automatic) or manual trigger; results show critical, major, and minor vulnerabilities with links to CVE details; integrate scanning into CI/CD pipelines to gate deployments based on vulnerability severity |
| Immutable Tags | Once an image is pushed with a specific tag, that tag cannot be overwritten; prevents accidental or malicious replacement of production images; enforced at the repository level in DTR settings; ensures that a tag always references the same image digest for reproducible deployments |
| Image Pruning | Remove unused images to reclaim storage; docker image prune removes dangling images (untagged, not referenced by any container); docker image prune -a removes all unused images; docker system prune cleans images, containers, networks, and build cache; use --filter to target specific images by age or label |
Exam Tip: Understand the image lifecycle: build (Dockerfile), tag (docker tag), push (docker push), pull (docker pull), and run (docker run). Know that docker image inspect shows image metadata including layers, environment variables, and exposed ports. Docker images use a content-addressable storage model where each layer is identified by its SHA256 digest. The docker save and docker load commands export and import images as tar archives for offline transfer.
Docker Engine Installation and Configuration
| Topic | Description |
|---|---|
| Docker Engine Components | Docker daemon (dockerd) runs as a background service managing images, containers, networks, and volumes; Docker CLI (docker) sends commands to the daemon via a REST API over a Unix socket (/var/run/docker.sock) or TCP; containerd is the container runtime that manages the complete container lifecycle; runc is the OCI-compliant low-level runtime that creates and runs containers using Linux kernel features (namespaces, cgroups) |
| Daemon Configuration | Configuration file at /etc/docker/daemon.json; key settings include: storage-driver (overlay2 recommended), log-driver (json-file, syslog, fluentd), log-opts (max-size, max-file for log rotation), default-address-pools (custom subnet ranges for bridge networks), insecure-registries (allow HTTP registries), live-restore (keep containers running during daemon restart); apply changes with systemctl restart docker or send SIGHUP for some settings; do not mix daemon.json settings with dockerd command-line flags for the same option or the daemon will fail to start |
| Logging Drivers | Control where container logs are sent; json-file (default, logs stored on disk as JSON), syslog (send to syslog daemon), journald (send to systemd journal), fluentd (send to Fluentd collector), awslogs (send to AWS CloudWatch), gcplogs (send to Google Cloud Logging), splunk (send to Splunk); set per container with docker run --log-driver or globally in daemon.json; the docker logs command only works with json-file and journald drivers |
| Namespaces and Cgroups | Linux namespaces provide isolation: PID (process isolation), NET (network interfaces), MNT (filesystem mount points), UTS (hostname), IPC (inter-process communication), USER (user and group IDs); cgroups (control groups) limit and account for resource usage: CPU shares, memory limits, block I/O, device access; together they create the isolation boundary that makes containers possible without full virtualization |
| Universal Control Plane (UCP) | Enterprise-grade cluster management UI and API for Docker Enterprise; manages both Swarm and Kubernetes workloads from a single interface; deployed as a set of containers on manager nodes; provides web-based dashboard, role-based access control, image signing enforcement, and audit logging; UCP client bundles contain TLS certificates for CLI access; integrates with LDAP/AD for user authentication |
Exam Tip: The daemon.json file is the primary method for configuring Docker Engine. The live-restore option ("live-restore": true) is critical for production because it allows containers to keep running even when the Docker daemon is stopped for updates. Know the docker system info command to verify engine configuration including storage driver, logging driver, kernel version, and operating system details.
Docker Compose
| Feature | Description |
|---|---|
| Compose File Structure | YAML file (docker-compose.yml) defining multi-container applications; top-level keys: version (deprecated in Compose V2), services (container definitions), networks (custom networks), volumes (named volumes), secrets (Swarm secrets), configs (Swarm configs); each service defines image or build context, ports, volumes, environment variables, depends_on, deploy settings, and health checks |
| Key Commands | docker compose up -d (create and start containers in detached mode), docker compose down (stop and remove containers and networks), docker compose down -v (also remove volumes), docker compose build (build images from Dockerfiles), docker compose logs -f (follow logs), docker compose ps (list containers), docker compose exec web sh (execute command in running container); Compose V2 is a Docker CLI plugin (docker compose) replacing the standalone binary (docker-compose) |
| Deploy Section | Controls Swarm deployment behavior within the Compose file; replicas, placement constraints, resource limits, update_config (parallelism, delay, failure_action, order), rollback_config, restart_policy (condition, delay, max_attempts, window); the deploy key is only used when deploying with docker stack deploy and is ignored by docker compose up |
| Variable Substitution | Use ${VARIABLE} or ${VARIABLE:-default} syntax in Compose files; variables sourced from shell environment or .env file in the project directory; docker compose config shows the resolved Compose file with all variables substituted; useful for environment-specific configurations (dev, staging, prod) without modifying the Compose file |
Docker Networking
| Network Driver | Description |
|---|---|
| Bridge (default) | Default network driver for standalone containers; creates a Linux bridge (docker0 for the default bridge); containers on the same bridge network can communicate by IP; user-defined bridge networks additionally enable DNS resolution by container name (automatic service discovery); isolate container groups by placing them on separate bridge networks; create with docker network create --driver bridge mynet |
| Overlay | Multi-host networking for Docker Swarm services; creates a distributed network spanning multiple Docker daemon hosts; uses VXLAN encapsulation to tunnel traffic between nodes over the underlying physical network; the ingress overlay network handles Swarm load balancing and routing mesh; user-defined overlay networks provide service-to-service communication; create with docker network create --driver overlay --attachable myoverlay (--attachable allows standalone containers to join) |
| Host | Removes network isolation between the container and the Docker host; container shares the host's network namespace directly; no port mapping needed as the container binds directly to host ports; best performance since there is no NAT overhead; only one container can bind to a given port; use with docker run --network host; not available on Docker Desktop for macOS and Windows since containers run in a VM |
| Macvlan | Assigns a MAC address to each container, making it appear as a physical device on the network; containers get IP addresses from the physical network; useful for legacy applications that expect to be directly connected to the network; requires the physical NIC to be in promiscuous mode; docker network create --driver macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 mymacvlan |
| None | Completely disables networking for the container; the container gets only a loopback interface; use for maximum isolation when the container performs computation without requiring network access; docker run --network none |
Swarm Networking and Service Discovery
- Routing Mesh: Built-in load balancing for Swarm services; publishes a service port on every node in the Swarm, regardless of whether the node is running a task for that service; incoming requests on any node's published port are routed to an active task via the ingress overlay network; enables external load balancers to target any Swarm node
- Internal DNS: Swarm has a built-in DNS server that resolves service names to virtual IPs (VIP) or individual task IPs; VIP mode (default) uses a single virtual IP that load-balances across all tasks; DNSRR mode (--endpoint-mode dnsrr) returns all task IPs and relies on the client for load balancing; service names are resolvable only within the same overlay network
- Published Ports: Expose services externally with -p or --publish; two modes: ingress (default, uses routing mesh, all nodes listen) and host (bypasses routing mesh, only the node running the task listens); host mode: docker service create --publish mode=host,target=80,published=8080; host mode is useful when you need client IP preservation or direct node access
- Required Ports: TCP 2377 for cluster management and Raft consensus, TCP/UDP 7946 for node discovery and gossip protocol, UDP 4789 for VXLAN overlay network data traffic; all three must be open between all Swarm nodes; if overlay encryption is enabled, IP protocol 50 (ESP) must also be allowed
Exam Tip: The default bridge network does NOT provide automatic DNS resolution between containers; you must use a user-defined bridge network for DNS service discovery. The routing mesh and VIP-based load balancing are key differentiators of Swarm networking. Remember that --attachable is required on an overlay network to allow standalone containers to connect to it.
Docker Content Trust (DCT)
| Concept | Description |
|---|---|
| Image Signing | Docker Content Trust uses Notary to sign and verify Docker images; publishers sign images with private keys, consumers verify signatures before pulling; ensures image integrity (not tampered with) and authenticity (published by a trusted source); enable globally with export DOCKER_CONTENT_TRUST=1; when enabled, docker push automatically signs images and docker pull only pulls signed images |
| Key Management | Root key (offline key): most important key, signs the repository metadata; should be stored securely offline on air-gapped systems or hardware security modules; generated once per publisher; Repository key (tagging key): signs individual image tags; can be rotated without affecting the root key; Delegation keys: allow teams to sign images without sharing the repository key; manage keys with docker trust key generate and docker trust signer add |
| UCP Enforcement | UCP can enforce image signing policies at the cluster level; only allow images signed by specific teams to be deployed; configure in UCP Admin Settings under Docker Content Trust; when enforced, unsigned images or images signed by untrusted signers are rejected during container creation; ensures supply chain security in production environments |
Exam Tip: When DOCKER_CONTENT_TRUST=1 is set, docker pull and docker run will only work with signed images. This is a critical security control for production environments. The root key must be kept secure; if compromised, an attacker can sign malicious images. UCP can enforce DCT at the cluster level, preventing any unsigned images from being deployed.
Secrets Management
| Feature | Description |
|---|---|
| Docker Secrets | Securely store sensitive data (passwords, TLS certificates, API keys) in the Swarm; encrypted at rest in the Raft log and in transit between managers using mutual TLS; only delivered to containers that have been explicitly granted access; mounted as files in the container's filesystem at /run/secrets/<secret_name>; never stored on disk on worker nodes, only held in memory via tmpfs; available only in Swarm mode, not standalone containers |
| Secret Commands | Create: echo "mypassword" | docker secret create db_password - or docker secret create db_password ./password.txt; grant to service: docker service create --secret db_password myapp; list secrets: docker secret ls; inspect: docker secret inspect db_password (shows metadata, not the value); remove: docker secret rm db_password (only if no services reference it); rotate by creating a new secret and updating the service with --secret-rm and --secret-add |
| Docker Configs | Similar to secrets but for non-sensitive configuration data; stored in the Raft log but NOT encrypted; mounted as files in the container at a configurable path (default /); useful for configuration files and environment-specific settings; commands: docker config create, docker config ls, docker config inspect, docker config rm; also Swarm-only |
Container Isolation and Security Controls
| Security Feature | Description |
|---|---|
| Namespaces | Provide process isolation; each container has its own PID, NET, MNT, UTS, IPC, and USER namespace; processes inside a container cannot see or affect processes in other containers or on the host; user namespaces (--userns-remap) map container root (UID 0) to an unprivileged host user, preventing container breakout from gaining host root privileges |
| Seccomp Profiles | Restrict which system calls a container can make to the kernel; Docker applies a default seccomp profile that blocks approximately 44 dangerous syscalls including reboot, mount, and ptrace; custom profiles can further restrict syscalls for specific applications; apply with docker run --security-opt seccomp=myprofile.json; disable with --security-opt seccomp=unconfined (not recommended for production) |
| AppArmor and SELinux | Mandatory access control (MAC) systems that restrict container capabilities beyond standard Linux permissions; AppArmor (Ubuntu/Debian): Docker applies docker-default profile limiting file access, network, and capabilities; SELinux (RHEL/CentOS): labels container processes and files to prevent unauthorized access; both add defense-in-depth beyond namespaces and cgroups |
| Capabilities | Linux capabilities divide root privileges into distinct units; Docker drops many capabilities by default such as SYS_ADMIN, NET_ADMIN, and SYS_PTRACE; add specific capabilities with --cap-add (docker run --cap-add NET_ADMIN); drop capabilities with --cap-drop; drop all and add only what is needed: --cap-drop ALL --cap-add NET_BIND_SERVICE; never use --privileged in production as it grants all capabilities and full device access |
| Read-Only Filesystem | Run containers with a read-only root filesystem using docker run --read-only; prevents malware from writing to the container's filesystem; combine with tmpfs mounts for directories that require write access (--tmpfs /tmp); significantly reduces the attack surface by ensuring the container cannot be modified at runtime |
RBAC and Access Control in UCP
- Subjects: Users (individual accounts), Teams (groups of users within an organization), Organizations (top-level grouping containing teams); UCP integrates with LDAP/AD for centralized user management; service accounts for automated access via client bundles containing TLS certificates
- Roles: Define permissions for Docker resources; built-in roles: None (no access), View Only (read access), Restricted Control (run containers but no bind mounts or privileged mode), Scheduler (schedule workloads on nodes), Full Control (all operations including admin); custom roles can be created with specific API operation permissions
- Collections: Group Docker resources (containers, services, nodes, volumes, networks, secrets) into hierarchical collections; grants are the combination of subject + role + collection; for example, grant the "developers" team "Restricted Control" over the "/production/web" collection; child collections inherit permissions from parent unless explicitly overridden
- Client Bundles: Downloadable ZIP files from UCP containing TLS certificates and environment variables; configure the Docker CLI and kubectl to authenticate against UCP; environment variables set DOCKER_HOST, DOCKER_TLS_VERIFY, DOCKER_CERT_PATH; user-specific bundles enforce the user's RBAC permissions via the CLI
Exam Tip: The --privileged flag gives a container full access to all host devices and capabilities, effectively removing all security boundaries. Never use it in production. Instead, add only the specific capabilities needed with --cap-add. Know the UCP RBAC model: subjects (users/teams) are granted roles (permissions) on collections (resource groups). The Restricted Control role is the recommended default for developers as it prevents bind mounts and privileged mode.
Volume Types and Mount Options
| Mount Type | Description |
|---|---|
| Volumes | Managed by Docker and stored in /var/lib/docker/volumes/ on the host; the preferred mechanism for persisting data generated by containers; created with docker volume create mydata or automatically when referenced in docker run -v mydata:/app/data; survive container removal; can be shared between multiple containers simultaneously; support volume drivers for remote and cloud storage (NFS, AWS EBS, Azure File); named volumes have a specific name while anonymous volumes receive a random hash name |
| Bind Mounts | Map a specific host filesystem path into the container; docker run -v /host/path:/container/path or docker run --mount type=bind,source=/host/path,target=/container/path; the container can read and write directly to the host filesystem; useful for development (mount source code for live reloading); security concern: container can modify host files; UCP Restricted Control role prevents bind mounts for this reason; bind mounts depend on the host's directory structure existing |
| tmpfs Mounts | Stored in memory only, never written to the host filesystem; docker run --tmpfs /app/cache or docker run --mount type=tmpfs,destination=/app/cache,tmpfs-size=100m; data is lost when the container stops; ideal for sensitive data that should not persist such as session tokens and temporary files; faster than disk-backed storage; only available on Linux hosts; cannot be shared between containers |
Exam Tip: Use the --mount flag (verbose syntax) instead of -v (shorthand) for clarity and full feature access. The key difference: -v creates the host directory if it does not exist, while --mount type=bind throws an error if the source does not exist. For the exam, know that volumes are the recommended approach for production data persistence, bind mounts are best for development, and tmpfs is for sensitive ephemeral data.
Storage Drivers
| Driver | Description |
|---|---|
| overlay2 | The recommended and default storage driver for all modern Linux distributions; uses the OverlayFS union filesystem to layer multiple directories into a single unified view; efficient for both memory and inode usage; requires Linux kernel 4.0+ and a backing filesystem of ext4 or xfs; supports up to 128 lower layers; performs well for build-heavy and write-heavy workloads |
| devicemapper | Uses device-mapper thin provisioning and copy-on-write at the block level; two modes: loop-lvm (uses loopback devices, for testing only with poor performance) and direct-lvm (uses raw block devices, production-ready); was the recommended driver for RHEL/CentOS before overlay2 support; more complex to configure than overlay2; block-level operations can be more efficient for write-heavy workloads but generally overlay2 is preferred |
| aufs | Advanced Multi-Layered Unification Filesystem; was the default driver on older Ubuntu and Debian systems before overlay2; supports many layers efficiently; not included in the mainline Linux kernel and requires a separate kernel module; deprecated in favor of overlay2; still works on older systems but not recommended for new installations |
| btrfs and zfs | Use the respective filesystem's native copy-on-write and snapshot features; require the host filesystem to be btrfs or zfs; offer advanced features like built-in snapshots, compression, and checksumming; more complex to set up and manage; suitable for specialized environments that already use these filesystems; not commonly used for general Docker deployments |
Volume Management Commands
| Command | Description |
|---|---|
| docker volume create | Create a named volume with optional driver and options: docker volume create --driver local --opt type=nfs --opt o=addr=192.168.1.100,rw --opt device=:/data nfsdata; supports driver-specific options for remote storage backends; labels can be added with --label for organization and filtering |
| docker volume ls | List all volumes on the host; filter with --filter: docker volume ls --filter driver=local or docker volume ls --filter dangling=true (volumes not referenced by any container); format output with --format for scripting |
| docker volume inspect | Display detailed information about a volume including driver, mount point (/var/lib/docker/volumes/<name>/_data), labels, options, and scope (local or global); use to verify volume configuration and location on the host filesystem |
| docker volume prune | Remove all unused (dangling) volumes; WARNING: this permanently deletes data; add --filter to limit which volumes are pruned; unlike docker volume rm which removes specific named volumes, prune targets all unreferenced volumes; include in cleanup scripts but use with extreme caution in production |
Volumes in Swarm Services
- Local Volumes in Swarm: Local volumes are node-specific; if a Swarm task is rescheduled to a different node, it gets an empty local volume; data is not automatically migrated between nodes; suitable only for ephemeral or replicated data like caches where loss on failover is acceptable
- Volume Plugins: Enable shared storage across Swarm nodes; popular plugins: REX-Ray (supports AWS EBS, Azure Disk, GCE PD), Portworx (distributed storage), GlusterFS, NFS; volume plugins ensure that when a task moves to a different node, the same persistent volume is available; configure with docker plugin install
- Service Volume Syntax: Attach volumes to Swarm services with docker service create --mount type=volume,source=mydata,target=/app/data myapp; the --mount flag is preferred over -v for Swarm services because it provides clearer syntax and better error handling; for bind mounts use --mount type=bind,source=/host/path,target=/container/path
- Container Writable Layer: Each container has a thin writable layer on top of the read-only image layers managed by the storage driver; writes to this layer use copy-on-write which copies the file from the image layer before modifying it; the writable layer is deleted when the container is removed; write-heavy applications should use volumes instead of the container writable layer for better performance and data persistence
Exam Tip: Know the difference between storage drivers (manage image layers and the container writable layer) and volume drivers (manage persistent data volumes). The storage driver handles the union filesystem for read-only layers and copy-on-write, while volumes bypass the storage driver entirely for better write performance. For the exam, overlay2 is the correct default storage driver, and named volumes are the correct default for data persistence.