Important Docker DCA Exam Questions

Answer: B

Explanation:

n: = Using the DTR web UI to make all tags in the repository immutable is not a good way to prevent an image, such as 'nginx:latest', from being overwritten by another user with push access to the repository. This is because making all tags immutable would prevent any updates to the images in the repository, which may not be desirable for some use cases. For example, if a user wants to push a new version of 'nginx:latest' with a security patch, they would not be able to do so if the tag is immutable.A better way to prevent an image from being overwritten by another user is to use the DTR web UI to create a promotion policy that restricts who can push to a specific tag or repository1.Alternatively, the user can also use the DTR API to create a webhook that triggers a custom action when an image is pushed to a repository2.Reference:

Prevent tags from being overwritten | Docker Docs

Create webhooks | Docker Docs

Answer: A

Explanation:

Label constraints can be used to schedule containers to meet the security policy requirements. Label constraints are a way to specify which nodes a service can run on based on the labels assigned to the nodes. Labels are key-value pairs that can be attached to any node in the swarm. For example, you can label nodes asdevelopmentorproductiondepending on their intended use. Then, you can use the--constraintoption when creating or updating a service to filter the nodes based on their labels. For example, to run a service only on development nodes, you can use:

docker service create --constraint'node.labels.environment == development'...

To run a service only on production nodes, you can use:

docker service create --constraint'node.labels.environment == production'...

This way, you can ensure that development and production containers run on separate nodes in the swarm, as required by the security policy.Reference:

Using placement constraints with Docker Swarm

Multiple label placement constraints in docker swarm

Machine constraints in Docker swarm

How can set service constraint to multiple value

Answer: A

Explanation:

= SAML is a supported user authentication method for Universal Control Plane (UCP). UCP has its own built-in authentication mechanism and integrates with LDAP and Active Directory. It also supports Role Based Access Control (RBAC) and Docker Content Trust. UCP allows you to configure SAML as an authentication method and connect it to your Identity Provider (IdP).You need to provide the Entity ID and the ACS URL fromUCP to your IdP, and the SAML Sign-on URL and the x509 Certificate from your IdP to UCP12.Reference:

SAML | Docker Docs

Configure Single Sign-On | Docker Docs

Answer: A

Explanation:

Node taints are a way to mark nodes in a Swarm cluster so that they can repel or attract certain containers based on their tolerations. By applying node taints to the nodes that are designated for development or production, the company can ensure that only the containers that have the matching tolerations can be scheduled on those nodes. This way, the security policy requirements can be met. Node taints are expressed as key=value:effect, where the effect can be NoSchedule, PreferNoSchedule, or NoExecute. For example, to taint a node for development only, one can run:

kubectl taint nodes node1 env=dev:NoSchedule

This means that no container will be able to schedule onto node1 unless it has a toleration for the taint env=dev:NoSchedule. To add a toleration to a container, one can specify it in the PodSpec. For example:

tolerations:

- key: 'env'

operator: 'Equal'

value: 'dev'

effect: 'NoSchedule'

This toleration matches the taint on node1 and allows the container to be scheduled on it.Reference:

Taints and Tolerations | Kubernetes

Update the taints on one or more nodes in Kubernetes

A Complete Guide to Kubernetes Taints & Tolerations

Answer: B

Explanation:

= The configuration willnotachieve fault tolerance for managers in a swarm, because it does not have enough managers to form a quorum. A quorum is the minimum number of managers that must be available to agree on values and maintain the consistent state of the swarm. The quorum is calculated as (N/2)+1, where N is the number of managers in the swarm. For example, a swarm with 3 managers has a quorum of 2, and a swarm with 5 managers has a quorum of 3. Having only two managers, one active and one passive, means that the quorum is also 2. Therefore, if one manager fails or becomes unavailable, the swarm will lose the quorum and will not be able to process any requests or schedule any tasks. To achieve fault tolerance, a swarm should have an odd number of managers, at least 3, and no more than 7. This way, the swarm can tolerate the loss of up to (N-1)/2 managers and still maintain the quorum and the cluster state.Reference:

Administer and maintain a swarm of Docker Engines

Raft consensus in swarm mode

How nodes work