The Configuration Management Initiative (CMI) is one of the most significant architectural changes introduced in Drupal 8. It fundamentally changed how Drupal stores, tracks, deploys, and synchronizes site configuration across environments.
Before CMI, configuration lived primarily in the database and was difficult to version, deploy, or audit. With CMI, configuration became exportable, version controlled, and environment aware, aligning Drupal with modern DevOps and enterprise workflows.
The goal is to understand CMI as a core system, not just how to run drush cex.
Why CMI Belongs in Core Architecture
Configuration is not content. It defines how the system behaves.
CMI is responsible for:
- Defining site structure and behavior
- Separating configuration from content
- Enabling environment based deployments
- Supporting version control and CI/CD
- Providing deterministic site builds
Nearly every core subsystem depends on configuration.
What Is Configuration in Drupal
Configuration represents site settings and structure, not user generated content.
Examples:
- Content types and fields
- Views definitions
- Image styles
- Text formats
- Roles and permissions
- Site settings
Configuration answers the question: How is the site built?
Pre-CMI vs Post-CMI
Before Drupal 8:
- Configuration stored in database tables
- Export through Features or custom code
- Hard to synchronize environments
Drupal 8 and later:
- Configuration stored as YAML
- Exported to the filesystem
- Imported deterministically
- Tracked in version control
This shift is foundational to modern Drupal architecture.
Active vs Staged Configuration
Drupal maintains two main configuration states.
Active Configuration
- Lives in the database
- Used by the running site
- Modified via UI or APIs
Staged Configuration
- Lives in the filesystem
- Stored as YAML files
- Used for deployment
CMI synchronizes staged configuration into active configuration.
Configuration Storage System
Drupal abstracts configuration storage using storage backends.
Common storages:
- Database storage (active)
- File storage (sync directory)
This abstraction allows Drupal to compare, import, and export configuration consistently.
Configuration Objects
Each configuration item is identified by a unique name.
Examples:
- system.site
- node.type.article
- views.view.frontpage
Configuration objects:
- Are immutable at runtime
- Are read through the Config API
- Are cached for performance
The Config API
Drupal provides a dedicated API for configuration access.
$config = \Drupal::config('system.site');
$site_name = $config->get('name');
For write operations:
$config = \Drupal::service('config.factory')->getEditable('system.site');
$config->set('name', 'New name')->save();
Configuration should never be modified directly in storage.
Configuration Dependencies
Configuration entities declare dependencies.
Dependencies ensure:
- Safe import order
- Correct removal of unused config
- Consistent environment sync
Example dependencies:
- Module dependencies
- Theme dependencies
- Other configuration entities
Broken dependencies cause import failures.
Configuration Entities vs Simple Configuration
Drupal distinguishes between two configuration types.
Simple Configuration
- Key value based
- Stored in single YAML file
- Example: system.site
Configuration Entities
- Structured objects
- Have IDs and labels
- Support CRUD
- Example: views, content types
Both types participate fully in CMI.
Configuration Synchronization
Configuration sync is a controlled operation.
Process:
- Export configuration from active storage
- Commit YAML to version control
- Deploy code to target environment
- Import configuration into active storage
This ensures predictable deployments.
Partial Configuration Imports
Drupal supports partial imports.
Use cases:
- Feature specific deployment
- Emergency fixes
- Environment specific overrides
Partial imports must be used carefully to avoid drift.
CMI and Environments
CMI enables multi environment workflows:
- Local
- Development
- Test
- Production
Each environment shares the same configuration baseline but may override specific settings.
Configuration Overrides
Overrides allow environment specific values.
Common methods:
- settings.php overrides
- settings.local.php
- Environment specific settings
Overrides do not modify exported configuration.
Common Mistakes
- Editing YAML directly in production
- Treating configuration as content
- Ignoring configuration dependencies
- Importing config without reviewing changes
- Storing secrets in configuration
CMI enforces discipline, not convenience.
Drupal 10 and 11 Best Practices
- Treat configuration as code
- Keep sync directory out of public files
- Use config splits for environment differences
- Review config diffs before import
- Automate config sync in CI pipelines
How CMI Fits with Other Core Systems
CMI integrates tightly with:
- Entity API
- Permissions system
- Routing system
- Plugin system
- Cache system
Many systems are defined entirely by configuration.
Acquia Exam Notes and Cheat Sheet
Key points to remember:
- CMI introduced in Drupal 8
- Configuration is stored as YAML
- Active config lives in the database
- Staged config lives in the filesystem
- Config is not content
Common exam traps:
- Confusing configuration with content
- Editing config directly in the database
- Forgetting dependencies during import
- Assuming overrides export automatically
Quick decision guide:
- Site structure: configuration
- User generated data: content
- Environment specific values: overrides
- Deployment consistency: CMI
If the question mentions YAML config deployment, CMI is the answer.
Summary
The Configuration Management Initiative is a foundational architectural system that transformed Drupal into a modern, deployable, and scalable platform. By separating configuration from content and enabling deterministic synchronization, CMI underpins Drupal’s enterprise readiness and DevOps workflows. Mastery of CMI is essential for Drupal 10 and 11 architecture and for Acquia certification success.
This article prepares you for advanced topics such as config entities internals, config schema, and configuration splitting strategies.