2 packs: 15% off with code BUY2. 3 or more: 20% off with code BUY3.

Free Mirantis DCA Docker Certified Associate Practice Questions

16 free Mirantis DCA Docker Certified Associate practice questions from the CertStash pack of 135, each with the correct answer and a full explanation. The rule is the same for every exam: ten free on the product page, 16 free here, all 135 in the pack, and each step includes the one before it.

Get all 135 questions (US$39) · Download the first 10 as a PDF

Question 1

When an application being managed by UCP fails, you would like a summary of all requests made to the UCP API in the hours leading up to the failure.

What must be configured correctly beforehand for this to be possible?

  1. UCP audit logs must be set to the ‘metadata’ or ‘request’ level.
  2. All engines in the cluster must have their log driver set to the ‘metadata’ or ‘request’ level.
  3. UCP logging levels must be set to the ‘info’ or ‘debug’ level.
  4. Set the logging level in the config object for the ucp-kube-api-server container to warning or higher.
Show answer and explanation

Correct answer: A. UCP audit logs must be set to the ‘metadata’ or ‘request’ level.

UCP can produce audit logs that record requests made to the UCP API. Audit logging has three levels: none, metadata and request. At the metadata level UCP records information about each request, such as the user, time and endpoint, and at the request level it also records the request body. Audit logging must be enabled at one of these two levels before the failure occurs, because UCP cannot reconstruct a history of API requests that it never recorded. The audit entries are written to the UCP controller logs, where they can be collected and reviewed.

Why the other options are wrong

  • B. Engine log drivers forward container output and have no metadata or request levels for recording UCP API calls.
  • C. UCP logging levels control the verbosity of component logs and do not produce an audit record of API requests.
  • D. Raising the kube-apiserver log threshold to warning reduces detail and does not record a history of UCP API requests.

Question 2

A user’s attempts to set the system time from inside a Docker container are unsuccessful.

Could this be blocking this operation?

SELinux

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Changing the system clock requires the Linux capability CAP_SYS_TIME. The system clock is not namespaced, so a change made inside a container would alter the time for the host and every other container. For that reason Docker drops CAP_SYS_TIME from the default capability set, and the attempt fails with a permission error whether or not SELinux is enabled. SELinux labels control which files and processes a container can access; they are not what prevents a container from setting the time. Granting the capability with --cap-add SYS_TIME is what would allow the operation.

Why the other options are wrong

  • A. The operation is blocked because Docker drops the CAP_SYS_TIME capability by default, not because of SELinux.

Question 3

One of several containers in a pod is marked as unhealthy after failing its livenessProbe many times.

Is this the action taken by the orchestrator to fix the unhealthy container?

The unhealthy container is restarted.

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

A livenessProbe tells the kubelet how to check whether a container is still working. When the probe fails more times in a row than its failureThreshold allows, the kubelet kills the container and restarts it according to the pod's restartPolicy, which is Always by default. Only the failing container is restarted; the other containers in the pod keep running and the pod itself is not rescheduled to another node. Restarting the unhealthy container is therefore exactly the action Kubernetes takes.

Why the other options are wrong

  • B. Repeated livenessProbe failures cause the kubelet to restart that container, so the statement is correct.

Question 4

Is this a way to configure the Docker engine to use a registry without a trusted TLS certificate?

Set INSECURE_REGISTRY in the ‘/etc/docker/default’ configuration file.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Docker Engine is told to use a registry without a trusted TLS certificate through the insecure-registries setting. It can be added as an array of registry addresses in the daemon configuration file, /etc/docker/daemon.json, or passed to the daemon with the --insecure-registry flag, followed by a restart of the daemon. There is no /etc/docker/default file that the engine reads, and INSECURE_REGISTRY is not a setting the daemon recognizes there, so this approach does not configure an insecure registry.

Why the other options are wrong

  • A. The daemon reads insecure-registries from daemon.json or the --insecure-registry flag, not an INSECURE_REGISTRY entry in /etc/docker/default.

Question 5

Is this a way to configure the Docker engine to use a registry without a trusted TLS certificate?

Set and export the IGNORE_TLS environment variable on the command line.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Trust for a registry is enforced by the Docker daemon, not by the client shell, so an environment variable exported on the command line does not change how the daemon connects to a registry. Docker has no IGNORE_TLS variable. A registry without a trusted certificate is allowed by adding it to the insecure-registries list in /etc/docker/daemon.json or by starting the daemon with the --insecure-registry flag, and then restarting the daemon.

Why the other options are wrong

  • A. IGNORE_TLS is not a Docker setting; insecure registries are configured on the daemon with insecure-registries or --insecure-registry.

Question 6

Is this a way to configure the Docker engine to use a registry without a trusted TLS certificate?

Pass the ‘--insecure-registry’ flag to the daemon at run time.

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

The Docker daemon accepts the --insecure-registry flag, which names a registry that the engine may reach over plain HTTP or over HTTPS with a certificate it does not trust. The flag can be repeated for several registries, and the same setting can be made permanent with the insecure-registries key in /etc/docker/daemon.json. Passing the flag to dockerd when it starts is therefore a valid way to let the engine use a registry without a trusted TLS certificate, although it removes the protection that certificate verification provides.

Why the other options are wrong

  • B. Starting the daemon with the --insecure-registry flag is a documented way to allow such a registry.

Question 7

Is this an advantage of multi-stage builds? better logical separation of Dockerfile instructions for increased readability

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

A multi-stage build uses several FROM instructions in one Dockerfile, each starting a named or numbered stage. Instructions for different concerns, such as installing build tools, compiling the application and assembling the runtime image, can be placed in their own stages, and COPY --from copies only the needed artifacts into the final stage. This separation makes the Dockerfile easier to read and maintain than a single long stage or a set of separate Dockerfiles and helper scripts, which Docker describes as a key benefit of multi-stage builds.

Why the other options are wrong

  • B. Organizing instructions into distinct stages for readability is a recognized advantage of multi-stage builds.

Question 8

Is this an advantage of multi-stage builds? better caching when building Docker images

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

In a multi-stage build each stage produces its own layers, and Docker caches them instruction by instruction. Placing slow, rarely changing work, such as installing toolchains and dependencies, in an early stage means that a change to application code in a later stage does not invalidate those cached layers, so rebuilds reuse them and finish faster. BuildKit also builds only the stages that the target stage depends on and can build independent stages in parallel, which further shortens build times.

Why the other options are wrong

  • B. Separating stages lets Docker reuse cached layers for unchanged stages, which is an advantage of multi-stage builds.

Question 9

You add a new user to the engineering organization in DTR.

Will this action grant them read/write access to the engineering/api repository?

Add the user directly to the list of users with read/write access under the repository’s Permissions tab.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

In Docker Trusted Registry, access to repositories owned by an organization is granted through teams. An organization owner creates teams, adds users to them and gives each team read-only, read-write or admin permission on a set of the organization's repositories; team permissions are additive, so a user receives the highest level from the teams they belong to. There is no list of individual users on the repository's Permissions tab, so the user gains read/write access to engineering/api by joining a team that has that permission.

Why the other options are wrong

  • A. Organization repositories grant access through teams, so the user cannot be added individually to the repository's permissions.

Question 10

Is this statement correct?

A Dockerfile stores persistent data between deployments of a container.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

A Dockerfile only describes how to build an image; it holds no data at run time. Data written inside a container's writable layer is lost when the container is removed. To keep data between deployments of a container, Docker uses volumes, which are managed by Docker and exist independently of any container, or bind mounts, which map a directory on the host into the container. The statement therefore describes the role of volumes, not of a Dockerfile.

Why the other options are wrong

  • A. Persistent data is kept in volumes or bind mounts, while a Dockerfile only contains build instructions.

Question 11

Is this a supported user authentication method for Universal Control Plane?

X.500

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Universal Control Plane authenticates users through its built-in user database, through integration with an LDAP or Active Directory directory, or through SAML single sign-on with an external identity provider. X.500 is a family of directory service standards from which LDAP was derived, but it is not an authentication method that UCP can be configured to use. Directory integration in UCP is done over LDAP.

Why the other options are wrong

  • A. UCP integrates with directories over LDAP, and X.500 is not one of its configurable authentication methods.

Question 12

In the context of a swarm mode cluster, does this describe a node? a virtual machine participating in the swarm

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

Docker defines a node as an instance of the Docker Engine participating in the swarm. Nodes can run on physical servers, on virtual machines in a data center or on cloud instances, and several can even run on one physical computer. A virtual machine running Docker Engine that has joined the swarm as a manager or worker is therefore a node.

Why the other options are wrong

  • B. A virtual machine whose Docker Engine has joined the swarm is a node.

Question 13

Seven managers are in a swarm cluster.

Is this how should they be distributed across three datacenters or availability zones?

3-2-2

  1. Yes
  2. No
Show answer and explanation

Correct answer: A. Yes

A swarm with seven managers keeps quorum as long as four managers, a majority, are available. Docker's guidance for spreading managers across three availability zones is a 3-2-2 split. With that layout, losing any single zone removes at most three managers and leaves at least four, so the swarm keeps quorum and continues to accept orchestration changes. The split balances the managers so that no single zone holds enough of them to take down the cluster.

Why the other options are wrong

  • B. A 3-2-2 split keeps a majority of four managers when any one zone fails, which is the recommended layout.

Question 14

You add a new user to the engineering organization in DTR.

Will this action grant them read/write access to the engineering/api repository?

Mirror the engineering/api repository to one of the user’s own private repositories.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Repository mirroring in Docker Trusted Registry copies images from one repository to another, for example to promote or replicate content. A mirror in the user's own private repository would give the user a separate copy of the images, but it would not change who can read or write the original engineering/api repository. Access to that organization repository is granted by adding the user to a team in the engineering organization that has read/write permission on it.

Why the other options are wrong

  • A. Mirroring creates a copy elsewhere and grants no permissions on the original engineering/api repository.

Question 15

An application image runs in multiple environments, with each environment using different certificates and ports. Is this a way to provision configuration to containers at runtime?

Create a Dockerfile for each environment, specifying ports and Docker secrets for certificates.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

A Dockerfile is used at build time, so a separate Dockerfile per environment produces separate images rather than providing configuration to containers at run time. The goal is to run the same image everywhere and inject environment-specific settings when the container or service starts: certificates as secrets, other files as configs, settings as environment variables, and ports through the --publish option or the ports section of a stack file. Building one image per environment defeats that model and duplicates maintenance.

Why the other options are wrong

  • A. Separate Dockerfiles create different images at build time instead of supplying configuration at run time.

Question 16

Is this the purpose of Docker Content Trust?

Enable mutual TLS between the Docker client and server.

  1. Yes
  2. No
Show answer and explanation

Correct answer: B. No

Docker Content Trust uses digital signatures to verify the integrity and publisher of image tags pushed to and pulled from a registry. It does not secure the connection between the Docker client and the daemon. Mutual TLS between client and server is configured separately by starting the daemon with TLS verification and giving clients certificates signed by a trusted certificate authority.

Why the other options are wrong

  • A. Mutual TLS for the daemon socket is a separate configuration; Content Trust signs and verifies image tags.

That was 16 of 135.

The full Mirantis DCA Docker Certified Associate pack has all 135 questions, each with the answer, the explanation and why the other options are wrong, plus a questions-only copy for timed runs. US$39, paid once, with free monthly updates and a pass-or-your-money-back guarantee.

Get the full pack

Not ready yet? Get the first 66 free as one PDF by email. Get the Half Pack →