Linux VMs on Azure: cloud-init and Extensions

cloud-init is the industry-standard, cross-platform tool for early initialization of cloud instances. It originated in Ubuntu (Canonical) and is now supported by almost all Linux distributions on Azure. Its primary purpose is to execute a set of configuration directives the *first time* a VM boots after being created from a generalized image. This is known as "first boot" or "provisioning time." The configuration is passed to the VM as a text file (typically YAML) via Azure's custom data feature. cloud-init runs before any configuration management tools (like Chef, Puppet, or Ansible) and before the VM becomes fully operational.

The mechanism is a multi-stage process that happens during the VM's initial boot cycle:

To use cloud-init, you create a YAML file (e.g., cloud-init.txt) and pass it to Azure CLI or ARM template using the --custom-data parameter. Example:

az vm create \
  --resource-group myRG \
  --name myVM \
  --image UbuntuLTS \
  --admin-username azureuser \
  --generate-ssh-keys \
  --custom-data cloud-init.txt

Example cloud-init.txt:

#cloud-config
package_upgrade: true
packages:
  - nginx
  - git
write_files:
  - path: /etc/nginx/sites-available/default
    content: |
      server {
          listen 80 default_server;
          root /var/www/html;
      }
runcmd:
  - [ systemctl, enable, nginx ]
  - [ systemctl, start, nginx ]
  - echo "Hello, Azure!" > /var/www/html/index.html

To verify that cloud-init executed successfully, SSH to the VM and check:

sudo cat /var/log/cloud-init-output.log
sudo cloud-init status  # returns 'status: done' or 'status: error'

Azure VM Extensions are small applications that provide post-deployment configuration and automation. They run *after* cloud-init completes. Common extensions include:

Extensions are applied via ARM templates, CLI, or Portal. They can be installed at VM creation or later. The exam tests that cloud-init is for *first-boot* customization, while extensions are for *ongoing* management. However, extensions can also run on first boot if deployed at creation time.

VM Extensions are managed by the Azure Guest Agent (for Windows) or the Linux Agent (waagent). The agent runs as a service and communicates with the Azure Fabric Controller over a secure channel. Extensions are downloaded from Azure storage, installed, and executed. The extension handler reports status back to Azure.

If you deploy both cloud-init and an extension at VM creation, cloud-init runs first (during boot), then the extension runs after the VM is fully booted. This ordering is important: if your extension depends on files created by cloud-init, it will work. Conversely, if cloud-init depends on an extension, it will fail because the extension hasn't run yet.

# List extensions on a VM
az vm extension list --vm-name myVM --resource-group myRG --query "[].{Name:name, ProvisioningState:provisioningState}"

# Get extension settings
az vm extension get --vm-name myVM --resource-group myRG --name myExtensionName

# View extension logs on the VM
sudo cat /var/lib/waagent/custom-script/download/0/stdout
sudo cat /var/lib/waagent/custom-script/download/0/stderr

| Feature | cloud-init | VM Extensions | |---------|------------|---------------| | Timing | First boot only | Anytime (creation, update, or post-deployment) | | Scope | OS-level configuration | Application-level or agent installation | | Idempotency | Yes (runs once) | Depends on extension (some are idempotent) | | Language | YAML or script | Script (PowerShell, Bash) or binary | | Security | Custom data visible to admins | Protected settings encrypted | | Logging | /var/log/cloud-init*.log | /var/lib/waagent/ |

The AZ-104 exam expects you to:

Mastering cloud-init and VM Extensions is essential for automating Linux VM deployments in Azure. The exam will test your ability to choose the right tool for the job and interpret configuration files. Practice creating VMs with custom data and extensions using CLI and ARM templates. Understand the ordering and limitations to avoid common pitfalls.

In a large enterprise, cloud-init is used to standardize the deployment of thousands of Linux VMs for a microservices platform. The DevOps team creates a golden cloud-init configuration that includes setting the correct timezone (UTC), installing the company’s monitoring agent (Datadog), configuring syslog forwarding to a central SIEM, and creating a local user with SSH keys for break-glass access. This configuration is stored in a Git repository and version-controlled. When developers spin up VMs for testing, they use the same cloud-init file to ensure consistency. The team also uses cloud-init to automatically resize the root partition (growpart) because their custom images are built with a small root partition (30 GB) to save storage costs. Without cloud-init, the VM would boot with only 30 GB of usable space, even if the managed disk is 128 GB. Cloud-init’s growpart module detects the disk size and expands the partition and filesystem automatically.

Another scenario involves a managed service provider (MSP) that manages VMs for multiple clients. They use Azure VM Extensions to deploy security agents (like Trend Micro Deep Security) and to join VMs to a domain. The extension is deployed after the VM is provisioned, using Azure Policy to automatically assign the extension to all VMs in a subscription. For example, they have a policy that deploys the Custom Script Extension to run a PowerShell script that installs the Trend Micro agent and registers it with the management console. The script is stored in a secured storage account with a SAS token. The extension’s protected settings contain the storage account key, which is encrypted at rest. This approach ensures that every new VM automatically gets the security agent without manual intervention.

A common failure scenario occurs when cloud-init is misconfigured with a typo in the YAML. For example, a missing colon or an incorrect indentation will cause cloud-init to ignore the entire configuration. The VM boots without any customizations, and the administrator only discovers the issue when they SSH in and find no packages installed. The fix requires deleting the VM and recreating it with the corrected cloud-init file. Another failure is when the cloud-init script tries to access an external resource (like a package repository) that is not reachable due to network security group rules. In that case, cloud-init times out and marks the instance as error. The administrator must check the cloud-init logs and adjust NSG rules accordingly. For extensions, a common issue is that the script fails because it runs as root but the script expects environment variables that are not set. The extension logs in /var/lib/waagent/ show the error, and the administrator must fix the script and re-run the extension.