TS-C (NCCT) key terms

A lightweight software component installed on an endpoint that runs checks, collects data, and reports back to a central management server, letting administrators act on devices without manual logins.

A defined set of rules and endpoints that lets one system request data or trigger actions in another programmatically, so tasks can be automated instead of performed by hand in a user interface.

The process of converting data from different sources into a common format, naming scheme, and scale so records can be compared, searched, and reported on consistently.

An access model where permissions are attached to roles rather than individual accounts, and users receive permissions by being assigned one or more of those roles.

The principle of giving each user, service, or process only the permissions needed to do its job, and no more, to limit the impact of mistakes or compromised accounts.

An authentication arrangement in which a user logs in once at a central identity provider and is then granted access to multiple connected applications without signing in again.

The work of estimating future demand for users, data, and processing so that infrastructure, licensing, and budgets are sized before performance problems or outages occur.

A design that keeps a service running through component failures by duplicating critical parts, such as servers or database nodes, and automatically failing over between them.

Adding more machines or instances to a system so work is spread across them, as opposed to upgrading a single machine, which is called vertical scaling.

A documented, approved set of settings for systems and applications that serves as the reference standard; any deviation from it is treated as a change to be reviewed.

A table showing which versions of a platform, operating systems, agents, and integrations are supported together, used to avoid unsupported combinations during upgrades and new installs.

An architecture in which one instance of an application serves several separate customer organizations, keeping each tenant's data and settings isolated from the others.

Dividing a network into smaller zones with controlled traffic between them, so a compromise in one zone is less likely to spread and access can be restricted by role.

A near-copy of the production environment used to test installations, upgrades, and configuration changes before they reach live users.

A limited rollout to a small, representative group of users or devices, used to confirm that a change works before it is extended to the whole organization.

Documented steps and saved backups that let a team quickly return a system to its previous working state if a deployment or change fails.

Testing performed by real users or business owners against agreed requirements to confirm a deployed system supports actual work before it is formally accepted.

Creating and configuring the accounts, roles, devices, or infrastructure a user or service needs, usually through automation so that setup is repeatable and consistent.

The conditions that must exist before software can be installed, such as supported operating system versions, free disk space, open ports, certificates, and required accounts.

An automated probe that confirms a component is running and responsive, often feeding dashboards or triggering alerts and failover when results fall outside expected ranges.

A short, step-by-step guide for performing a routine operational task or handling a known incident, written so any trained team member can follow it consistently.

Collecting log records from many systems into one central store so they can be searched, correlated, retained, and alerted on from a single place.

A structured investigation that goes beyond the immediate symptom to identify the underlying reason a problem occurred, so a fix prevents recurrence rather than just restoring service.

The repeatable process of identifying, testing, approving, and applying software updates that fix defects and security flaws across systems on a defined schedule.

Copying data and configurations to a separate location on a schedule, plus the tested procedures for loading those copies back when data is lost or corrupted.

The gradual divergence of live system settings from the approved baseline, caused by manual fixes and unrecorded changes, which makes behavior inconsistent and troubleshooting harder.

A predefined sequence that says who to contact, and in what order, when a problem exceeds a support tier's skill or authority or breaches its response target.

Protecting stored data, on disks, backups, or databases, by encoding it so it is unreadable without the correct key, which limits damage if media is stolen.

Protecting data while it moves across a network by using encrypted protocols such as TLS, so intercepted traffic cannot be read or altered by an eavesdropper.

A tamper-evident record of who did what, when, and from where across a system, kept so activity can be reviewed and evidence produced during investigations or audits.

Rules that state how long each category of data must be kept, where it is stored, and when and how it is securely deleted.

Assigning labels such as public, internal, confidential, or restricted to data so handling, access, and protection requirements match the sensitivity of the information.

Splitting sensitive tasks among different people so that no single account can both make and approve a high-risk change, reducing fraud and accidental misuse.

Storing passwords, API keys, and certificates in a protected vault with controlled access and rotation, rather than embedding them in scripts or configuration files.

Requiring two or more independent proofs of identity, such as a password plus a code from a phone, so a stolen password alone is not enough to sign in.

The plans, backups, and alternate infrastructure that let an organization restore critical services after a major outage, along with targets for how fast and how complete recovery must be.

The maximum acceptable time a service can be unavailable after a disruption, used to set recovery priorities and justify standby infrastructure or staffing.

The maximum acceptable amount of data loss measured in time before a disruption, which determines how frequently backups or replication must run.