Docker Compose: Multi-Container Orchestration Quiz Quiz

Challenge your understanding of Docker Compose features, configuration, and best practices for orchestrating multi-container applications. This quiz will help you assess key concepts, YAML syntax, networking, and common pitfalls in multi-container setups.

  1. Service Dependency Management

    In a Docker Compose YAML file, how can you ensure that the 'web' service only starts after the 'db' service has been started, assuming you want to control service startup order?

    1. Use the 'depends_on' key under the 'web' service definition
    2. Place db above web in the YAML file
    3. Set 'priority: high' for the db service
    4. Add a 'wait_for' entry in the db service

    Explanation: The 'depends_on' key specifies service dependencies to control startup order, making it the correct option for managing dependencies in Compose. 'wait_for' and 'priority' are not recognized configuration keys in standard Compose files. Simply changing the order of services in the YAML does not establish dependency relationships.

  2. Network Isolation

    When multiple services are defined in a Docker Compose file without specifying custom networks, what is the default networking behavior between them?

    1. Each service is on its own isolated network by default
    2. Services require manual linking to communicate
    3. A bridge network must be explicitly defined for communication
    4. All services are connected to the same default network and can communicate by service name

    Explanation: By default, Compose creates a single network for the entire application and attaches each service to it, allowing inter-service communication via service names. Isolated networks for services do not happen automatically. Explicit bridge network configuration is not needed unless you require customization, and 'links' is deprecated and unnecessary for basic communication.

  3. Volume Configuration

    Which option correctly attaches a persistent named volume to the '/data' directory inside a service container in Docker Compose?

    1. mounts:n - type: bind, source=data, target=/data
    2. volumes:n - data_volume:/data
    3. storage:n - ./data:/data
    4. binds:n - ./data:/data

    Explanation: The correct Compose syntax for named volumes uses the 'volumes' key and the format 'name:/path', such as 'data_volume:/data'. 'storage', 'mounts', and 'binds' are not recognized keys or are improperly formatted in Compose YAML files. The provided distractors contain incorrect keywords or unsupported options.

  4. Scaling Services

    How can you run three instances of the 'worker' service defined in a Docker Compose file, assuming the YAML is correctly configured?

    1. Adding 'replicas: 3' under the 'worker' service
    2. Adding 'count: 3' in the Compose file
    3. Using 'docker compose up --scale worker=3'
    4. Modifying the service name to 'worker3'

    Explanation: The '--scale' command-line flag is used during Compose deployment to run multiple instances of a service. The 'replicas' option is relevant only for some other orchestration platforms, not standard Compose. Changing the service name or adding 'count' does not implement scaling in Compose.

  5. Environment Variable Injection

    In Docker Compose, how can you set an environment variable called 'APP_ENV' with the value 'production' for a specific service?

    1. Under the service, use 'environment: APP_ENV=production'
    2. Use 'env_vars: APP_ENV: production' under the service
    3. Place 'export APP_ENV=production' at the top of the YAML
    4. Add 'set APP_ENV production' in the service definition

    Explanation: Setting environment variables for a service in Compose is done with the 'environment' key and the format 'VAR=value'. Adding 'export' or 'set' commands or using unsupported keys like 'env_vars' in YAML is not valid. These alternatives would not inject environment variables correctly.