DCA Project Planning & Execution 5 — Questions and Answers
Question 1: A project requires containers to be automatically restarted if they crash, but not if stopped manually. Which restart policy should be configured?
- --restart=always
- --restart=unless-stopped (Correct answer)
- --restart=on-failure
- --restart=no
Correct answer: --restart=unless-stopped
The 'unless-stopped' policy restarts crashed containers automatically but respects an explicit manual stop, unlike 'always'.
Question 2: During project planning, the security team requires all containers to run as a non-root user. How is this enforced in a Dockerfile?
- RUN chmod 750 /app
- USER <username_or_uid> instruction before the CMD or ENTRYPOINT (Correct answer)
- EXPOSE --user=appuser
- ENV RUN_AS_USER=appuser
Correct answer: USER <username_or_uid> instruction before the CMD or ENTRYPOINT
The USER instruction in a Dockerfile sets the default user for subsequent RUN, CMD, and ENTRYPOINT instructions in the container.
Question 3: A team plans to use Docker configs (not secrets) to distribute non-sensitive configuration to Swarm services. What is a key difference between Docker configs and Docker secrets?
- Configs are encrypted at rest; secrets are stored as plain text
- Configs are mounted at arbitrary paths; secrets are always mounted at /run/secrets/ (Correct answer)
- Configs can be updated in place; secrets are immutable and must be versioned
- Configs support binary data; secrets only support UTF-8 strings
Correct answer: Configs are mounted at arbitrary paths; secrets are always mounted at /run/secrets/
Secrets are always mounted under /run/secrets/<secret_name>, while configs can be mounted at any path specified in the service definition.
Question 4: When planning the execution environment, a developer wants to override the default command of a Docker image at runtime without modifying the Dockerfile. Which approach is correct?
- docker run --entrypoint-override myimage /bin/bash
- docker run myimage <new_command> appends to ENTRYPOINT and replaces CMD (Correct answer)
- docker run --cmd '/bin/bash' myimage
- docker run --override CMD myimage /bin/bash
Correct answer: docker run myimage <new_command> appends to ENTRYPOINT and replaces CMD
Arguments passed after the image name in 'docker run' replace the default CMD; use --entrypoint to override ENTRYPOINT instead.
Question 5: A project execution plan requires rolling back a Docker Swarm service to its previous configuration after a failed update. What is the correct command?
- docker service update --rollback <service_name> (Correct answer)
- docker service restart --previous <service_name>
- docker stack rollback <service_name>
- docker service revert <service_name>
Correct answer: docker service update --rollback <service_name>
The 'docker service update --rollback' command reverts a service to the configuration it had before the last 'docker service update'.
Question 6: During project planning, the team wants to inspect the layers of a Docker image to understand what contributed to its size. Which command provides this information?
- docker image layers <image>
- docker history <image> (Correct answer)
- docker inspect --layers <image>
- docker image diff <image>
Correct answer: docker history <image>
The 'docker history' command shows each layer of an image, including the instruction that created it and the size contribution.
Question 7: A project plan includes health checks for all services. Where can a HEALTHCHECK instruction be defined so it applies to every container started from an image?
- In the docker-compose.yml healthcheck key only — Dockerfile does not support it
- Directly in the Dockerfile using the HEALTHCHECK instruction (Correct answer)
- As a --health-cmd flag passed at 'docker build' time
- In the /etc/docker/daemon.json file as a global default
Correct answer: Directly in the Dockerfile using the HEALTHCHECK instruction
The HEALTHCHECK instruction in a Dockerfile embeds the health check into the image so it runs by default for all containers started from it.
DCA Project Planning & Execution 5
A project requires containers to be automatically restarted if they crash, but not if stopped manually.
Which restart policy should be configured?