Study guide
5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision
Tanium Certified Operator TCO
Track your progress as you read
Finished sections get a check mark.
1 Tanium Certified Operator Exam and Platform Foundations
1.1 The Tanium Certified Operator Exam: Blueprint, Logistics and Certification Path 1.2 Tanium Platform Components, Client Registration and Linear Chain Peering
2 Asking Questions (22% of the TCO Blueprint)
2.1 Sensors: Execution Model, Output Structure and Data Types 2.2 Parameterized Sensors and Question Parameter Syntax 2.3 Issuing Questions in Interact: Ask a Question, Question Builder and Question Anatomy 2.4 Creating Saved Questions: Reissue Intervals, Merge and Drill-Down Flags, and RBAC 2.5 Defending Tanium as an Efficient User of Network Resources
3 Refining Questions (23% of the TCO Blueprint)
3.1 Targeting Endpoints: from and with Filters, Operators and Boolean Logic 3.2 Drilling Down into Question Results 3.3 Merging Questions to Add Columns 3.4 Computer Groups: Management versus Filter, Dynamic versus Manual 3.5 Custom Tags and Tag-Based Grouping
4 Taking Action (15% of the TCO Blueprint)
4.1 Packages: Anatomy, Command Syntax, Parameters and File Distribution 4.2 Deploying Actions: Entry Points, Targeting, Distribution and Approval 4.3 Verifying Endpoint State and Automating with Scheduled Recurring Actions
5 Navigation and Basic Module Functions (23% of the TCO Blueprint)
5.1 Console Layout, the Main Menu and Where Things Live 5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision 5.3 Security and Risk Modules: Threat Response, Comply, Enforce, Reveal, Discover and Integrity Monitor 5.4 Interpreting Module-Specific Historical Results and Tanium Data Service 5.5 Choosing the Right Area: Client Status, Direct Connect and Action History 5.6 Content Sets, Roles and Personas: Why You Can See What You Can See
6 Report Generation and Data Export (17% of the TCO Blueprint)
6.1 Exporting Question Results: CSV, Headers, Flatten Rows and Copy 6.2 Creating Reusable Reports with Tanium Reporting 6.3 Dashboards, Boards and Metric Sources: Trends, Its Replacement and Migration 6.4 Scheduled Delivery and Exporting to External Systems with Tanium Connect
5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision
Key Takeaways Explain This Topic AI
Tanium Deploy installs, updates or removes software on a flexible set of targets, and is the right tool when what you manage is software with a lifecycle rather than a one-off command.
Tanium Patch automates patch delivery and models supersedence, so a raw question for a specific superseded KB can wrongly suggest an endpoint is unpatched.
Tanium Asset aggregates live asset data with recent data from offline assets, which is what makes it usable for licence reconciliation and audit rather than a live Interact question.
Tanium Performance monitors, investigates and remediates endpoint performance issues and carries history, so it can distinguish a new slowdown from a longstanding one.
Tanium Provision handles bare-metal and operating-system refreshes, and a provisioned endpoint loses local state such as custom tags, which breaks hand-maintained manual computer groups.
Last updated: August 2026
5.2 Operations Modules: Deploy, Patch, Asset, Performance and Provision
Quick overview: Blueprint objective NAV-1 asks you to navigate to a module to perform a basic module-specific task . That means knowing, for each module, what problem it owns and what the first thing you do in it is . This section covers the operations-side modules an operator uses most; section 5.3 covers the security and risk side.
1. Why the module boundary matters
Interact can answer almost anything and deploy almost anything, so a reasonable question is: why use a module at all?
Because modules add three things Interact does not have:
Domain state. Patch knows what a patch is , which ones supersede which, and what "installed" means on each platform. Interact only knows sensor strings.
Workflow. Deploy knows about software packages, maintenance windows and reboot behaviour, so you configure a deployment rather than assemble one.
History. Modules retain their own results over time, which is what objective NAV-2 — interpret module-specific historical results — is about.
The exam-relevant instinct: if a module owns the problem, go to the module. Rebuilding patch compliance out of raw sensors in Interact is possible and is the wrong answer.
2. Tanium Deploy
What it owns: installing, updating or removing software on a flexible set of targets.
- You want to… Basic task in Deploy
- Get an application onto a set of endpoints Create a software deployment targeting a computer group
- Remove unwanted or unlicensed software Create a removal deployment
- Keep an application at a required version Configure a deployment that re-evaluates over time
- Know what is deployable Review the software packages catalogue in the module
Deploy also feeds Reporting : the Endpoint Details page's Endpoint Management tab shows Software Package Applicability and Maintenance Windows panels populated by Deploy.
Tip
Deploy versus a plain package action: use a package action for a one-off command or script; use Deploy when the thing you are managing is software with a lifecycle — versions, applicability, maintenance windows, removal.
3. Tanium Patch
What it owns: automating patch delivery to minimise security vulnerabilities.
- You want to… Basic task in Patch
- See what is missing across the fleet Open the module's overview and read patch applicability
- Push this month's updates Build a deployment from a patch list against a target group
- Standardise a recurring monthly process Create a deployment template and reuse it
- Control when endpoints may be disrupted Configure maintenance windows
Patch also populates the OS Patch Applicability and Maintenance Windows panels on the Reporting Endpoint Details page.
The patch trap worth knowing
Cumulative updates supersede earlier ones. A question such as Get Installed Patches from all machines on a fully patched Windows endpoint returns the current cumulative update — not the twelve monthly updates it replaced. Searching for a specific superseded KB and finding nothing does not mean the endpoint is unpatched. This is exactly the kind of domain knowledge that makes the module the right tool: Patch models supersedence, a raw sensor question does not.
4. Tanium Asset
What it owns: viewing enterprise inventory by aggregating live asset data with recent data from offline assets .
That phrase is the whole point of the module. Interact tells you about endpoints that are online now. Asset gives you the inventory including the machines that are switched off — which is what makes it usable for licence reconciliation, hardware refresh planning and audit responses.
- You want to… Basic task in Asset
- Answer "how many of X do we own?" Open the inventory views in the module
- Reconcile software licence counts Report on installed software across the full inventory
- Plan a hardware refresh Report on hardware attributes and age
- Feed a CMDB Combine Asset with Connect (chapter 6)
- 5. Tanium Performance
What it owns: monitoring, investigating and remediating endpoint performance issues.
Performance is the module to reach for when the complaint is subjective — "my laptop is slow" — and you need it to become measurable. It carries history, so it can answer "was it slow yesterday, or only since the change?", which a live Interact question fundamentally cannot.
- You want to… Basic task in Performance
- Investigate a slow endpoint Open the endpoint's performance view and review its history
- Find fleet-wide degradation Review performance across a computer group
- Correlate a change with a slowdown Compare the period before and after a deployment
- 6. Tanium Provision
What it owns: modernising bare-metal and operating-system refreshes.
Provision is where OS deployment lives. For an operator the relevant fact is usually a consequence rather than a task: a provisioned endpoint is a new endpoint. Custom tags are gone (section 3.5), local state is gone, and any manual computer group listing the old machine is now wrong. Dynamic groups and tagging built into the build process survive; hand-maintained lists do not.
7. A routing table for operations scenarios
- Scenario Module
- "Install this application on the finance workstations" Deploy
- "Which endpoints are missing this month's updates?" Patch
- "How many Windows Server licences do we actually need?" Asset
- "This group of laptops has been slow since Tuesday" Performance
- "Rebuild these machines to the standard image" Provision
- "Is this specific process running right now?" Interact — no module needed
- "Run this one-off script on twelve endpoints" Interact — deploy a package action
- 8. Fleet hygiene as a worked routine
Continuous hygiene is where these modules earn their place, and the routine is the same each cycle:
- Step Where What you are establishing
- 1. Inventory Asset What we have, including offline assets
- 2. Exposure Patch and Comply (5.3) What is missing or misconfigured
- 3. Remediation Patch , Deploy Close the gap on a controlled schedule
4. Verification Interact , module history Did the gap actually close?
5. Trend Reporting (chapter 6) Is the gap closing faster than it opens?
Step 5 is the one that distinguishes an operator from a ticket-closer. A single patch cycle is an event; the burn-down across cycles is the thing leadership asks about, and chapter 6 is how you produce it.