An Operator manages Pods and Services owned by a custom database resource. A developer manually edits those child objects, but changes keep reverting. What should they do instead?
Select an answer to reveal the explanation.
Short Explanation
Editing Operator-owned children is like repainting a rental car the fleet system keeps restoring. Change the custom resource that defines desired state. Let reconcile do the work.
Full Explanation
When an Operator manages Pods and Services owned by a custom database resource, manual edits to those children keep reverting because reconcile loops restore desired state from the CR. The correct approach is to update the custom resource and let the Operator reconcile—avoid fighting Operator-owned children. Municipal platform stability depends on that single source of truth so configuration drift does not briefly appear fixed and then vanish on the next sync.
Deleting the Operator Deployment permanently so manual edits stick fails governance and leaves databases unmanaged, backups unattended, and drift undetected. Adding finalizers on every child to block reconcile forever is sabotage of the control loop and can strand resources that cannot be deleted cleanly. Converting children to bare Pods outside any Namespace to “escape” reconciliation fails practically and still leaves you without Operator automation for users, failover, and storage lifecycle.
Exam caveat: some fields are intentionally left to users—read the CRD schema for which spec fields drive which children before assuming every annotation is fair game. Operational check: change the CR spec, watch the Operator update children, confirm status conditions, and refrain from kubectl-edit on owned Pods/Services unless the Operator docs say a field is user-managed.