Configuration Management

Configuration management. This lesson is about knowing what is actually running in your production environment, and being able to prove it matches what was approved.

The scene. You pull the approved change records for a production server and compare them against how the server is actually configured. A firewall rule is open that no change ever authorised. Nobody can say when it was added or by whom. The change records and the live system tell two different stories, and only one of them was approved.

Configuration management maintains an authoritative record of the configuration items that make up the I-T environment, servers, applications, network devices, their attributes and relationships, together with their approved baseline state. Often that record lives in a configuration management database, a C-M-D-B. Its purpose is to answer two questions: what is actually in production, and does it match what was authorised.

And that is why a C-M-D-B is more than an asset inventory. An asset list tells you a server exists. Configuration management records the approved state, the baseline, against which the real world can be compared. Recording the authorised state is the whole point.

Now the distinction the exam relies on, because these two are constantly confused. Change management is the process: it assesses, authorises and controls a change before it happens. Configuration management is the record: it captures what the environment actually is, after changes have happened.

They are designed to work together. Every authorised change should update the configuration record, so the baseline stays current. Change management says what should have changed; configuration management shows what did. And reconciling the two, comparing the live configuration against the record of approved changes, is exactly how unauthorised change is detected.

Which is where the open firewall rule is caught. A production configuration that differs from the baseline with no corresponding change record is the signature of an unauthorised change. That mismatch is not noise; it is the thing configuration management exists to surface.

And it means one of two things, both findings. Either something was altered without going through change management.

Or the records are not being maintained. Both are findings, and both are what configuration management is there to expose. When you see a live configuration differ from the approved baseline with nothing to account for it, you investigate.

Without a maintained baseline, the organisation is blind to all of this. It cannot tell an approved state from a drifted one, cannot detect that a rule was opened without approval, and cannot even reliably say what is running in production.

So the baseline changes the question you can ask. It turns a vague the server looks fine into a testable statement: the server matches its authorised state, or it does not. That is the shift from impression to evidence.

So carry this away. Change management authorises a change; configuration management records what the system actually is, and it is the reconciliation between them that catches what slipped through. An unexplained difference from the baseline is a potential unauthorised change to investigate, not something to wave away.