Some API operations are one-off actions with no idempotent “get” — reset, rebuild, migration, hour reservation. Both providers model these as trigger strings: the action fires only when the value changes, and you re-fire it by changing the value again.
One-shot triggers
To rebuild again, change the value — a common pattern is timestamps or counters:
Rebuilds wipe the VM disk. Use them deliberately.
Pulumi
Change the string to re-fire — e.g. rebuildOs: "ubuntu-22-" + Date.now() (computed at program evaluation).
Declarative power state
Power actions are declarative, not triggers: the provider calls the API only when the desired state differs.
If the portal (or someone else) changes the power state out of band, the next apply/up reconciles it.
Side-effecting data sources
gpu_console / gpuConsole mints a new one-time console session on every read. Treat it as an action, not as a lookup: reference it where a fresh session is wanted, and never inside values evaluated during plan diffing.