A team must build database instances for development, test and production, and past incidents were caused by small configuration differences between environments that were set up by hand. Which provisioning approach best prevents this?
Select an answer to reveal the explanation.
Short Explanation
If you bake every cake from the same written recipe, they come out the same. A template or infrastructure-as-code file is that recipe for your database servers. Doing it by hand each time is exactly how drift sneaks in.
Full Explanation
Repeatable provisioning defines the server, storage, engine version and configuration once, in a template or infrastructure-as-code definition stored in version control, and then builds each environment from that same definition with only declared parameters, such as size or name, varying. Because the configuration is code, it can be reviewed, tested and audited, and drift can be detected by comparing a running environment with the definition. This directly addresses the incidents caused by hand-built differences. Running the vendor's wizard manually each time is the source of the problem: every click is an opportunity for an inconsistent choice, and nothing records what was selected. Cloning production nightly with live customer data does produce similar environments, but copying real PII and confidential data into lower environments violates data protection principles and should be replaced by masked or synthetic data. Letting developers adjust settings freely after building production reintroduces drift by design. Exam caveat: some parameters, such as memory or instance size, can legitimately differ between environments, but they should be explicit parameters of the template. Operational check: run a configuration comparison between development, test and production after provisioning and confirm the only differences are the declared parameters.