Configuration Management and Environment Parity
Environment parity means Dev, Stage, and Prod behave the same because configuration lives in code, not in the database or UI. For Drupal 8+, that means exporting config to YAML, committing it, and importing on each environment (drush cex / drush cim). For Drupal 7, it means features and strongarm-style approaches. The exam tests whether you know where a setting should live: code (config), environment variables (secrets and per-environment values), or the database (content).
Acquia Cloud environment variables are the key parity tool: they let the same code run against different values per environment (API keys, search indexes, cache backends). Set them in the Cloud UI or via the API; they are injected at runtime. A trap is hardcoding credentials in settings.php-the correct answer is usually an environment variable. Another trap: config that differs per environment (e.g., a Solr server name) should be split with config splits or environment-specific settings, not edited by hand in each environment.
Worked rule of thumb: if a value is a secret or differs by environment, it belongs in an environment variable or settings override. If it is application behavior, it belongs in exported config. If it is editorial content, it belongs in the database. Questions often present a settings change made in Prod's UI that disappears after the next deploy-because config was re-imported from code.
Watch for traps around config import overwriting, the order of drush cim in a deploy hook, and whether a config change should be committed to the branch that each environment tracks (it must, or the next import reverts it).