Structuring Compose files across environments

WHAT THIS TESTS This probes whether you understand Docker Compose's file-merging model and can keep multi-environment configuration DRY instead of forking entire files that drift apart.

A GOOD ANSWER COVERS Start with a base file, conventionally compose.yaml, holding the common service definitions, networks, and volumes. Compose automatically merges compose.override.yaml on top when you run plain docker compose up, which is ideal for local-only tweaks like bind mounts and debug commands. For other environments create explicit files such as compose.ci.yaml and combine them with docker compose -f compose.yaml -f compose.ci.yaml up. Files are applied left to right: scalars like image or command are overridden by the last file, while mappings such as environment are deep-merged. Mention extends or YAML anchors for sharing fragments, and externalizing secrets via env_file rather than inlining.

COMMON WRONG ANSWERS Maintaining a separate complete compose file per environment, which guarantees drift. Believing a later -f file replaces the earlier one wholesale rather than merging. Hardcoding environment-specific secrets directly in the base file.

LIKELY FOLLOW-UPS How does merge behave for lists versus maps? How do you verify the final resolved config? What does the COMPOSE_FILE environment variable do? When would you prefer extends over multiple files?

ONE CONCRETE EXAMPLE Base compose.yaml defines an api service with its image and ports. compose.override.yaml adds a source bind mount and command running a hot-reload server for local work. compose.ci.yaml instead sets command to run the test suite and points DATABASE_URL at a throwaway database. Locally you run docker compose up and get the dev override automatically; in CI you run docker compose -f compose.yaml -f compose.ci.yaml up, and you confirm the result with docker compose config, which prints the fully merged definition so there are no surprises.