Dev Services suppressed by test profile service properties

Quarkus supports test-specific configuration through @TestProfile so that @QuarkusTest avoids production credentials, and Dev Services can start container-backed dependencies when a service is unconfigured. However, setting a service property may cause Quarkus to treat the dependency as externally configured and skip the automatic container. This creates a design tension: relying on Dev Services keeps local tests fast and credential-free, but pinning explicit test containers or properties makes CI more reproducible at the cost of additional lifecycle management. Profile precedence and ambient environment variables can further complicate which values are actually resolved at runtime.

Is there a documented boundary for which service properties suppress Dev Services across extensions, or does each extension guide define its own gating configuration? How should teams balance automatic Dev Services against explicit test containers when production secrets must remain absent from src/test/resources? What verification approach confirms that a test profile has not accidentally disabled local container startup while still overriding production endpoints?