An operations team patches a fleet of long-running cloud servers by hand. Over time their configurations have drifted apart, and no two servers are identical, which makes vulnerability findings hard to remediate consistently. Which practice best addresses this?
Select an answer to reveal the explanation.
Short Explanation
Instead of repairing each dented car by hand, you roll a fresh one off the assembly line every time. That's immutable architecture: patch the image, replace the server. The trap is more manual patching, which is exactly how the drift started.
Full Explanation
Immutable architecture treats running servers as disposable. Changes, including security patches, are made to a versioned, hardened golden image or template, tested once, and then rolled out by replacing instances rather than modifying them in place. Every server built from the same image is identical, so drift disappears, vulnerability findings map to a single image version, and remediation becomes rebuilding and redeploying. Baselines and hardening are enforced at build time and verified automatically. More frequent manual patch windows with checklists keep the same human-driven process that produced the drift, and checklists are followed inconsistently across a fleet. Standing root access to fix drift increases privilege exposure and encourages further undocumented changes, making the fleet less consistent. Snapshots before changes help recovery from a bad change but do not converge servers to one known-good state; rolling back simply restores a different drifted configuration. Exam caveat: the 2026 outline adds immutable architecture and hardening to security hygiene; logs and state must be externalized so replacing a server loses nothing. Operational check: compare running instances against the approved image version, flag any server running an older or unknown image, and confirm interactive logins to production hosts are disabled or alerted on.