A public-health team labels every Deployment an “Operator” because it runs in the cluster. What distinction should architects enforce?
Select an answer to reveal the explanation.
Short Explanation
Calling every Deployment an operator is like calling every city van an ambulance. Operators specifically watch custom resources and reconcile them. A plain web Deployment is just a workload unless it implements that controller pattern.
Full Explanation
Architects should enforce that an operator is a controller that reconciles custom resources—not merely any Deployment in the public-health cluster. Calling every Deployment an operator is like calling every city van an ambulance; the defining behavior is CR-centric control. A readiness probe alone does not make a Pod an operator by specification. Mounting hostPath at / does not turn a Deployment into an operator. ReplicaSets are not “the operators” while Deployments never participate; operators are often packaged as Deployments that run controllers. Exam caveat: Operator = reconcile CRs; workload Deployment ≠ operator by default. Operational check: Inventory true operators via their CRDs/controllers, and stop labeling ordinary web Deployments as operators in architecture docs. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.