Infrastructure Management: Scenario-Based Questions

A “snowflake server” is a machine that’s unique and difficult to reproduce — a configuration nightmare. In cloud-native and DevOps environments, preventing these ensures consistency, resilience, and automation.

🧊 Characteristics of Snowflake Servers

• Manual configurations over SSH
• Drift from standard setup over time
• No source-controlled provisioning logic

🏗️ How to Prevent Them

• Infrastructure as Code (IaC): Use Terraform, Pulumi, or CloudFormation to declare infrastructure.
• Immutable Infrastructure: Replace, don’t patch — use AMIs or containers.
• Configuration Management: Use Ansible, Chef, or Puppet to enforce state.
• Golden Images: Bake base images with packer or similar tooling.

🔁 Drift Detection

• Use Terraform plan drift detection in CI.
• Integrate AWS Config or GCP Policy Scanner for compliance.
• Use cron audits or daemon services to check config consistency.

✅ Best Practices

• Tag builds with version info and maintain changelogs.
• Run audits after manual interventions (patches, hotfixes).
• Train teams on self-service pipelines to avoid one-off fixes.

🚫 Common Pitfalls

• Letting “pet servers” evolve — untracked, hand-crafted VMs.
• Skipping CI validation on IaC merges.
• Overloading base images with app logic or secrets.

📌 Final Insight

Snowflake servers breed chaos in modern infra. With automation, codified infrastructure, and strict access controls, you can eliminate them — and gain reproducibility, velocity, and peace of mind.