What is HashiCorp Packer and When Would You Use It?
Learn what Packer does, how builders and provisioners create golden images, and why it pairs with Terraform in modern DevOps pipelines.
Expected Interview Answer
Packer is a tool that automates building identical, pre-configured machine images — such as AWS AMIs, Azure images, or VM templates — from a single declarative template, so every server launched from that image starts already fully configured instead of being configured after boot.
A Packer template (HCL) defines one or more “builders” that specify the target platform (amazon-ebs, azure-arm, vsphere-iso, docker), a “source” base image to start from, and a “provisioners” section — often shell scripts or an Ansible playbook — that installs packages and applies configuration inside a temporary instance Packer spins up just for the build. Once provisioning finishes, Packer snapshots that temporary instance into a finished image and tears down the builder instance, leaving only the reusable artifact behind. This produces “golden images”: immutable, pre-baked images that boot in seconds because there is no configuration step at launch, in contrast to configuring a plain base image with Ansible or cloud-init every time an instance starts. Packer is commonly paired with Terraform, where Terraform references the AMI ID that Packer produced, giving a clean separation between “what the machine looks like” (Packer) and “how many, where, and how they are networked” (Terraform).
- Produces immutable golden images that boot already fully configured
- Eliminates configuration-drift risk from per-boot provisioning scripts
- Speeds up autoscaling since new instances need zero setup time at launch
- Builds the same image consistently across AWS, Azure, GCP, or on-prem
AI Mentor Explanation
Packer is like a factory that pre-assembles a complete, ready-to-play kit bag — bat strung, pads fitted, spikes broken in — once, in a controlled workshop, rather than making every young player break in their own gear on match morning. The workshop follows an exact assembly template, tests the finished kit, then ships identical kit bags to every academy. A player picking up one of these bags is ready to walk out and play immediately, with zero setup time at the ground. Compare that to handing every player raw gear and a fitting checklist to complete themselves before every single match.
Step-by-Step Explanation
Step 1
Write a Packer template
Define a builder (target platform), a source base image, and provisioners (shell/Ansible) in HCL.
Step 2
Run packer build
Packer spins up a temporary instance from the source image on the target platform.
Step 3
Provision the instance
Shell scripts or an Ansible playbook install packages and apply configuration inside that temporary instance.
Step 4
Snapshot and clean up
Packer captures the configured instance as a golden image (e.g. AMI) and destroys the temporary builder instance.
What Interviewer Expects
- Understanding that Packer produces immutable pre-baked images, not runtime configuration
- Knowledge of builders, source images, and provisioners as the three template concepts
- Ability to explain the golden-image pattern versus configuring instances at boot
- Awareness that Packer and Terraform are complementary, not competing, tools
Common Mistakes
- Confusing Packer with a configuration management tool like Ansible itself
- Thinking Packer manages running infrastructure rather than building images
- Forgetting the temporary builder instance is destroyed after the image is captured
- Not knowing Packer output (an image ID) is typically consumed by Terraform
Best Answer (HR Friendly)
“Packer lets us build a fully configured server image once, in an automated and repeatable way, rather than configuring every new server after it boots. We define what the image should contain, Packer builds and tests it, and then every instance we launch from that image is already ready to go — which makes scaling up much faster and removes the risk of servers drifting apart in configuration.”
Code Example
source “amazon-ebs” "app" {
ami_name = "myapp-{{timestamp}}"
instance_type = "t3.micro"
region = "us-east-1"
source_ami_filter {
filters = {
name = "ubuntu/images/*22.04-amd64-server-*"
}
owners = ["099720109477"]
most_recent = true
}
ssh_username = "ubuntu"
}
build {
sources = ["source.amazon-ebs.app"]
provisioner “ansible” {
playbook_file = "./playbook.yml"
}
}Follow-up Questions
- How does Packer decide when the image build is finished?
- Why pair Packer with Terraform instead of using either alone?
- What is the golden-image pattern and why does it speed up autoscaling?
- How would you build one Packer template that targets both AWS and Azure?
MCQ Practice
1. What is the primary output of a Packer build?
Packer produces a reusable, pre-configured image artifact, not a running server or infrastructure state.
2. What happens to the temporary instance Packer creates during a build?
Packer provisions a temporary builder instance, snapshots it into an image, then tears the instance down.
3. Why is Packer commonly paired with Terraform?
Packer produces the golden image; Terraform then provisions infrastructure (e.g. instance count, networking) using that image as the source.
Flash Cards
What does Packer produce? — A pre-configured, reusable machine image (e.g. an AWS AMI or VM template).
What are the three key Packer template concepts? — Builders (target platform), source image, and provisioners (shell/Ansible).
What is a golden image? — An immutable, pre-baked image that boots already fully configured, with no setup step at launch.
How do Packer and Terraform typically pair? — Packer builds the image; Terraform provisions infrastructure referencing that image ID.