Environment Variables Usage in Docker Compose Quiz

Explore the essential aspects of handling environment variables in Docker Compose with this quiz. Assess your understanding of variable declaration, substitution, scope, and best practices within docker-compose files.

1. Specifying Variables in Compose Files

   When defining environment variables for a service in a docker-compose.yml file, which key should you use to pass them directly into the container process?

   1. environment
   2. env_file
   3. environ
   4. expose_vars

   Explanation: The 'environment' key allows you to define environment variables that are passed directly to the container at runtime. 'env_file' is used to import variables from an external file, not to define them inline. 'environ' and 'expose_vars' are not valid keys in docker-compose syntax, though their names sound similar or plausible.

2. Variable Substitution from Host Environment

   If docker-compose.yml contains the line MY_SECRET: ${SECRET_KEY}, how does Docker Compose resolve the value of MY_SECRET at runtime?

   1. It retrieves SECRET_KEY from the host environment variables.
   2. It prompts the user for a value if SECRET_KEY is missing.
   3. It automatically generates a random value.
   4. It sets MY_SECRET to the literal string '${SECRET_KEY}'.

   Explanation: Docker Compose substitutes ${SECRET_KEY} with the value from the host's environment variables, enabling dynamic configuration. It does not prompt interactively or auto-generate values. If SECRET_KEY is missing, unless a default is set, Compose may fail or leave it empty; it will not use the literal string with the brackets.

3. Supplying Multiple Environment Variables Externally

   Which method allows you to import several environment variables into a service from an external file called env.list?

   1. Using env_file: env.list
   2. Using export: env.list
   3. Listing env.list under environment_vars:
   4. Referencing include_env: env.list

   Explanation: The 'env_file' option specifies an external file (like env.list) containing environment variable pairs, which Compose reads and applies. 'export' and 'include_env' are not valid keys, and 'environment_vars' is incorrect since Compose recognizes the singular 'environment'. Only 'env_file' is correct in this context.

4. Overriding Environment Variables

   What happens if you define an environment variable with the same name in both the environment section and an env_file for a service?

   1. The value in the environment section takes precedence.
   2. Compose throws an error and stops.
   3. The env_file value always overrides the environment section.
   4. Both values are merged and passed together.

   Explanation: When an environment variable is defined in both the environment section and an env_file, the value from the environment section takes precedence and overrides the value from the file. Compose does not throw an error, nor does it merge both values or let the file value override the inline one.

5. Best Practices for Sensitive Data

   For storing sensitive secrets like passwords in Docker Compose, which approach is recommended to avoid exposing them in version control?

   1. Use an env_file listed in .gitignore to keep credentials out of source code.
   2. Write secrets directly in the docker-compose.yml under the environment key.
   3. Define all sensitive data as build-time ARGs in the Dockerfile.
   4. Store secrets in comments within the compose file for reference.

   Explanation: Storing sensitive data in an env_file that is excluded from version control helps protect secrets from being exposed in source repositories. Including passwords directly in the compose file or as comments risks accidental exposure. While build-time ARGs can pass sensitive data, their values may still be visible in image history; so this is not best practice for secrets.