CI/CD & DevOps Practices Practice Question 7: Immutable Servers Drift
CI/CD & DevOps Practices · Test 1 · question 7 of 10
A web tier of 60 long-lived VMs is managed by a configuration management tool that runs every 30 minutes and enforces the settings it declares. Engineers sometimes SSH in to hot-fix incidents, and instances built in different years now differ in OS packages the tool never declared. A bug that appears only on some instances took a week to track down.
The team wants every running instance to match a version-controlled definition that was tested in the pipeline, with no leftover differences between instances. Which approach achieves this?
Show answer and explanation
Answer:
An immutable server is never changed after it is deployed; it is only replaced. Every change is made to the base image definition, tested automatically, and rolled out by creating new instances and destroying the old ones. Because no server lives long enough to collect unmanaged changes, this removes configuration drift entirely: every instance is built from the same tested definition (A).
Option B makes the existing tool faster, but it can only fix what it declares. Fowler points out that configuration synchronization cannot keep servers fully consistent. Undeclared items, such as packages installed through the package manager, still build up and make older instances diverge. That is the problem the stem describes.
Option C turns one snowflake server into a template. Its state came from years of manual changes, so it cannot be rebuilt from version control, and it was never tested through the pipeline. It copies the drift instead of removing it.
Option D slows new manual changes down and records them. It does nothing about the differences already on the fleet, and it does not make instances rebuildable from a tested definition.
References: Immutable Server (martinfowler.com); Configuration Synchronization (martinfowler.com)