Acquia Developer (D10) study materials
Acquia Developer (D10) study resources

Config sync drift between local and Acquia environments

Acquia Developer (D10) · Put your knowledge to work in context.

All case studies

Config sync drift between local and Acquia environments

A team deploys Drupal 10 to Acquia Cloud using a pipeline that runs drush config:import on each deploy. Local development uses config_split with a local split enabling devel and stage_file_proxy, and a prod split enabling only Acquia modules. After a release, the staging environment shows devel enabled and the local split active. The pipeline log shows config:import succeeded with no changes. The team's settings.php includes an environment-detection block that sets $config['config_split.config_split.local']['status'] = TRUE when $_ENV['AH_SITE_ENVIRONMENT'] is dev.

1. Explain the most likely cause of devel appearing on staging and how to correct it.

Read the worked answer

The environment detection in settings.php is keyed on AH_SITE_ENVIRONMENT === 'dev', but Acquia Cloud staging is test and production is prod; if staging is actually the test environment, the local split should not activate. The more likely issue is that the split status was exported: config_split stores status in the split's config entity, and if someone ran drush config:export while the local split was active in the local environment, the exported config_split.config_split.local.yml has status: true. Import then enables it everywhere unless overridden in settings. The settings override only applies if it runs after config import reads the value; settings overrides do apply at runtime, but the imported config still has status: true and the override must explicitly set it to FALSE for non-dev. Correct approach: export splits with status: false in the base config, drive activation purely via settings.php per environment, and add an explicit $config['config_split.config_split.local']['status'] = FALSE; branch for non-dev environments. Then re-export and redeploy.

2. What guard would you add to the pipeline to prevent this class of drift recurring?

Read the worked answer

Add a CI check that runs drush config:status after import and fails on any differences, plus a static check that greps exported split YAML for status: true and fails the build. Also run drush config:import --preview (or --diff) in a dry-run step on a copy of the target environment's database before the real import, so drift is visible pre-deploy rather than post-deploy.