Magento 2.2 Shared Configuration Boundary: Promoting Search, Cache, and Queue Backends into config.php

Magento 2.2 introduced configuration management that splits shared settings into app/etc/config.php and environment-specific values into app/etc/env.php. In production mode, config.php is authoritative. The platform does not enforce a boundary between shared and environment-specific settings, so backends for search, full-page cache, and message queues configured in Admin before a dump can be promoted into config.php and locked for every environment that shares that file.

A deployment can appear successful in logs while the application fails at runtime because config.php references a backend that exists only in staging. The resulting error surfaces in var/log or var/report rather than in the deploy output. Because no supported command dumps everything except chosen scopes, teams must decide which entries are safe to promote and which must remain in env.php.

When a shared config.php is promoted between environments, how should teams classify catalog/search, system/full_page_cache, and queue/AMQP settings to avoid locking staging-only backends into production? What verification steps confirm that the configuration import has not overwritten environment-specific values in env.php? Is there a documented compatibility boundary for which backends are safe to share across environments in a given Magento 2.2 branch?