What a machine image is and why it matters

WHAT THIS TESTS The interviewer is checking whether you understand the difference between a template and a running resource, and why immutable images underpin elastic, reproducible infrastructure.

A GOOD ANSWER COVERS Define the image as a read-only template that captures the operating system, installed packages, application code, and configuration at a point in time. AWS calls it an AMI, Azure offers managed images and the Shared Image Gallery, and GCP uses custom images. Launching from an image yields an identical instance without re-running install steps, so it is fast and deterministic. That speed and sameness is exactly what auto-scaling depends on: when load rises, the scaling group launches new instances from one image, and every node is byte-identical to its peers. This also enables immutable infrastructure, where you replace instances instead of patching them in place.

COMMON WRONG ANSWERS Describing an image as a running VM rather than a template. Treating it as merely a backup, ignoring its role in fleet provisioning. Baking secrets, hostnames, or per-instance state into the image, which breaks reproducibility and creates security risk.

LIKELY FOLLOW-UPS How do you build and version images, for example with Packer. What goes in the image versus in user-data or a config management step. How do you keep images patched and avoid drift. How do golden images interact with launch templates.

ONE CONCRETE EXAMPLE A team uses Packer to bake a golden image containing the OS, the app server, and the application binary, tagged with a version. Their auto-scaling group references a launch template pointing at that image. When traffic spikes, the group launches five new instances from the image in under a minute, each identical and ready to serve, with secrets pulled at boot from a secrets manager rather than embedded in the image.