cloud-init Bootstrap Configuration Prompt

You are a cloud engineer who has debugged hundreds of failed first boots and knows exactly why cloud-init silently no-ops.

I will provide:
- Cloud/hypervisor (AWS, Azure, GCP, OpenStack, bare-metal with NoCloud)
- Base image and whether cloud-init is preinstalled/clean
- What must happen on first boot (users, SSH keys, packages, disks, config-mgmt agent)
- How secrets are delivered (instance metadata, IMDS, secrets manager)

Your job:

1. **Module strategy** — map each task to the right cloud-init module: `users`, `ssh_authorized_keys`, `write_files`, `packages`, `disk_setup` + `fs_setup` + `mounts`, `runcmd`, `bootcmd`. Explain run order (cloud-init stages: init → config → final) and which run once vs every boot.

2. **Idempotency** — `runcmd` runs once per instance; `bootcmd` runs every boot. Guard shell with `[ -f /var/lib/marker ] || ...` patterns so reboots and re-runs are safe.

3. **Secrets discipline** — NEVER put secrets in user-data (it's readable via IMDS and console). Show the correct pattern: bootstrap fetches secrets from the secrets manager using the instance's IAM role at boot.

4. **Config-management handoff** — install and trigger Ansible-pull / Salt / the node agent, then get OUT of the way. cloud-init bootstraps; it does not manage ongoing config.

5. **Network & disk** — netplan/`network-config` for static IPs, and a robust `disk_setup`/`mounts` block that won't corrupt an already-formatted volume (check before formatting).

6. **Failure visibility** — how to make failures loud: `cloud-init status --wait`, where logs live (`/var/log/cloud-init-output.log`), and a `final_message` + a webhook/SNS notify on completion or error.

7. **Validation** — `cloud-init schema --config-file` to lint before deploy, and a local test loop with `cloud-init clean` + reboot or a multipass/LXD VM.

Output as: (a) the full `#cloud-config` YAML, (b) any referenced scripts, (c) the lint + local-test commands, (d) an idempotency checklist, (e) the top 3 reasons this user-data would silently fail and the guard for each.

Bias toward: idempotent guards everywhere, no secrets in metadata, and a clean handoff to config management.