What is cloud-init and How Does It Work?
Learn what cloud-init is, how it fetches user data at first boot, and how it differs from Packer for provisioning cloud instances.
Expected Interview Answer
cloud-init is the industry-standard boot-time initialization tool that runs during a cloud instance's first boot to apply provider-supplied metadata and user-supplied configuration — setting the hostname, creating users, installing packages, and running scripts — so a generic base image becomes a specifically configured instance without needing a custom pre-baked image for every variation.
When a cloud instance boots, cloud-init fetches metadata and “user data” from the cloud provider's metadata service (a well-known local endpoint like 169.254.169.254), where user data is typically a YAML "cloud-config" document or a shell script supplied at instance-launch time through the provider console, CLI, or Terraform's user_data / custom_data argument. cloud-init then runs through its staged modules — network configuration, hostname/FQDN setup, SSH key injection, user and group creation, package installation, and arbitrary runcmd shell commands — in a defined order across its Init, Config, and Final stages, logging everything to /var/log/cloud-init.log for debugging. Because it only reliably runs on true first boot (state is tracked so it does not re-run on every reboot), cloud-init is best suited to lightweight, instance-specific customization like registering with a config management tool or setting environment-specific variables — not for heavyweight software installs, which belong in a Packer-built golden image for faster, more reliable boots. In short, Packer bakes the image once; cloud-init personalizes each individual instance launched from that image at boot time.
- Lets one generic base image serve many differently configured instances
- Automates first-boot setup (users, SSH keys, packages) without manual login
- Integrates cleanly with Terraform via the user_data argument
- Provides a standard, cross-provider mechanism (AWS, Azure, GCP, OpenStack)
AI Mentor Explanation
cloud-init is like a generic kit bag delivered to a new player that includes a sealed instruction card specific to that player — their squad number, their locker assignment, which practice group to join — read and acted on the very first time they arrive at the ground. The bag itself is identical for every player; it is the personalized card, read once on arrival, that makes it theirs. If the player leaves and returns the next day, that first-arrival card is not re-read — the setup already happened. A full kit re-fitting for major changes still happens back at the factory, not through this arrival card.
Step-by-Step Explanation
Step 1
Instance boots for the first time
cloud-init starts as an early boot service before user-facing services launch.
Step 2
Fetch metadata and user data
It queries the cloud provider's metadata service for instance metadata and provider/Terraform-supplied user data (cloud-config YAML or a script).
Step 3
Run staged modules
Across Init, Config, and Final stages it sets hostname, injects SSH keys, creates users, installs packages, and runs runcmd commands, in order.
Step 4
Mark first-boot complete
cloud-init records that it has run so it does not re-execute on subsequent reboots, and logs everything to /var/log/cloud-init.log.
What Interviewer Expects
- Understanding cloud-init runs at first boot, sourced from provider metadata and user data
- Knowledge of what a cloud-config YAML document typically configures
- Ability to distinguish cloud-init (per-instance, first-boot) from Packer (per-image, pre-baked)
- Awareness of how Terraform supplies user_data to trigger cloud-init
Common Mistakes
- Confusing cloud-init with a general configuration management tool that runs continuously
- Assuming cloud-init re-runs on every reboot rather than only the first boot
- Using cloud-init for heavyweight software installs instead of baking them into the image
- Forgetting to check /var/log/cloud-init.log when debugging a failed first boot
Best Answer (HR Friendly)
“cloud-init is what runs automatically the very first time a new cloud server boots up, and it takes care of things like setting the hostname, creating the right users, adding SSH keys, and running any startup script we supply. It means we can use the same generic base image everywhere and still get a server that is correctly personalized the moment it comes online, without anyone logging in manually.”
Code Example
#cloud-config
hostname: web-01
users:
- name: deploy
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- ssh-ed25519 AAAAC3Nza... deploy@ci
package_update: true
packages:
- nginx
runcmd:
- systemctl enable nginx
- systemctl start nginxFollow-up Questions
- Where does cloud-init fetch user data from on an AWS EC2 instance?
- How is cloud-init different from Packer in the image-vs-instance lifecycle?
- Why would you avoid installing a large software stack purely via cloud-init runcmd?
- How would you debug a cloud-init failure on first boot?
MCQ Practice
1. When does cloud-init reliably run on a cloud instance?
cloud-init tracks that it has run and is designed to execute reliably only on first boot, not on subsequent reboots.
2. Where does cloud-init typically get its user-supplied configuration from?
User data (cloud-config YAML or a script) is supplied at instance launch and fetched by cloud-init from the metadata service.
3. How does cloud-init typically relate to Packer in a deployment pipeline?
Packer produces a pre-baked image; cloud-init applies lightweight, instance-specific customization the first time an instance from that image boots.
Flash Cards
What is cloud-init? — A boot-time tool that applies provider metadata and user data to personalize a cloud instance on first boot.
Where does cloud-init get user data from? — The cloud provider's metadata service, populated by launch-time user_data (e.g. from Terraform).
Does cloud-init re-run on every reboot? — No — it is designed to run reliably only on the instance's first boot.
How does cloud-init differ from Packer? — Packer bakes a golden image once; cloud-init personalizes each individual instance at first boot.