4.2 Deploying Actions: Entry Points, Targeting, Distribution and Approval

4.2 Deploying Actions: Entry Points, Targeting, Distribution and Approval

Quick overview: An action is a configuration object you deploy to endpoints to manage a change on them. In the action configuration you specify the package that performs the change, endpoint targeting criteria such as an action group, and deployment conditions such as scheduling. Blueprint objective TA-1 — given a scenario, make changes to an endpoint — is this workflow, and the parts that go wrong in practice are targeting, distribution and approval.

---

1. Where an action deployment starts

Tanium gives you several entry points, and choosing the right one is often the whole answer to a scenario item.

[!IMPORTANT] The 100-row limit is real and it is a design signal. If your population is larger than 100 endpoints, Tanium is telling you to express it as a computer group or a saved question rather than as a hand-selected list. Hand-selection does not scale and does not survive being repeated next month.

Simple and adaptive actions

The distinction has practical consequences: Distribute Over can be set only for simple actions, not for adaptive actions, and stopping them differs — you disable or delete a simple action, whereas an adaptive action is stopped, paused or resumed from its deployment pages.

---

2. Action groups: the targeting boundary

Actions are targeted through action groups. An action group defines the set of computer groups an action is permitted to reach, and it exists to bound the blast radius of a deployment independently of the question or group that discovered the problem.

The mental model to carry into an exam item: the question finds the endpoints, the action group constrains where the change is allowed to land. If an operator can see an endpoint in question results but cannot deploy to it, the action group is the first thing to check after computer management group assignment.

Quick Summary: Deploying an Action is the mechanism by which a static Tanium Package is executed across a targeted set of enterprise endpoints. Operators can deploy actions interactively from question results in Interact or schedule recurring actions from the administration workspace. Critical deployment parameters include Targeting Filters (scoping who runs the action), Schedule Start Time (when execution begins), Distribute Over (randomly spreading execution over hours to eliminate network spikes), and Expiration Time (defining how long offline endpoints have to check in and execute). Understanding how these timing controls interact and tracking action execution lifecycle states is essential for enterprise operations and the TCO exam.

---

1. Action Deployment Workflows & Console Entry Points

Tanium provides two primary operational entry points for deploying actions:

+---------------------------------------------------------------------------------------------------+
|                                 ACTION DEPLOYMENT ENTRY POINTS                                    |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|  ENTRY POINT A: Interact Results Grid (Contextual Triage & Remediation)                          |
|  1. Operator asks a question in Interact: `Get Installed Applications contains "VulnerableApp"`    |
|  2. Results grid displays matching rows (e.g., 250 endpoints return "VulnerableApp 1.0").         |
|  3. Operator selects the row(s) and clicks `Deploy Action`.                                       |
|  4. Tanium automatically pre-populates the targeting filter with the exact sensor query criteria. |
|  5. Operator selects the remediation package, enters parameters, and deploys.                     |
|                                                                                                   |
|  ENTRY POINT B: Packages / Actions Administration (Direct & Scheduled Deployment)                 |
|  1. Operator navigates to `Administration > Actions > Deploy Action` (or Packages catalog).        |
|  2. Operator selects the desired Package directly from the catalog.                               |
|  3. Operator manually defines the target Computer Group or builds a custom targeting expression.  |
|  4. Operator configures one-time or recurring scheduling options and submits the action.          |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

---

2. Action Targeting Architecture & Scope Safety

Targeting controls ensure that an action executes only on the specific machines intended by the operator. Tanium uses a multi-layered security model to prevent accidental mass deployments:

+---------------------------------------------------------------------------------------------------+
|                                  ACTION TARGETING GOVERNANCE                                      |
+---------------------------------------------------------------------------------------------------+
|                                                                                                   |
|                          [ Operator User Persona Permissions ]                                    |
|                                            │                                                      |
|                                            ▼                                                      |
|                         [ Action Group Scope (Computer Groups) ]                                  |
|                                            │                                                      |
|                                            ▼                                                      |
|                      [ Targeting Question Filter (Sensor Expression) ]                            |
|                                            │                                                      |
|                                            ▼                                                      |
|                      [ FINAL EFFECTIVE TARGET: Matching Endpoints ]                               |
|                                                                                                   |
+---------------------------------------------------------------------------------------------------+

Targeting Components

1. Operator Persona Scope: An operator can never deploy an action to endpoints outside their assigned management rights computer groups (e.g., a Windows Server Admin persona cannot target macOS endpoints).
2. Action Groups: An administrative configuration object that assigns specific computer groups to action execution boundaries. Scheduled and recurring actions must be assigned to an Action Group.
3. Targeting Question Filters: The real-time filter expression evaluated by endpoints. For example: Is Windows equals True and Operating System contains "Server" and Disk Free Space < 10 GB.

The Dual-Filter Evaluation Rule

When an endpoint receives an action instruction, it evaluates both its membership in the target Action Group and the specific question filter. If the endpoint does not satisfy both criteria simultaneously, it discards the action instruction without downloading payloads or executing code.

3. Action Timing Controls: Start, Distribution & Expiration

Configuring action timing is a critical operational skill tested heavily on the TCO exam. Three distinct timing controls dictate how and when an action executes:

+---------------------------------------------------------------------------------------------------+
|                                   ACTION TIMING PARAMETERS                                        |
+---------------------------------------------------------------------------------------------------+
|  TIMING PARAMETER        | DEFINITION & MECHANICS                 | TYPICAL VALUE & SCENARIO      |
+--------------------------+----------------------------------------+-------------------------------+
|  1. Schedule Start Time  | Specifies the exact date/time when     | Immediate (Now) for incidents;|
|                          | endpoints are authorized to begin      | Future Maintenance Window     |
|                          | executing the action.                  | (e.g., Saturday at 02:00 UTC).|
+--------------------------+----------------------------------------+-------------------------------+
|  2. Distribute Over    | Spreads the execution start time       | 2 to 4 hours for large apps;  |
|     (Distribute Over)        | randomly across endpoints over a       | 0 minutes for emergency       |
|                          | configured duration window.            | incident containment.         |
+--------------------------+----------------------------------------+-------------------------------+
|  3. Expiration Time      | The duration during which the action   | 2 hours for active incidents; |
|     (Action Lifespan)    | remains active on the Tanium Server    | 3 to 7 days for mobile /      |
|                          | for offline endpoints to receive.      | roaming laptop workforces.    |
+--------------------------+----------------------------------------+-------------------------------+

Deep-Dive: Distribute Over

If an administrator deploys a 1 GB software package to 100,000 endpoints simultaneously with Distribute Over = 0, every machine will attempt to install the software at the exact same second. This can cause:

• Thundering Herd Network Spikes: Saturated local network switches and proxy gateways.
• Storage I/O Bottlenecks: Virtual Desktop Infrastructure (VDI) SAN storage lockups ("boot storms").
• Backend Service Outages: Hundreds of thousands of endpoints simultaneously restarting a service or connecting to a database.

How Distribute Over Resolves This: When an operator sets Distribute Over = 2 hours, each target endpoint calculates a randomized local execution delay (jitter) between 0 and 120 minutes. Endpoint A starts at minute 7, Endpoint B starts at minute 42, and Endpoint C starts at minute 108. The operational load is smoothed perfectly across the entire 2-hour window.

Deep-Dive: Expiration Time

Enterprise workforces are dynamic—laptops go to sleep, traveling employees board flights, and branch offices experience intermittent connectivity. If an action had zero lifespan, only endpoints online at the exact deployment moment would receive it.

How Expiration Time Resolves This: When an action is configured with Expiration Time = 5 days, the Tanium Server maintains the action definition active in the linear chain broadcast state. If an offline laptop powers on 3 days after the initial deployment, the Tanium Client checks in, evaluates the active action, verifies that the current timestamp is prior to the expiration cutoff, downloads the payload, and executes the remediation.

[!TIP] Exam Rule of Thumb for Expiration Time:

• For Emergency Incident Containment (e.g., isolating a compromised ransomware host or killing a malicious process), use short expiration times (e.g., 2 to 6 hours) to prevent running obsolete remediation commands days later.
• For Fleet-Wide Software Deployment or Compliance Baselines, use long expiration times (e.g., 3 to 14 days) to achieve maximum fleet coverage across traveling and offline devices.

---

---

5. Action approval and two-person integrity

Some organisations require two-person integrity, which means that actions a user initiates cannot deploy until another user approves those actions. This is a platform capability rather than a workflow convention, and it is configured through roles.

The three permissions that matter

Both are configured as custom roles and can be assigned to personas, users and user groups. The global switch is Require Action Approval, set to ON or OFF, and there is an optional Bulk Approval setting that lets approvers approve multiple actions without being prompted to review each configuration — which enables a More > Bulk Approval option on the Actions I can Approve page.

One documented exception: Tanium Endpoint Configuration automatically bypasses approval when deploying actions that distribute Tanium Client configuration and manifest packages.

The approval workflow

1. An operator deploys an action. If approval is required, the action does not start.
2. Users with the Admin reserved role can see everything waiting on Administration > Actions > All Pending Approvals.
3. An approver signs in and works from the Actions I can Approve page. They can click Preview to review the action configuration before approving, or use Bulk Approval to approve without reviewing.
4. Once approved, the action proceeds. Its status is visible on the Action History page or the Deployment Details page.

How long an approval lasts

The approval remains in force until the End At date-time that is set in the action configuration, or until another user modifies the configuration.

That second clause is the one that catches people. Editing an approved action invalidates its approval, and the action must be approved again. This is deliberate — otherwise an approver would be signing off on a configuration that someone could quietly change afterwards, which would defeat the entire point of two-person integrity.

Why organisations turn it on

• Insider-threat and compromised-account mitigation. A single credential cannot unilaterally push a change to production.
• Blast-radius reduction. A second reader catches an inverted filter or a target group that is wider than intended before it reaches endpoints.
• Audit evidence. Frameworks that demand dual authorisation for production change get it natively, with the record kept in the platform.

---

6. A safe deployment sequence