Problem

api is up and serving, but something's deeply wrong: it's reading and writing the staging database from what's supposed to be a production container. No crash, no error — it's just behaving as if it were staging. The image is the right one (myapp:latest). Find out why a prod container is running staging's configuration, and fix it so it uses prod config.

Initial setup

• api — myapp:latest, Up, on 8080, config bind-mounted at

/app/config.yaml.

• Host configs live at /srv/configs/ (prod.yaml, staging.yaml).

Example interaction

$ docker logs api | grep environment
[config] loaded: environment=staging

$ docker inspect -f '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{end}}' api
/srv/configs/staging.yaml -> /app/config.yaml

Acceptance

You've solved it when:

• You've established the container is running staging config because the

wrong host file is bind-mounted at /app/config.yaml (/srv/configs/staging.yaml instead of prod.yaml) — not a bad image, not an env var, not a code bug.

• You've brought api back up running with the prod config mounted

(/srv/configs/prod.yaml -> /app/config.yaml).

Constraints

• Tools: docker CLI only.
• End state: api running with prod.yaml mounted at /app/config.yaml.

Follow-up

1. Why did this fail silently (a running, "healthy" container) instead of

crashing — and why is that more dangerous?

1. A bind mount can't be changed on a live container — what's the minimal

sequence to swap the mounted file?

1. How would mounting configs read-only, or by a content hash, have caught

the wrong file earlier?