What configuration precedence rules apply when overriding connection strings in ASP.NET Core integration tests using WebApplicationFactory?

The goal is to configure ASP.NET Core integration tests so that they never read production secrets while still exercising the same configuration binding logic used in production.

When using WebApplicationFactory to create a test host, developers can override settings via environment variables, user‑secrets, or testcontainers, but it is not clear which source takes precedence when the same key is supplied by more than one mechanism, nor whether the test host’s configuration builder might inadvertently fall back to a user‑secret value.

Which configuration source wins when both an environment variable and a user‑secret are defined for the same key in a test host built with WebApplicationFactory? Does setting a connection string through an environment variable guarantee that any user‑secret value for that key is ignored? Can testcontainers be combined with environment‑variable overrides without risking that the container’s internal configuration overrides the test host’s settings?