Docker DCA Practice Test - Questions Answers, Page 18

While creating a Dockerfile for each environment is a possible solution, it is not the most efficient or scalable way to provision configuration to containers at runtime. Docker provides several mechanisms to inject configuration into containers at runtime, such as environment variables, command line arguments, Docker secrets for sensitive data, or even configuration files mounted as volumes. These methods allow the same Docker image to be used across multiple environments, promoting immutability and consistency across your deployments. Creating a separate Dockerfile for each environment would mean maintaining multiple versions of the Dockerfile, which could lead to inconsistencies and is generally not a recommended practice.

Yes, the docker port command can be used to identify the published ports for a running container. It shows the mapping between the host ports and the container's exposed ports. The docker network inspect command can also provide information about the network settings of the container, including port mappings. However, it's important to note that docker network inspect requires the network's name or ID as an argument, not the container's. Therefore, to get the network details of a specific container, you would first need to identify the network the container is connected to. These commands, when used appropriately, can help you identify the published ports for a container.

While removing push access from all other users can prevent an image from being overwritten, it's not the only way and might not be the most efficient or practical solution, especially in a collaborative environment. Docker Trusted Registry (DTR) provides a feature called 'Immutable Tags' which can be used to prevent an image, such as 'nginx:latest', from being overwritten. Once a tag is marked as immutable, DTR will prevent any user from pushing the same tag to the repository, thus preserving the image. This allows for better version control and prevents accidental overwrites. Therefore, the solution to prevent an image from being overwritten is not just to remove push access from all other users, but to use the features provided by DTR like 'Immutable Tags'.

Docker's bridge network allows containers connected to the same bridge network to communicate, while providing isolation from containers that aren't connected to that bridge network1. By using the network attach command, you can connect a container to the bridge network, making it reachable from the host's network12. However, it's important to note that containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy2. For better isolation and automatic DNS resolution between containers, it's recommended to use user-defined bridge networks12.

Docker uses cgroups, a Linux kernel feature, to limit the resources a container can use. This includes CPU and memory resources12. For instance, Docker can limit a container's CPU usage to the equivalent of a single CPU core on the Docker host system2. Similarly, Docker can limit a container's memory usage1. However, to use these features, the Docker host must have cgroup memory and swap accounting enabled1. Therefore, cgroups can indeed limit a Docker container's access to host resources such as CPU and memory12.

Docker Swarm requires more than one manager node to achieve fault tolerance12. A single manager node is not fault tolerant because if it goes down, the entire cluster goes down3. For a swarm to be fault-tolerant, it needs to have an odd number of manager nodes2. For example, a three-manager swarm tolerates a maximum loss of one manager2. Therefore, a configuration with one manager node for two worker nodes will not achieve fault tolerance for managers in a swarm12.

The provided Kubernetes NetworkPolicy YAML configuration indicates that the policy applies to pods with the label tier: backend in the default namespace1. The ingress rule allows traffic from pods with the label tier: api1. Therefore, a request issued from a pod bearing the tier: api label to a pod bearing the tier: backend label will not be blocked by this networkPolicy1. This is because the networkPolicy explicitly allows ingress from pods with the tier: api label1. For more information on Kubernetes Network

The provided Kubernetes NetworkPolicy YAML configuration indicates that the policy applies to pods with the label tier: backend in the default namespace1. The ingress rule allows traffic from pods with the label tier: api1. Therefore, a request issued from a pod bearing only the tier: frontend label to a pod bearing the tier: backend label will be blocked by this networkPolicy1. This is because the networkPolicy does not have a rule allowing ingress from pods with the tier: frontend label1. For more information on Kubernetes NetworkPolicies, you can refer to the Kubernetes Documentation on Network Policies.

Using network connect to access the container on the bridge network does not accomplish creating a container that is reachable from its host's network.The network connect command connects a container to an existing network, but it does not expose the container's ports to the host1.The bridge network is the default network that Docker creates for containers, and it provides isolation from the host network2.To create a container that is reachable from its host's network, you need to use the host network driver, which disables network isolation and uses the host's network stack directly3.Alternatively, you can use the port mapping feature to publish specific ports of the container to the host4.Reference:

docker network connect | Docker Docs

Bridge network driver | Docker Docs

Host network driver | Docker Docs

Publish ports on the host | Docker Docs