Automated Infrastructure Provisioning

Servers were being created and configured by hand, so environments drifted apart and rebuilding one from scratch was slow and error-prone.

1. L1Provisioning
   • Terraform modules
   • Remote state
2. L2Configuration
   • Ansible roles
   • Per-environment inventories
3. L3Secrets
   • Ansible Vault
   • Environment variables
4. L4Targets
   • Staging hosts
   • Production hosts

Terraform for what exists, Ansible for how it's configured

Keeping a clear boundary between provisioning and configuration made each tool easier to reason about and test independently.

Role-based playbooks

Small, focused roles (base hardening, Docker, monitoring agent, application) compose into per-host playbooks and can be reused across projects.

Environment-specific inventories and variables

The same roles run against staging and production; only inventory and group variables differ, so promotion is predictable.

• Wrote reusable Terraform modules with input variables and outputs consumed by Ansible.
• Configured remote state with locking to make concurrent runs safe.
• Built idempotent Ansible roles and verified repeated runs produce no changes.
• Encrypted sensitive variables with Ansible Vault.
• Wrapped common workflows in documented scripts.

• No plaintext secrets in the repository; vault-encrypted variables only.
• Least-privilege IAM for the provisioning identity.
• SSH key-based access only; password authentication disabled by the base role.

• Environments can be rebuilt from code instead of memory.
• Configuration changes go through review like any other code change.
• Staging and production stay aligned by construction.

• Idempotency has to be tested, not assumed — run every playbook twice.
• Keep Terraform state access tightly controlled; it can contain sensitive values.