Deploying Actions and Packages
Packages define what; actions define who and when
Two objects do all the work in Deploy. A package is the payload: one or more files plus a command line that runs on the endpoint. Files are staged into the client's local download cache and the command line references them there. An action is a package plus a targeting question (which endpoints), a schedule (now or later, optionally distributed over time to avoid a thundering herd), a run-as identity, and an expiration after which endpoints stop trying.
Constraints that questions love to test: package commands must be silent and non-interactive - no prompts, no GUI - because they run in a non-interactive session, by default as LocalSystem on Windows. Exit codes are interpreted: 0 means success, and 3010 means success but a reboot is required; any other code is reported as a failure. Action status moves through Pending, Active, Completed, Expired, and Stopped. Stopping an action halts future delivery but does not undo work already performed on endpoints.
If action approval is enabled in the environment, a second authorized user must approve a queued action before it deploys - a separation-of-duties control worth naming when a question asks how to prevent one administrator from pushing unapproved changes.
Rule of thumb: before deploying, run the exact targeting question and read both the result count and the endpoint list. An action that reaches the wrong endpoints cannot be un-run - only remediated.