Ops wants OS packages, services, and config files on city VMs installed identically every time. Which practice fits best?
Select an answer to reveal the explanation.
Short Explanation
Think of a restaurant recipe card for every server—same packages, same services, same config files, every kitchen. That is configuration as code, not hoping last night's SSH session somehow sticks.
Full Explanation
Configuration as code codifies packages, services, and files so city VMs reach a known desired state consistently every time automation runs. It complements infrastructure as code by focusing on guest and application configuration rather than only cloud resource graphs. Disabling package managers and relying only on AMI defaults forever fails because baselines still drift and many civic requirements need explicit package and service enforcement after first boot. Storing SSH session recordings as the configuration baseline fails; recordings are forensic artifacts, not convergent desired state. Placing all runtime settings only in undocumented console sticky notes fails auditability and repeatability. Exam caveat: Cloud+ separates IaC (provision resources) from configuration management as code (configure systems)—both matter for identical municipal builds. Operational check: express packages, services, and files in a managed repository, apply via pipeline or config agent, verify idempotent re-runs, and scan for drift after emergency SSH changes. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate.