An engineer at Cascade Regional Airlines is deploying a Linux VM to monitor seasonal booking-load spikes and wants it to install a monitoring agent and write a configuration file automatically the very first time it boots, using a standard, cloud-platform-agnostic method rather than an Azure-specific tool. Which approach fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
Cloud-init is like a to-do list you hand the VM before it's even born, written in a format that works the same way across Azure, AWS, or anywhere else. It runs automatically during the very first boot, installing packages and writing files without any Azure-specific tooling involved. That portability is exactly what makes it different from an Azure-only mechanism.
Full Explanation
Cloud-init is a widely adopted, cross-platform initialization method for Linux (and some other) VMs: you supply a configuration at VM creation time, and it executes automatically during the first boot to install packages, write files, and run commands, without depending on any Azure-specific agent. That combination — first-boot automation, cloud-agnostic format — is precisely what the scenario asks for. An availability set has nothing to do with executing configuration; it only controls how VMs are distributed across fault and update domains for resiliency, so 'triggering' configuration from it is not a real mechanism. Running the Custom Script Extension on a recurring weekly schedule is an Azure-specific tool, which fails the portability requirement, and it also doesn't match 'the very first time it boots' — it describes ongoing scheduled runs, not one-time first-boot provisioning. Restoring a disk snapshot after boot doesn't configure a live, already-running VM's first boot; a snapshot is a data copy, not an execution mechanism, and applying it after the fact is backwards from the requirement. As an operational check, review the VM's cloud-init logs (commonly under /var/log/cloud-init.log) to confirm the configuration actually ran successfully on first boot rather than assuming it silently worked.