Installation, Configuration, and Deployment
Installation, Configuration, and Deployment
This domain covers getting systems to a known, repeatable state: unattended installs, package sources, configuration management, and image lifecycle.
Core rules
- Automate installs. Linux: PXE boot with DHCP options 66/67, TFTP for the bootloader, Kickstart (
ks=kernel argument) or Ubuntu Autoinstall for answers. Windows: Windows Deployment Services or MDT with answer files. - Package management is transactional in intent:
aptanddnfresolve dependencies from configured repositories; versionlock or pinning prevents surprise upgrades. Verify GPG keys on repos. - Configuration management (Ansible, Puppet, Chef) must be idempotent - running twice gives the same end state. Prefer declarative modules over shell commands.
- Golden images reduce drift but need a re-bake cadence; otherwise you deploy known-vulnerable templates.
- Partitioning: separate
/var,/var/log,/home, and swap; use LVM for flexibility.
Worked example
You must deploy 50 identical web servers. Reasoning: build one reference VM, document every manual step, then convert those steps into a Kickstart file plus an Ansible playbook that installs packages, writes config from templates, and enables services. Test the playbook twice on a clean VM to prove idempotency. Use --check for a dry run. Tag the image with a build date and package manifest so you can answer "what is on this host?"
Traps
- Treating a snapshot as a backup or as configuration management.
- Hard-coding hostnames and IPs in images; use templates and facts.
- Forgetting to disable the install ISO repo after build, which causes package drift.
- Assuming a successful install means a correctly configured service; verify ports and health checks.