DCA Risk Assessment & Management 5 — Questions and Answers
Question 1: A risk assessment identifies that Docker build cache is being shared across multiple teams in a CI environment. What is the primary security concern?
- Shared cache increases build times because of cache invalidation conflicts
- A malicious or compromised build from one team could poison the shared cache and inject artifacts into other teams' images (Correct answer)
- Shared build cache prevents Docker Content Trust from verifying image signatures
- Build cache sharing disables layer deduplication in the image registry
Correct answer: A malicious or compromised build from one team could poison the shared cache and inject artifacts into other teams' images
Cache poisoning allows a tampered layer to be reused by subsequent builds, silently introducing malicious code into images built by other teams.
Question 2: Which command correctly audits the Linux capabilities granted to a running Docker container to assess privilege escalation risk?
- `docker logs <container> --cap-list`
- `docker inspect <container> --format '{{.HostConfig.CapAdd}}'` (Correct answer)
- `docker exec <container> cat /proc/1/limits`
- `docker stats <container> --no-stream`
Correct answer: `docker inspect <container> --format '{{.HostConfig.CapAdd}}'`
`docker inspect` reads the container's HostConfig, which shows added and dropped Linux capabilities configured at container start time.
Question 3: A security team wants to enforce that all containers in a Swarm cluster run only images from a trusted internal registry. Which control implements this at the cluster level?
- Configuring registry mirrors in each daemon's `/etc/docker/daemon.json`
- Using Swarm's `--image` flag to hardcode the registry for each service
- Deploying an admission control policy or image signing enforcement that rejects images from untrusted registries (Correct answer)
- Setting `DOCKER_CONTENT_TRUST=1` only on worker nodes
Correct answer: Deploying an admission control policy or image signing enforcement that rejects images from untrusted registries
Admission controllers or policy engines (e.g., OPA, Notary enforcement) intercept API requests cluster-wide and reject non-compliant image sources before scheduling.
Question 4: What risk is introduced by running long-lived, stateful data directly inside a container's writable layer rather than in a Docker volume?
- Data stored in the writable layer is replicated to all nodes in a Swarm cluster
- Data loss on container removal, since the writable layer is destroyed when the container is deleted (Correct answer)
- The writable layer encrypts data automatically, causing performance issues
- Docker Compose cannot manage containers that write to their writable layer
Correct answer: Data loss on container removal, since the writable layer is destroyed when the container is deleted
A container's writable layer is ephemeral and tied to the container's lifecycle; data not stored in a named volume is permanently lost when the container is removed.
Question 5: An organization's compliance requirement mandates that all Docker container activity be auditable. Which daemon-level configuration enables system-call-level audit logging for containers?
- Setting `log-driver: json-file` in `/etc/docker/daemon.json`
- Enabling Linux Audit (`auditd`) rules on `/usr/bin/docker` and the Docker socket (Correct answer)
- Configuring `--log-opt max-size` for each container
- Using `docker events` to stream real-time daemon events to a file
Correct answer: Enabling Linux Audit (`auditd`) rules on `/usr/bin/docker` and the Docker socket
Adding auditd rules for the Docker binary, daemon socket, and relevant directories captures privileged operations at the kernel audit subsystem level for compliance.
Question 6: When assessing the risk of a multi-stage Docker build, what security advantage do multi-stage builds provide over single-stage builds?
- Multi-stage builds automatically scan each stage for vulnerabilities before proceeding
- Multi-stage builds ensure build-time tools, compilers, and secrets used during build are not present in the final production image (Correct answer)
- Multi-stage builds enforce a read-only filesystem in all intermediate stages
- Multi-stage builds require Docker Content Trust to be enabled for each FROM statement
Correct answer: Multi-stage builds ensure build-time tools, compilers, and secrets used during build are not present in the final production image
By copying only compiled artifacts into a clean final stage, multi-stage builds exclude build tools, SDKs, and any secrets used during compilation from the shipped image.
Question 7: A risk model classifies the Docker host's kernel as a shared resource. Which threat does this shared-kernel architecture create that hypervisor-based virtualization does not?
- Containers on the same host cannot share CPU cache lines, causing cache misses
- A kernel vulnerability exploited inside one container can potentially affect all containers and the host (Correct answer)
- Docker containers cannot run on hosts with SELinux enabled
- The shared kernel prevents more than 256 containers from running simultaneously on one host
Correct answer: A kernel vulnerability exploited inside one container can potentially affect all containers and the host
Because all containers share the host kernel, a kernel exploit (e.g., container escape CVE) can compromise the entire host and all co-located containers simultaneously.
DCA Risk Assessment & Management 5
A risk assessment identifies that Docker build cache is being shared across multiple teams in a CI environment.
What is the primary security concern?