A standard manifest creates resources, but an operator continuously manages them through their lifecycle. For stateful services, that means it can observe cluster state, apply migrations, coordinate upgrades, and enforce conventions such as ownership and status. The practical difference is automation of ongoing operations, not just initial creation, which is why operators fit recurring maintenance tasks better than static manifests.
Why an operator changes the operating model for stateful services
A standard deployment manifest tells Kubernetes what to create and keep running, but it does not encode the ongoing operational logic that stateful systems need. An operator turns that logic into code, so the platform can react to cluster state over time instead of only instantiating pods and services once. That is the practical distinction: static desired state versus continuous lifecycle management.
For stateful services, the difference matters because the hard part is rarely initial scheduling. The hard part is preserving data consistency, sequencing upgrades, handling topology changes, and keeping the service within the conventions that the application expects. A manifest can describe replicas, volumes, and probes, but it cannot reason about whether an upgrade should wait for a leader election, whether a migration must precede rollout, or whether a failed node should be rebuilt in a specific order.
That is why operators are often used when the service has embedded operational rules, such as backup timing, failover behaviour, schema changes, certificate rotation, or cluster expansion. The operator becomes the control loop that watches state, compares it to desired operational policy, and takes action when conditions drift.
What a manifest can express, and what it cannot
A standard deployment manifest is best when the workload is relatively stateless or when the operational steps are simple enough to manage outside the cluster. It defines the runtime shape of the workload, but it does not understand application semantics. If the service needs a migration before the new version starts serving traffic, the manifest can only express the new pods, not the decision logic that makes the rollout safe.
For stateful services, that limitation shows up quickly. The manifest can mount persistent storage and set update strategy, yet the service still needs someone or something to coordinate how replicas come back, which instance should be primary, and how to avoid split-brain or partial writes during maintenance. An operator fills that gap by embedding the service-specific workflow into reconciliation.
In practice, that means the manifest is a configuration document, while the operator is an automation layer. The manifest is useful when the lifecycle is predictable and externalised. The operator is useful when the lifecycle is repetitive, conditional, and tied to the health of the application itself.
Why this distinction matters for reliability and control
Stateful systems have more failure modes than simple deployment objects, because the application state has to survive restart, replacement, and upgrade. Operators reduce manual intervention, but they also concentrate more responsibility into code that must be tested and trusted. If the operator’s logic is wrong, it can accelerate a bad rollout just as efficiently as it can execute a good one.
That makes observability and guardrails important. Good operator design should make status visible, limit the blast radius of each action, and keep reconciliation idempotent so repeated events do not compound damage. The goal is not automation for its own sake, but automation that preserves service invariants while reducing human error during recurring operations.
For teams choosing between the two, the practical question is whether the workload needs a controller that understands application behaviour, or merely a declarative spec that Kubernetes can run as given. The more the service depends on ordered actions and state-aware maintenance, the stronger the case for an operator.
Risk and Threat Considerations
Stateful services managed only by static manifests often accumulate operational risk in upgrades, failover, and recovery because the required sequence is left to humans or ad hoc scripts. When those steps are not encoded, the most common failure is inconsistency between the service’s stored state and the cluster’s runtime state.
Failure mechanism: A manifest can restart or replace workloads, but it cannot enforce the application-specific checks that prevent unsafe migrations, missed backup steps, or incorrect promotion of replicas.
Impact: The result can be data loss, extended downtime, or a brittle maintenance process that works only when operators intervene correctly every time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Lifecycle automation for stateful services needs bounded operational authority. |
| RC.RP-1 — Recovery Plan is executed during or after an incident | Operators often coordinate restore, failover, and maintenance actions that affect recovery outcomes. | |
| GV.PO-1 — Organizational cybersecurity policy is established, communicated, and enforced | Operator behavior should reflect an explicit policy for lifecycle actions on stateful services. | |
| Recommendation — Apply least-privilege controls to the operator's permissions and narrow its access to only the managed resources. Use the operator's automation to rehearse and execute recovery steps in a controlled, repeatable sequence. Define policy for who may change operator logic and which lifecycle actions it may perform automatically. | ||
| CIS Controls v8 | 5.4 — Secure Configuration for Enterprise Assets and Software | Operators encode service-specific operational configuration and reconcile it over time. |
| 4.8 — Unwanted Software and Software Inventory | Operators are long-lived management components that should be inventoried and governed like other software. | |
| Recommendation — Track and harden the operator's configuration so reconciliation cannot drift into unsafe state changes. Inventory the operator and review its version, ownership, and update path alongside the stateful service. | ||
Practitioner Guidance
What to verify: Before choosing a manifest-only approach, verify that the service can tolerate unsupervised restarts, version changes, and replica replacement without coordinated application logic. If not, the missing capability is not “more YAML”, it is a controller that understands the service lifecycle.
Decision rule: Use a plain manifest when the workload is simple enough that Kubernetes can safely reschedule it without domain-specific decisions. Use an operator when the service has ordered maintenance, state transition rules, or recovery steps that must be repeated consistently across environments.
Common mistake: Teams often treat an operator as just a convenience wrapper around deployment automation. For stateful systems, that underestimates how much of the real safety model lives in the upgrade and recovery workflow, not in the initial resource definition.
Practitioner takeaway: The key distinction is not whether Kubernetes can run the service, but whether the service needs ongoing application-aware decisions to remain correct after the first deployment.
Related resources from NHI Mgmt Group
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between zero trust for users and zero trust for NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
