Implementation and Configuration
This domain tests configuration management, build and release discipline, environment parity, and change control. Questions often describe a defect that appears in one environment and ask for the most likely cause or the first control to add.
Core rules
- Identify configuration items and place them under version control. Use a branching strategy that matches release cadence and team size.
- Baselines are approved states; changes require a request, impact analysis, approval, implementation, verification, and closure.
- Continuous integration builds and tests on every change; continuous delivery promotes tested artifacts through environments with automated gates.
- Maintain environment parity for runtime versions, configuration values, and dependencies. Treat configuration as code and keep secrets in a managed secret store, never in the repository.
- Distinguish version from release: a version identifies a configuration; a release is a deployed collection of items made available to users.
- Plan rollback or roll-forward before deployment, and verify that the plan has been exercised.
Worked example
An application works in staging but fails in production with timeouts. The application artifact version is identical, but the production configuration has a 30-second timeout while staging uses 5 seconds, and a proxy setting differs. Compare configuration baselines and environment diffs before changing code. The fix is to codify the timeout and proxy settings, promote them through the pipeline, and add a smoke test that exercises the real dependency path. Reasoning: the defect is configuration drift, not a code regression.
Traps
- Making manual production changes that bypass version control.
- Conflating a build with a release or a version with a deployment.
- Storing secrets in source code or build logs.
- Deploying without a tested rollback path.
- Allowing uncontrolled hotfixes that never return to the mainline.